Sponsorship

If you, or someone you know, is interested in sponsoring the newsletter, please reach out at console.substack@gmail.com

Not subscribed to Console? Subscribe now to get a list of new open-source projects curated by an Amazon engineer in your email every week.

Already subscribed? Refer 10 friends to Console and we’ll donate $100 to an open-source project of your choice and send you a Console sticker pack!

Share Console

Projects

the-book-of-secret-knowledge

The Book of Secret Knowledge is a collection of inspiring lists, manuals, cheatsheets, blogs, hacks, one-liners, cli/web tools and more.

stars: 46579, watchers: 1638, forks: 4871, issues: 15

last commit: July 13, 2021, first commit: June 23, 2018

https://twitter.com/trimstray

slides

slides is a terminal based presentation tool.

language: Go, stars: 4404, watchers: 50, forks: 112, issues: 9

last commit: July 16, 2021, first commit: April 05, 2021

https://twitter.com/maaslalani

supertokens-core

SuperTokens is an open core alternative to proprietary login providers like Auth0 or AWS Cognito.

language: Java, stars: 2417, watchers: 39, forks: 79, issues: 91

last commit: July 06, 2021, first commit: January 05, 2020

https://twitter.com/supertokensio

PynamoDB

PynamoDB is a Pythonic interface to Amazon’s DynamoDB.

language: Python, stars: 1659, watchers: 42, forks: 363, issues: 226

last commit: June 29, 2021, first commit: January 20, 2014

https://www.linkedin.com/in/ikonst

An Interview With Rishabh Poddar of SuperTokens

Hey Rishabh! Thanks for joining us! Let’s start with your background. Where are you from, how did you learn how to program and what languages or frameworks do you like?

Graduated from Imperial College of London in 2015 with a BSc in CS. Originally from Mumbai, India.

Learnt programming when I was 15 by myself, and then formalised it via a college education - so a lot of unlearning, and learning again.

I have worked with Node (express), PHP, Spring, reactJS, react-native, iOS and Android. Out of these, I prefer Node the most, due to its simplicity. Though I never use JS directly, always use TypeScript.

What are you currently learning?

About web components and compilers like StencilJS. We may use it for our frontend SDK to support React, Angular and Vue + VanillaJS

Why was SuperTokens started?

SuperTokens was initially a secure session management solution - we had started it because we saw that session management was one of the most misunderstood topics (judging by the endless arguments online), and that its importance in user security is generally overlooked. For example, even if an app has 2fa, if a user’s session tokens are compromised, that user’s account is compromised. How easy it is to compromise the tokens and the effect of that is a function of how it’s implemented - so we wanted to provide an out of the box, very secure solution.

Once we got into YC, we quickly realised that auth in general still has several pain points. Almost all the companies we spoke to (~100), complained about its complexity, limitations, pricing etc.. So we expanded our scope from session to auth in general.

What value did you get out of being in YC?

The biggest value that YC brought us was a large pool of other devs / companies we could go talk to, to understand their auth related pain points. Before YC, it would be hard to get on calls with other devs, but during and after YC, we got tons of inbound! So the biggest learning here is that talking to users / potential users is the best activity early stage founders can do.

Are there any overarching goals of SuperTokens that drive design or implementation?

So we aim to be as developer friendly as possible. This means allowing for customizability, control and natively supporting as many frameworks / languages as possible.

For example, we have architected SuperTokens so that the frontend talks to your backend API layer and not SuperTokens directly. Our backend SDK automatically exposes all the APIs required by our frontend widgets. This allows users to customise all those APIs, within their own backend very easily. They don’t need to create webhooks, or upload source code to the SuperTokens dashboard.

What trade-offs have been made in SuperTokens as a consequence of these goals?

The trade off of this is that the speed at which we can release new features is slower - cause we need to build those backend APIs for each language out there, as opposed to just once in the SuperTokens core.

It also implies that some of the features that other auth providers ask users to pay for, we have to make them free. For example, some providers limit the number of social login providers in their free tier, or limit the kind of social login allowed. In our case, because the whole OAuth dance happens via the user’s frontend and backend (not involving SuperTokens core), we can’t have any of those limitations - this is a positive from a customer’s point of view, but may be a negative from our business’ point of view.

What is the most challenging problem that’s been solved in SuperTokens, so far?

I think the session management that we have built works incredibly well. We use rotating refresh tokens as a security measure, and have had to solve several complex edge cases such as resilience to network failures, or syncing refresh API calls across multiple browser tabs. 

