Skip to content


Reinventing the wheel or targeting Scalability ?

We had a lot of discussion and thoughts about adding authentication to TheDevStarter template and at the end we decided to completely start from scratch and build it by hand so that it remains flexible and scalable enough.

having some of our other products running on Firebase / Supabase auth etc, we faced quite a few issues with scaling since the cost of scaling is underestimated while building the MVP and this hurts in long run.

The Devstarter boilerplate contains a custom JWT based authentication that can be customized to work with mobile apps, Chrome extensions and everything that you plan to build out since there is no Vendor Lock In as with Supabase / Firebase auth etc.

For Social Authentication we’re launching with Google Auth but we are also adding other Providers like Twitter and Github.

Configuring Auth:

for Simple Email authentication you can configure VERIFY_EMAIL_ON_SIGNUP as true/false on Backend server to enable email verification by a magic link. to enable this make sure you have configured SMTP credentials in backend env to enable emails using the environment variables.

you can use any SMTP provider, for low volume can start with Gmail and then scale to Brevo/ AWS SES etc based on your choice.

EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'

Google Auth

to configure Google Auth you need to configure Google Oauth credentials in backend env Getting Google Oauth2 credentials

DEFAULT_USER_AVATAR="any user avatar image"

Protected Pages:

any page built with (internal-pages) directory in Frontend would be protected and require the user to be logged in, whereas all (external-pages) would be public by default.

whereas in backend all API routes are protected by the auth_provider and to open up a API route to user we can do auth=None in the API decorator as follows:

@router.get("/blogs?query={query}", response=List[PostBase], auth=None)

here auth=None opens up the API to anonymous users.