Is my tech stack ok?
Hey IH!
I've been working a a side project for a couple of weeks now. It has been really interesting to learn new things and adapt to old knowledge.
The product I'm building is a simple webapp, in which the members of a sports club can book hours to do sports on site and such. It's not that big of an app, perfect for me to do in cooperation with another programmer (I'm a CS student).
I'd like to get some feedback on my 'tech stack'. It's as follows:
Backend: Python Flask
Frontend: Angular
Database: PostgreSQL
All three of these services are split up into their own docker containers. We did that, to make development more comfortable. As my partner will mostly be working on the frontend and I'm more of a backend guy i figured it'd be a great idea to let everything he needs startup with a simple docker-compose command.
Does an architecture like this make sense for a production scenario? Should these three services be split up into docker containers if a single customer buys our product and we host these three services on a VPS for them?
I'm already far in the project so changing the whole tech stack is not really an option, but I'd love to know your opinion. Are we on the right track? Is what we're doing efficient? It's my first project like this.
Thanks in advance for your help and your opinions!
Best wishes,
DO.NOT.WORRY.ABOUT.ARCHIECTURE.EARLY.
I am a highly technical developer that will often get caught in analysis paralysis with tech stacks. I think your tech stack looks awesome, and it keeps things simple and clean. Build it out, vet it, and get people interested. Once you start scaling, that's when you can worry about architecture. With the question you are asking, you sound similar to me, so I recommend focusing on marketing and the business side, and worry about architecture later on. You're doing awesome!
Thanks for your kind words! I'll definitely keep that in mind!
Agree with him ^, once you find a good market tho, u guys r gonna crush it
I am fully agreeing with you.
@Thomas18 If you are not able to ship something usable, you can spare the work (maybe apart from some educational purposes). Think about your architecture after you have validated the idea. And even then there is no need to shoot straight away with the big guns ;-)
Your highest priority should be getting something out there, not worrying too heavily about your architecture. Specifically, you should be concerned with getting business logic written, and anything that gets in the way of that is wasting your time.
I'm, of course, biased, since I'm writing Nodewood, a SaaS starter kit specifically for the purpose of skipping past the "What architecture do I use? How do I do user authentication? How do I charge money?" stages, but I wouldn't be sinking all this time into making this if I didn't believe it was the best way to start a new SaaS.
That said, if you're strongest in Python, it won't help you specifically, since Nodewood is 100% JavaScript. But if you are interested in using something to skip you past all that extraneous wasted time, there are absolutely other starter kits out there, potentially more-tailored to your preferred languages. In Python, for example, there's SaaS Pegasus, written by indiehacker @czue.
At any rate, definitely look into using a starter kit (or "boilerplate"). It could save you a lot of time!
As @alchemist has mentioned, build the MVP and put it on a cheap $5/mo Digital Ocean droplet. Don't think ahead of yourself.
I made this mistake with as SaaS of my own. I had a Docker DO droplet that talked to a managed Postgres DB. Since I don't have many users now I decided to just add a Postgres container to the droplet and migrate the data. It's a little risky but now I avoid about $30/mo extra.
That's good to know. Thanks jator!
For that app, you have nothing to worry about. You can put everything on the VPS and have the DB on that box as well for a long time.
I wouldn't split it into separate services unless somehow you have so many engineers that you need to split them into separate teams.
Thanks alchemist? So you're saying i shouldn't split it up into three docker containers?
I'm saying I wouldn't. You can and it's fine if you do, but it's not necessary and it may be more work.
In general, the advantage of microservices is for ease of scaling team size.
Why do you think its not ok?
If it is doing what you need then its more then ok, its perfect.
Now with that said, I would complement that you could break the backend into multiple pieces, microservices, that way if you grow, you will have an easier path into making changes, swapping the tech you using, etc, not sure how Python Flask helps you there, since I am not familiar at all with it, put if possible you should consider it, even at whatever point you are.
@axegon mentioned about Flask not being the most performatic of the available frameworks, but as long as you are not persisting state on each instance, you can always grow sideway which will increase you monthly costs but hopefully you will be making money to pay for small jumps. Because of that I would not worry about the performance of that particular framework.
Hi oakcool,
thanks for taking the time!
Oh, I'm not thinking the tech stack is bad or anything, just wanted some to know if I'm on the right track, you know?
Especially with the modularization part with the docker containers. Thanks for your answer on that.
The thing with growing sideways shouldn't be a problem.
What do you mean with: "As long as you're not persisting state on each instance " ?
The idea is that when you want to grow sideway (Adding more instances of your service), you have to stateless or have the state in a central service (i.e. SQL).
This has to do with routing, lets say UserA lands on Container1, and while he is there doing his things, the load on that container grows, and he has to be redirected to a new Container2, if his state was all in Container1, he would have to start over, so for example, very bad example by the way, lets say he spent the last 4hrs writing his next best selling novel, and for some weird reason, the latest version of his book is stored in a local session or file, when he attempts to hit the server again and he was redirected to Container2, that session or file wont exist there, so his page is gonna be blank.
While that was a horrible example, I just want to show how bad it can be, but this applies to all sorts of things, carts, login, any and all data that could be stored in a server as memory or as written files. The cool thing is that as far as I know most, if not all, frameworks allow you to configure and change the behavior so you store that data in a shared location, in ASP.NET you could store in a Session server, SQL, and I believe there are a few other ways, I personally like the SQL one for its convenience, you run a script on your already existing database, and point you server to that, done.
After that is done, it does not matter which container the user is on, or will be on, his data is hosted in a central location to all containers and can be accessed from all of them.
I hope this helps ilustrate what I meant.
<KeepCoding/>
Flask is a good option on the account that there's a lot of documentation available and it's widely used and incredibly stable. Mind you, it is one of the slower python frameworks out there and others will run in circles around it.
Postgres - it's no secret that I'm a huge fan of Postgres so yes. Surely, there are scenarios in which there are better alternatives but overall as far as open source databases go, It's my favorite by a long shot.
Angular - meh... I hate javascript and all it's flavors with a passion so no opinions there.
Containers are a good idea simply because they provide isolation and you have a much lower risk of crashing everything when you decide to do an os upgrade. If we are talking about a small number of customers, a low-end vps is a good and cheap option. And if your product becomes big(hopefully), you have all the basis for migrating the project to a kubernetes cluster.
The one thing I would add in advance is some caching service, even if you don't use it initially, it's best to have something lined up if things start going south. Another personal favorite of mine is redis - fast, efficient and adds a ton of options beyond simple key-value stores - lists, maps, counters, pubsub and so on. And given that you are using python, the client for python is really good and comes with everything included.
Good luck.
Hi axegon!
Thank you so much for your feedback and for your tips!
I'll definitely take a look at caching and redis.
Stack looks good, as for the Angular front-end, it's static so you could host it for free on services such as Netlify, GitHub Pages, or Firebase Hosting!