Are there any competitors or projects similar to SuperTokens? If so, what were they lacking that made you consider building something new?

There are tons of other auth providers - both open and close sourced.

I am biased here, but other solutions lack the ability to make lots of customisations easily. Plus there is a very steep learning curve to implementing them - especially for other open source auth providers. I believe the different architecture that our solution employs, allows for easier customisations and prevents developers from having to understand all the various OAuth flows and jargon - making it easier to understand.

What was the most surprising thing you learned while working on SuperTokens?

It was surprising for me when I realised that our product is, first, our documentation and second, the actual solution / code. As developers, we tend to focus way more on the code than on user communication… but if our docs are “bad”, then no matter how the code is, it won’t matter. Whilst the other way around is not true (as long as the code is correct).

What is your typical approach to debugging issues filed in the SuperTokens repo?

The first step is to reliably replicate the issue. Sometimes this can be really difficult because of the number of various frameworks  and deployment options (serverless or not, using SSR or not). I remember that there was a frontend issue that a user of ours was experiencing - an issue that I could not replicate locally. So I used chrome’s override feature to change the frontend code on their site directly whilst debugging. 

Once the issue is replicated, we go about finding the root cause of it and fixing it. Sometimes the fix is easy, other times, it leads to breaking changes… we of course try and minimise the number of API / breaking changes, but sometimes, it’s inevitable.

Finally, we add unit / integration tests to make sure that the issue never comes back.

What is the release process like for SuperTokens?

For each SDK / the core, we start by adding a dev tag to the commit that needs to be released. The tag looks like dev-vX.Y.Z, where X.Y.Z is the current version number.

Adding this tag starts a CI/CD process which runs all the unit tests for the SDK, and all the integration tests.

For the integration tests, we set up the whole supertokens stack in CICD and run tests for each compatible version. For example, if we release a change to the frontend SDK, we set up a node backend and the supertokens core for integration tests. If the frontend SDK is compatible with multiple versions of the node backend, then we run integration tests with each of the versions.

Once all the tests pass, we add a release tag (vX.Y.Z) to the commit and delete the dev tag. A release tag can only be added to a commit that has a dev tag, and if all the tests have passed.

In terms of versioning, we follow the Semantic Versioning guidelines.

What are you using for CI/CD?

We are using CircleCI.

How do you intend to monetize SuperTokens?

We follow Gitlab’s buyer based model. So we (will) have different pricing tiers for different feature sets - aimed at different sizes of companies.

Within each tier, we will change the pricing based on the usage / number of users.

The pricing will also be different for our managed service vs self hosted.

What is the current main source of revenue?

At the moment, because we still need to build out many features that “larger” companies need, our main source of revenue is support.

Where do you see the project heading next?

We have a product roadmap page that highlights all the next set of features we will be making

We also want to expand the team to be able to support several more tech stacks - both frontend and backend.

Finally, we have a lot of work to do to make our docs better - starting with moving to Docusaurus v2.

Is there anything in particular you're looking for in a developer?

Excellent core CS skills - so understanding of operating systems, threading, cryptography, networking, compilers etc.. someone who can work with a variety of languages or is capable of picking one up in a few weeks time.

Where did you hear about Docusaurus?

So ReactJS's docs use Docusaurus. That's where we first found out about it.

What motivates you to continue contributing to SuperTokens?

Seeing sites that implement us - even the people behind that site don’t pay us.

Where do you see software development heading next?

I see a lot of people using serverless and the ecosystem around that.

With the release of tools like Github copilot, I guess that in a few decades, a lot of the boilerplate / grunt work in programming will be 100% automated. Devs will be focusing way more on app / code architecture, code reviews (generated by machines) and stitching different tools together to achieve what they want - development time will reduce significantly.

Where do you see open-source heading next?

A lot more people will want to choose open source solutions over closed source (that’s one of our thesis for why SuperTokens). The reason is that a whole generation of devs have “grown up” and learnt programming by reading and contributing to open source - so the natural instinct is to go with an OS alternative.

The above in turn implies more scope for contributions, which in turn implies more features and “better” projects.

The one topic I am most unclear, but very curious about, is how crypto / blockchain will affect open source developers - specifically for OS code that’s running on blockchains like Ethereum. For example, if I write an OS library that’s ultimately used in an app that runs on Ethereum, I can imagine there being a system where the author(s) of the library get paid each time their code runs… That would be pretty cool.