Time for #DEVDiscuss โ right here on DEV ๐
How To Build a Scalable SaaS Backend in 10 Minutes With 100 Lines of Code ๐
JS for ZenStack ใป Jun 21 '23
Inspired by @jiasheng's Top 7 post, tonightโs topic is...developing SaaS (software as a service) products!
In their post, @jiasheng shares about their project @zenstack and how it can be used to build "a scalable SaaS backend in 10 minutes with 100 lines of code" ๐ฅ
Itโs hard to build a scalable SaaS system. Having been involved in the development of four commercial SaaS products at my previous company, I've come to realize the multitude of complexities that arise compared to typical consumer products. Among these complexities, one prominent area lies in the intricate realm of permission control and access policies.
Questions:
- What's more important to you when building a SaaS: reducing complexity, or having lots of features and functionality?
- How have you approached access control with SaaS apps in the past?
- How does building SaaS at the startup level differ from working on a SaaS at the larger, commercial level?
- Any triumphs, fails, or other stories you'd like to share on this topic?
Top comments (4)
Let me throw a brick to get you started ๐
In my humble view, I believe that reducing complexity does not necessarily conflict with adding functionality. However, it does demand expertise, knowledge, and skill to pursue simplification effectively. Check out our own experience shared by my partner @ymc9
For Most of Us, Simplification Rules
ymc9 for ZenStack ใป May 7 ใป 4 min read
Yes, we have built more than 5 SaaS products. There are some common things we have to implement every time with different stacks like:
Itโs not only tedious but also hard to make it right. Thatโs one of our own pain points and the big reason why we built ZenStack.
Based on my personal experience, I have found that at the startup level, prioritizing speed is crucial as it allows for rapid validation of product-market fit. This agility enables quick adjustments and changes in direction if needed. However, at the commercial level, you need to put more focus on stability and extensibility because there are people running business on it already.
If you are planning to build a new product, you could verify peopleโs responses before building it. In one of our cases, we simply created a website with the normal registration process as if itโs already fully launched. Then we did SEM to get traffic to our website to see whatโs the click rate and conversion rate for our website. If it doesn't meet the expectation, we know we went in the wrong direction. Of course, for the people who registered, you should tell them the truth and give them some credit as your early adopters. Most people are actually very nice about it.
Thanks for the valuable insights ๐
Would be interesting to hear your "unopinionated opinion" on possible overheads (and future maintenance hassle) of adding such kind of new abstraction level over the codebase (as ZenStack, or refine, for instance) as compared to kinda "barebones" way (with all the mutual tradeoffs).
Thatโs a good question. Iโm trying to be unopinionated, but as Iโm the creator of ZenStack, youโd better make your own call. ๐
In my humble view, the major overheads of adding an abstraction are:
But coming to the trade-off, I would think it has to be opinionated for each individual. For example, personally, I think itโs painful to write raw SQL and maintain it, whereas not for some people; They might find running a generation command every time to be cumbersome, whereas I do not. The more general case is that I consider type safety to be of utmost importance, although I am aware that some individuals, such as the founder of Basecamp, still prefer JavaScript over TypeScript:
twitter.com/dhh/status/16550766687...
Also, I canโt deny that trust is also a big factor that also varies with each individual. Itโs what we keep working on and sometimes it takes time.
As always, there is no one-size-fits-all approach, and you have to make your own trade-off. For me, thatโs the beauty of the software development world.
yml
file(little crude but worked).My suggestion for anyone would be "Don't get disheartened if lot of your hard work is scrapped or goes unnoticed"