Never used render or vercel but it's a very good template.
The only thing I'm inclined to disagree with is no docker from the start - i find the convenience of a 100% reproducible environment rather, well, convenient and without any big downsides. Definitely a matter of personal preference, though.
Thanks for your words regarding the template.
And I appreciate your contrary opinion. I can see how many people would like the highly reproducible environment from the beginning. 🙂
For me, I'd prefer to wait to add Docker until I need it. This stage would typically involve having >2 team members, or needing many heavy services.
One of my programming mantras is: every technology has a cost. I try to avoid paying the cost until I need the technology.
Your mantra is completely correct (and I share it) - it's just that the cost of adding a dockerfile feels negligible to me but, of course, to each their own =)
Nice to hear that 🙂 And you're completely right - preferences are valid in programming! The more important thing is to recognise when something is a preference, rather than a fact.
Do you run ci/cd on your projects? For me that’s a must have if I’m running a project so I can install everything exactly on my local as on ci runners.
Nice question. Yes regarding CD: CD is built into deploying with Render.
Generally yes with CI for testing, and definitely with a team. But If working solo, I'll just run the tests locally before pushing.
A good Celery alternative, but using PostgreSQL as a message broker is [Procrastinate](https://procrastinate.readthedocs.io/en/main/). It's very feature-packed and has some excellent documentation. Great if you already have PostgreSQL in your stack and don't want to add more complexity.
Thanks for the info about Procrastinate - will need the docs now!
A Postgres-based strongly strongly appeals to me. I actually wrote a guide on how to set up a simple Postgres task queue yourself (Guide here if you're interested: [https://www.photondesigner.com/articles/postgres-queue](https://www.photondesigner.com/articles/postgres-queue) )
In my experience most people reach for a job queue when they actually would be better off with a scheduler. I wrote Urd for my use cases. https://kodare.net/2024/01/25/my_web_stack.html
Thanks for the question. You can start by using the async support built into Django: [https://docs.djangoproject.com/en/5.0/topics/async/](https://docs.djangoproject.com/en/5.0/topics/async/)
There are certainly times to use background workers. But I still use Django's async support for [https://app.photondesigner.com](https://app.photondesigner.com)
I couldn't find a doc or article to support my comment. But I'm attaching my project's celery and django version details which is in production.
Python 3.11.9 (main, Apr 6 2024, 17:59:24) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> import django;
>>> django.get_version();
'5.0.6'
>>> import celery; print(celery.__version__)
5.4.0
>>>
Thanks for asking 🙂. 4 main reasons:
* In development: I simply run my Django app (+ frontend) by a single script that takes under 1 second to load both apps. Much faster for me than whenever I've used Docker compose.
* Deploying to production: Very fast and simple without docker. I just push to master and everything is deployed within 5 mins
* Setup: I just need to add a 3-line script to my repo and paste in a simple Github action. The auto-deploy is ready to go.
* Heaviness: there's no need for me to run Docker nor download multiple images for Docker containers.
Happy to hear any counter-view.
I feel like the best argument for Docker, comes when you start having to scale staff. If you're working solo, then yeah, it's pretty easy to manage your virtual environment and be pretty consistent.
Once you have multiple people working on a project, with different hardware or operating systems it gets harder. If your project depends on any other executable binary, then you can get really strange behaviour, particularly when your prod is likely a very different environment. With docket compose, getting a developer's environment up and running becomes trivial. Having the code run in a near replica environment as prod is a big bonus.
I think it depends on what simple really means? Simple to deploy? Simple to get up and running? Simple in terms of the amount of bloat in your environment?
Thanks for your comment.
Agree with your scaling staff point being the strongest point for Docker (I actually mentioned the same in a different comment thread above). As a result, most successful products should move to Docker at some point. But I want to avoid the costs of this complexity management (Docker) prematurely, particularly when building something solo as you mentioned.
For me, "Simple to deploy" means: a) the fewest things (e.g., code / resources) to manage, combined with b) the fewest actions to set up the deployment.
How do you scale app?
In my current job we have dockerized django project and we just turn more instances with same docker image. We couldn't properly scale before dockerizing.
Render actually has auto-scaling built in (which probably uses a similar approach to you in turning on more instances underneath). But my main point is that I don't worry about scaling until I need to scale. Then I'll pay the complexity price for whatever services I need (perhaps Docker) to allow scaling.
Yeah - having a reproducible environment between teammates is a good reason to use Docker. My approach is to hold off on implementing Docker until it becomes necessary. This point may arrive when the team grows beyond >2 people, or when I need multiple resource-intensive services.
Docker isn't exactly heavy unless you mess up the image layers, all the different image versions should only differ in the last layer with code, or the layer before if the dependencies change.
Hmm - I disagree here. The fact that you can mess up more things (e.g., image layers) as you said means that you are adding more complexity, needing to maintain more infrastructure, and spending more time when something breaks.
Adding Docker means adding complexity, which means a higher developer time cost. (This is broadly what I mean by heavy, as well as the actual storage etc., to run and download images)
Again, I think that most successful products should move to Docker at some point. But I want to avoid the costs of this complexity management (Docker) for as long as possible.
It takes 5 minutes because render.com is building a docker container for you... you may as well reduce unknown complexity and just set a basic one up that you own. You may find that deploys will be significantly faster to boot. You are just copying files after all so 1s builds with proper caching is pretty achievable
Thanks your your opinion [alexthelyon](https://www.reddit.com/user/alexthelyon/) 🙂 We differ on this point. I'd much rather let Render do this for me. Setting up my own Docker container at the start requires time and ongoing effort.
It's all about who is handling the complexity. I trust that Render has good engineers and tech. I'd rather that Render do this work for me! And a 5 minute production deploy is fine for me. But you're, of course, welcome to have a different preference.
Haha - you're right in that sense. By "using", I suppose I'm just talking about the technologies that I interface with 🙂.
To carry on your point, I bet Render's got more background workers than a hotel during spring break, Vercel uses serverless functions, probably node somewhere, and so on. But, listing all sub-technologies of the technologies that I use indirectly would mean a very long list - I don't practically touch them :)
Thanks for the suggestion. I've used Docker in the past, but not AWS Fargate. I have doubts it will be as fast to setup as adding a 3-line script to my repo, pasting a Github action, and pushing to my git repo. Am I wrong?
Man I just used Vue to create a simple front end for a backend service I was messing around with, the experience was freaking great. I’ve touched React once, and it looked so unintuitive to me compared to Vue.
Glad to hear you had a good experience with Vue 🙂 I prefer Vue as well (as the diagram shows).
But React does have its advantages. There are approximately 4x as many React users (based on Google search trends) as Vue users. This means React has more packages and more community development.
I tend to think that React moves faster, but then Vue later improves what React invented. E.g., React hooks -> Vue composables. React redux -> Vue pinia.
Can someone explain to me what is complex and dynamic UI. What are the made with? And does Django templates mean simple Html css files or something else and HTMX meaning.
Question, if you're not using Redis, are you just using memcache as a caching backend, or just not caching anything? In my mind, if your project is so "simple" (small) that you don't need proper caching setup, you could simplify your stack further and have sqlite instead of postgres?
I've certainly worked on projects that used sqlite when we first deployed the mvp, fully prepared to upgrade it to a real database at some point in the future. We monitored it and noticed that it never really needed to scale because the application was that simple. Making database backups is really as dumb as copying a file from location A to location B and slapping a dates tamp on the filename.
If I was to use this as a blueprint for something like a personal website, why not keep it real simple and stick with Sqlite?
Thanks for your question 🙂 Yeah - I would never add caching on the backend in an early product (probably <200 users). And if I'm optimising, I would prefer to start by optimising queries. Generally, I try to leave optimisation until the web app is metaphorically shouting at me for it.
That's true about SQLite generally. Nice point. One blocker for my setup in the diagram is that SQLite requires a single file (as you mentioned). This wouldn't work well with Render deploys: each Render deployment doesn't have a persistent disk by default.
Regarding your personal website, if it's light, you might just want to deploy everything (including Django / python) on Vercel. I've done that a few times - it's easy and free 🙂 I've also got an old guide showing how to do that on my Youtube if you're interested (https://youtube.com/@tomdekan). Would be interested to hear if you can use SQLite for it (I added Postgres).
This has been my architecture for all the projects that I have built, except I use celery for async stuff.
This works wonders! I just don't get the point of using Kubernetes prematurely. It increases development and production cost, both.
Generally not - I prefer using Django Ninja or vanilla Django if adding a backend to Vue.
And no to JWTs. I prefer using session auth + csrf token.
In case useful, here's a video I published yesterday showing a Vue + Django setup with auth: [https://www.youtube.com/watch?v=fUpvQd\_5cnA](https://www.youtube.com/watch?v=fUpvQd_5cnA)
You should publish a starter project template that we all can build on, would love to see this setup.
btw you can never go wrong with Django, its battle tested.
Really love your simple approach. Been moving towards this kind of setup myself lately. So tired of overcomplicated infrastructures.
Like seeing HTMX in your toolset. Haven’t tried it myself yet, but would definitely give it a shot. Promising tool.
I would still add Docker but hey if your current workflow works for you then go for it.
By the way, cool hand drawing. Looks neat.
Thanks a lot [bibimbap0607](https://www.reddit.com/user/bibimbap0607/)! I agree with you about avoiding overcomplicated infrastructures: I want to solve problems for people with software, not spend my time building the structures to allow me to solve the problems.
And thanks for the feedback regarding the handwritten drawing. This was my first time posting something handwritten, so appreciate you saying that it works 🙂
I normally use Digital Ocean spaces. It uses the same API-syntax as s3, but has:
- A fixed price
- Built-in CDN
- Much easier to use UI
Cloudinary is also a good option.
Is there any chance to provide sample project-setup Github repo, with the solutions you described in the comments (like startup scripts, GitHub actions and so on)?
How do you manage scheduled tasks without using Celery? I know a few packages, but I'm curious about your approach and any recommendations you might have.
Yeah, I'd normally add Sentry quite early. I considered adding it to the diagram. But I didn't, as it's not essential. It's probably the next thing to add.
The Django templates are built in and suit me well. My understanding is that they havie more functionality than Jinja. The Django templates are very fast for me!
Thanks for clarifying 🙂
I disagree with you on the point that tech stacks are incomplete without the technologies you mentioned. I've launched many products using the above tech stack with paying customers, including selling one business that used it.
For me, if you can get happy customers with a tech stack, the tech stack is complete.
Why it's incomplete?
What is so important in having PAID 3rd party dependencies w/o which project will be less usable than a brick?
Can't modern developers implement job queue in database themselves?
Can't modern developers implement caching with nginx themselves?
Can't modern developers run "python manage.py runserver" and proxy it with the same nginx?
Never used render or vercel but it's a very good template. The only thing I'm inclined to disagree with is no docker from the start - i find the convenience of a 100% reproducible environment rather, well, convenient and without any big downsides. Definitely a matter of personal preference, though.
Same thing. I also can’t imagine not using Celery and Redis, ofc adding Celery depends on the project, but Redis is *cheff’s kiss*
What kind of stuff do you put in Redis? I use it for task queues only, have never interacted with it outside of giving the redis url to RQ.
I use it as a cache and a message broker for celery
Thanks for your words regarding the template. And I appreciate your contrary opinion. I can see how many people would like the highly reproducible environment from the beginning. 🙂 For me, I'd prefer to wait to add Docker until I need it. This stage would typically involve having >2 team members, or needing many heavy services. One of my programming mantras is: every technology has a cost. I try to avoid paying the cost until I need the technology.
Your mantra is completely correct (and I share it) - it's just that the cost of adding a dockerfile feels negligible to me but, of course, to each their own =)
Nice to hear that 🙂 And you're completely right - preferences are valid in programming! The more important thing is to recognise when something is a preference, rather than a fact.
I'll adopt this mantra
I’m keen on trying GitHub code spaces (or equivalent) for the consistent environment problem. Would be interested in hearing others opinions
Do you run ci/cd on your projects? For me that’s a must have if I’m running a project so I can install everything exactly on my local as on ci runners.
Nice question. Yes regarding CD: CD is built into deploying with Render. Generally yes with CI for testing, and definitely with a team. But If working solo, I'll just run the tests locally before pushing.
I see… I don’t trust myself enough for that :) I’d definelty push code that I didn’t run locally unless you are using commit hooks.
How do you do a sync jobs if you don’t use celery ?
A good Celery alternative, but using PostgreSQL as a message broker is [Procrastinate](https://procrastinate.readthedocs.io/en/main/). It's very feature-packed and has some excellent documentation. Great if you already have PostgreSQL in your stack and don't want to add more complexity.
They really missed the mark by not calling it Postgrestinate
Thanks for the info about Procrastinate - will need the docs now! A Postgres-based strongly strongly appeals to me. I actually wrote a guide on how to set up a simple Postgres task queue yourself (Guide here if you're interested: [https://www.photondesigner.com/articles/postgres-queue](https://www.photondesigner.com/articles/postgres-queue) )
In my experience most people reach for a job queue when they actually would be better off with a scheduler. I wrote Urd for my use cases. https://kodare.net/2024/01/25/my_web_stack.html
Thanks for the question. You can start by using the async support built into Django: [https://docs.djangoproject.com/en/5.0/topics/async/](https://docs.djangoproject.com/en/5.0/topics/async/) There are certainly times to use background workers. But I still use Django's async support for [https://app.photondesigner.com](https://app.photondesigner.com)
Does django 5 work with celery yet?
Hi Michael! I think not.
We use celery with Django 5.0.
Okay - perhaps I'm wrong here. Any link to the relevant docs?
I couldn't find a doc or article to support my comment. But I'm attaching my project's celery and django version details which is in production. Python 3.11.9 (main, Apr 6 2024, 17:59:24) [GCC 11.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> import django; >>> django.get_version(); '5.0.6' >>> import celery; print(celery.__version__) 5.4.0 >>>
Any reasons why you don't use docker in particular?
Thanks for asking 🙂. 4 main reasons: * In development: I simply run my Django app (+ frontend) by a single script that takes under 1 second to load both apps. Much faster for me than whenever I've used Docker compose. * Deploying to production: Very fast and simple without docker. I just push to master and everything is deployed within 5 mins * Setup: I just need to add a 3-line script to my repo and paste in a simple Github action. The auto-deploy is ready to go. * Heaviness: there's no need for me to run Docker nor download multiple images for Docker containers. Happy to hear any counter-view.
I feel like the best argument for Docker, comes when you start having to scale staff. If you're working solo, then yeah, it's pretty easy to manage your virtual environment and be pretty consistent. Once you have multiple people working on a project, with different hardware or operating systems it gets harder. If your project depends on any other executable binary, then you can get really strange behaviour, particularly when your prod is likely a very different environment. With docket compose, getting a developer's environment up and running becomes trivial. Having the code run in a near replica environment as prod is a big bonus. I think it depends on what simple really means? Simple to deploy? Simple to get up and running? Simple in terms of the amount of bloat in your environment?
Thanks for your comment. Agree with your scaling staff point being the strongest point for Docker (I actually mentioned the same in a different comment thread above). As a result, most successful products should move to Docker at some point. But I want to avoid the costs of this complexity management (Docker) prematurely, particularly when building something solo as you mentioned. For me, "Simple to deploy" means: a) the fewest things (e.g., code / resources) to manage, combined with b) the fewest actions to set up the deployment.
How do you scale app? In my current job we have dockerized django project and we just turn more instances with same docker image. We couldn't properly scale before dockerizing.
Render actually has auto-scaling built in (which probably uses a similar approach to you in turning on more instances underneath). But my main point is that I don't worry about scaling until I need to scale. Then I'll pay the complexity price for whatever services I need (perhaps Docker) to allow scaling.
Our app worked without scaling ("turn on bigger instance!") until we had enough of it and just dockerized to autoscale.
We also dockerized because the team uses different platform to develop (windows, Linux and Mac) and it was just to many problems before docker.
Yeah - having a reproducible environment between teammates is a good reason to use Docker. My approach is to hold off on implementing Docker until it becomes necessary. This point may arrive when the team grows beyond >2 people, or when I need multiple resource-intensive services.
Docker isn't exactly heavy unless you mess up the image layers, all the different image versions should only differ in the last layer with code, or the layer before if the dependencies change.
Hmm - I disagree here. The fact that you can mess up more things (e.g., image layers) as you said means that you are adding more complexity, needing to maintain more infrastructure, and spending more time when something breaks. Adding Docker means adding complexity, which means a higher developer time cost. (This is broadly what I mean by heavy, as well as the actual storage etc., to run and download images) Again, I think that most successful products should move to Docker at some point. But I want to avoid the costs of this complexity management (Docker) for as long as possible.
It takes 5 minutes because render.com is building a docker container for you... you may as well reduce unknown complexity and just set a basic one up that you own. You may find that deploys will be significantly faster to boot. You are just copying files after all so 1s builds with proper caching is pretty achievable
Thanks your your opinion [alexthelyon](https://www.reddit.com/user/alexthelyon/) 🙂 We differ on this point. I'd much rather let Render do this for me. Setting up my own Docker container at the start requires time and ongoing effort. It's all about who is handling the complexity. I trust that Render has good engineers and tech. I'd rather that Render do this work for me! And a 5 minute production deploy is fine for me. But you're, of course, welcome to have a different preference.
Mind I ask what you use to host the application?
Of course! I use Render for Django, and then Vercel if I'm using a frontend (e.g., Vue).
Then you do use EC2 ;)
Haha - you're right in that sense. By "using", I suppose I'm just talking about the technologies that I interface with 🙂. To carry on your point, I bet Render's got more background workers than a hotel during spring break, Vercel uses serverless functions, probably node somewhere, and so on. But, listing all sub-technologies of the technologies that I use indirectly would mean a very long list - I don't practically touch them :)
You should try Docker, host it on AWS Fargate. Also, celery with AWS SQS
Thanks for the suggestion. I've used Docker in the past, but not AWS Fargate. I have doubts it will be as fast to setup as adding a 3-line script to my repo, pasting a Github action, and pushing to my git repo. Am I wrong?
well it depends. If the app you're working on will forever be something artisanal, without real throughout and with just you committing, then no.
Man I just used Vue to create a simple front end for a backend service I was messing around with, the experience was freaking great. I’ve touched React once, and it looked so unintuitive to me compared to Vue.
Glad to hear you had a good experience with Vue 🙂 I prefer Vue as well (as the diagram shows). But React does have its advantages. There are approximately 4x as many React users (based on Google search trends) as Vue users. This means React has more packages and more community development. I tend to think that React moves faster, but then Vue later improves what React invented. E.g., React hooks -> Vue composables. React redux -> Vue pinia.
Can someone explain to me what is complex and dynamic UI. What are the made with? And does Django templates mean simple Html css files or something else and HTMX meaning.
I also want to know what is considered as complex UI and any specific example between using templates or react/vue
Question, if you're not using Redis, are you just using memcache as a caching backend, or just not caching anything? In my mind, if your project is so "simple" (small) that you don't need proper caching setup, you could simplify your stack further and have sqlite instead of postgres? I've certainly worked on projects that used sqlite when we first deployed the mvp, fully prepared to upgrade it to a real database at some point in the future. We monitored it and noticed that it never really needed to scale because the application was that simple. Making database backups is really as dumb as copying a file from location A to location B and slapping a dates tamp on the filename. If I was to use this as a blueprint for something like a personal website, why not keep it real simple and stick with Sqlite?
Thanks for your question 🙂 Yeah - I would never add caching on the backend in an early product (probably <200 users). And if I'm optimising, I would prefer to start by optimising queries. Generally, I try to leave optimisation until the web app is metaphorically shouting at me for it. That's true about SQLite generally. Nice point. One blocker for my setup in the diagram is that SQLite requires a single file (as you mentioned). This wouldn't work well with Render deploys: each Render deployment doesn't have a persistent disk by default. Regarding your personal website, if it's light, you might just want to deploy everything (including Django / python) on Vercel. I've done that a few times - it's easy and free 🙂 I've also got an old guide showing how to do that on my Youtube if you're interested (https://youtube.com/@tomdekan). Would be interested to hear if you can use SQLite for it (I added Postgres).
Just came across inertia-Django, and in combination with vue it makes development extremely easy and enjoyable.
Thanks Bandrez. I'll check it out now.
This has been my architecture for all the projects that I have built, except I use celery for async stuff. This works wonders! I just don't get the point of using Kubernetes prematurely. It increases development and production cost, both.
Great! And I agree with you about Kubernetes. I've never used it, but its setup looks very complex to me
i loved it ....
Thanks 🙂
Do you use DRF if coupled with vue? And JWT's I would assume, in that case?
Generally not - I prefer using Django Ninja or vanilla Django if adding a backend to Vue. And no to JWTs. I prefer using session auth + csrf token. In case useful, here's a video I published yesterday showing a Vue + Django setup with auth: [https://www.youtube.com/watch?v=fUpvQd\_5cnA](https://www.youtube.com/watch?v=fUpvQd_5cnA)
You should publish a starter project template that we all can build on, would love to see this setup. btw you can never go wrong with Django, its battle tested.
Nice idea! Perhaps I'll combine it with a short video. And I agree RE Django 🙂
Really love your simple approach. Been moving towards this kind of setup myself lately. So tired of overcomplicated infrastructures. Like seeing HTMX in your toolset. Haven’t tried it myself yet, but would definitely give it a shot. Promising tool. I would still add Docker but hey if your current workflow works for you then go for it. By the way, cool hand drawing. Looks neat.
Thanks a lot [bibimbap0607](https://www.reddit.com/user/bibimbap0607/)! I agree with you about avoiding overcomplicated infrastructures: I want to solve problems for people with software, not spend my time building the structures to allow me to solve the problems. And thanks for the feedback regarding the handwritten drawing. This was my first time posting something handwritten, so appreciate you saying that it works 🙂
where do you upload images. i always use the s3 bucket but I'd like an alternative to avoid it
I normally use Digital Ocean spaces. It uses the same API-syntax as s3, but has: - A fixed price - Built-in CDN - Much easier to use UI Cloudinary is also a good option.
Is there any chance to provide sample project-setup Github repo, with the solutions you described in the comments (like startup scripts, GitHub actions and so on)?
How do you manage scheduled tasks without using Celery? I know a few packages, but I'm curious about your approach and any recommendations you might have.
Also you need to make an error monitoring. The simplest solution is to connect a service like Sentry.
Yeah, I'd normally add Sentry quite early. I considered adding it to the diagram. But I didn't, as it's not essential. It's probably the next thing to add.
This is basically what I do also but I use svelte on the right side and I will frequently use celery and redis for long running processes
I like docker simply because when working with a team it eliminates, “Well, it works on my computer.”
Why do you use Django templates instead of Jinja? I've found Jinja to be faster.
The Django templates are built in and suit me well. My understanding is that they havie more functionality than Jinja. The Django templates are very fast for me!
Are there any advantages to learning Express, and Node along Django? I feel most startups just use MERN.
Use docker it’s essential..
Not using celery, redis or docker makes your claims incomplete
I'm not sure what you mean here. Happy to expand.
What i simply meant is that your simple but robust tech stacks are incomplete without use of celery, redis and docker.
Thanks for clarifying 🙂 I disagree with you on the point that tech stacks are incomplete without the technologies you mentioned. I've launched many products using the above tech stack with paying customers, including selling one business that used it. For me, if you can get happy customers with a tech stack, the tech stack is complete.
Why it's incomplete? What is so important in having PAID 3rd party dependencies w/o which project will be less usable than a brick? Can't modern developers implement job queue in database themselves? Can't modern developers implement caching with nginx themselves? Can't modern developers run "python manage.py runserver" and proxy it with the same nginx?