5 ms·
My main resolution for 2024 is to figure out my side project/SaaS boilerplate. Boilerplates are opinionated, and my opinions are so out of whack that I can't us
by anyfactor 3y ago
My main resolution for 2024 is to figure out my side project/SaaS boilerplate. Boilerplates are opinionated, and my opinions are so out of whack that I can't use any other folks' opinionated boilerplate. The challenge is the opinion part of boilerplates and the last "S" of SaaS, which stands for service.
I can't spend more than $5 a month, and I don't want to use anything other than Python. I think in Python and it provides the absolute frictionless path to bring my ideas to life. I wish I had the same feeling about JavaScript, and that would have certainly made my life easier. But this is a compromise I am happy to accept as part of my identity.
The stack I am thinking of right now includes:
- Firebase: I chose this because Stripe integration, real-time database, Firebase functions, documentation and Firebase authentication.
- Vue/Nuxt + BootstrapVue: This is for basic front-end stuff.
- VM/VPS: This will be used to host the operational logic.
- Python: This is the core operation. Firestore operations and management will have the real database in PostgreSQL/SQLite to reduce calls to Firestore.
- FastAPI: This will be used for communicating with Firebase via API. User calls will be relayed via Firebase to FastAPI. It may be slower, but it will make my life a bit easier.
- NGINX: Plan is to have one FastAPI project per project. I think NGINX is going to be helpful here. Also, I would like to do some firewall configuration.
I still have a lot to figure out. One thing I am trying to determine is if I really need Firebase here because I already have a backend there.
I want to build an API-first system and Unix philosophy-inspired systems where multiple API services or Python modules do one thing only and are linked to each other. The goal is to create common operation Python modules, so I can quickly develop POCs by combining boilerplates with parameters and write the core logic in the minimum amount of Python code. The whole plan is to keep trying different approaches until I find one that works.
- la_fayette 3y agoLooks interesting. I use a similar stack. What made things a lot simpler for me was packaging the python app inside a nginx unit docker image. CI/CD was highly simplified...
- anyfactor 3y agoI will look into it. Thank you very much. My current plan was to SSH and develop inside the VM/VPS. VS code's remote desktop extension makes this quite easy.
- hot_gril 3y agoConcurrency handling and package management alone got me to switch from Python to JS for backends.
- anyfactor 3y agoFor both these issues the answer is Go. I found Go more fun than JavaScript. I won't write Go from scratch rather I will rewrite Python to Go when I start hitting walls. On concurrency, I hope FastAPI will help on that. But I am horrible at writing concurrency code and that is why I don't enjoy writing JS. But from my limited experience, I enjoyed goroutines. Package management, for mission critical stuff I have to straight up use Go binaries to be honest. I didn't mention Go in my parent comment because it will be used as a langauge to rewrite solutions and for that to happen I need to make atleast a couple hundred dollars a month to make that investment.
- hot_gril 3y agoI'd use Go if it had exceptions and async/await. The Goroutines are great for "systems" type software but overkill for web backends.