193 karma · joined June 16, 2016
You suggested using nextjs for the backend. This weeks flavor of nextjs database connections is to be done with Prisma. Setting the two up together is no walk in the park. So great, you’ve spent a week setting up Prisma and the layers which connect it to your API. You’ll probably now task yourself with connecting the database to a GraphQL API with a Playground (another week). What about auth? Hand roll of reach some the suggested Auth0 library for nextjs. Another week of integrating. You can see the pattern. Meanwhile, the Django user has everything setup in day one, nextjs app for front end only deployed on day 2, and is building user features day 3.
We haven’t even talked about setting up request middleware, integration with logging tools, distributed tracing, exception aggregators, sending email, scheduled background tasks. Which you can spend another week for each or just go to your battle tested framework of choices’ doc page.
The performance boost argument is a joke when we have horizontal scaling and and multithreading.
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/in...)" curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/maste... | python - brew install pyenv // update shell with pyenv pointer pyenv install 3.9.0 pyenv global 3.9.0 poetry init poetry config virtualenvs.in-project true --local poetry install
For deployment, Docker python3:alpine, install poetry, copy over pyproject.toml and install
Tech stack: React + Nextjs (react-query, graphql-generate, typescript), Django (admin panel, celery for background tasks, channels, graphql), Postgres, Redis (for celery and websockets). Postgres in RDS with auto rotating secrets. Deploy as a Django as a Docker image on AWS. Access keys from Secrets Manager at runtime (this is your pre EKS setup). Deploy frontend app on Vercel. Use Stripes newest payments system for billings. Deploy everything via GitHub actions PRs and use Actions, including the new code and dependency checks.
Bam you’ve got a frontend with a busting cache, websockets for automatic updates, ability to do server side rendering, and all the content management systems from the Django admin panel you would have setup by hand with Express/Flask. You can choose to use any method of auth that Django provides or go with Auth0.
Using graphql-generate and Django Graphene you can auto generate your typescript SDK on your frontend. All you have to worry about now is your view code and your models structure.
Using celery and celery-beat will allow you to do long running or scheduled tasks. Connect it with Django channels and push updates from a celery worker to the frontend.
GitHub will keep it up to date and check for security errors with automatic pull requests.
Expansions on this architecture include: - switching to EKS (useful especially for secrets and scale) - Infra as code via Pulumi to switch to any K8s provider - Using RabbitMQ for more robust messages passing over simple Redis queue
Also, I still haven’t seen how the async addition will work with Class Based Views. Also, Django Rest Framework is still considering spending time for support. Until these two use cases are viable many users won’t benefit.
my favorite feature of `now` is environment variables, and `next.js` 9.4 has even better support. so if using `now`, you store your env vars / secrets in your project on https://vercel.com/ in separate buckets for prod, dev, etc
then on your local environment run `now env pull` and get the latest dev env vars populated in `.env` of your project. this is super great for remote teams where you don't have to share .env files via communication channels / ask someone for the latest variable value
the Graphene implementation for Django brings up a Relay GraphQL server so fast. The best part is that at compile time it ensures your GraphQL schema confirms to the Relay standard, enforcing correct naming. You really don't have to think about much.
I've been using it for about 4 years now. Best money management system I've used in a long time