We believe most apps should start as a monolith. In the early days of an app, fast development speed and getting users is way more important than having a perfectly, infinitely scalable architecture from day 1.
That said, Blitz already greatly improves on monoliths like Rails because Blitz can be ran serverless where each API endpoint is its own serverless function. So it's already serverless ready!
And over time we will be making Blitz more powerful, flexible, and well suited for enterprise environments and more complex backend architectures.
To clarify, there is an API, it's just abstracted into a compile step. So there's some magic there, but it's very minimal and easily inspected.
Most apps should not start as a monolith. However the first time a senior engineer is attempting to grok microservice design patterns, definitely they should go that route of decomposing monolith into microservices. Training wheels aren't needed forever unless they're doing a poor job implementing those patterns, training/selling their teammates on it, or failing to convince their bosses on the efficacy of microservice architecture.
If that's the case, monolith away: let the team balloon around that beast, increase the cost of technical debt, increase the ramp-up time for new engineers, slow down & formalize those release cycles & code freezes, and let's party like it's 2011!!
We believe most apps should start as a monolith. In the early days of an app, fast development speed and getting users is way more important than having a perfectly, infinitely scalable architecture from day 1.
That said, Blitz already greatly improves on monoliths like Rails because Blitz can be ran serverless where each API endpoint is its own serverless function. So it's already serverless ready!
And over time we will be making Blitz more powerful, flexible, and well suited for enterprise environments and more complex backend architectures.
To clarify, there is an API, it's just abstracted into a compile step. So there's some magic there, but it's very minimal and easily inspected.
Most apps should not start as a monolith. However the first time a senior engineer is attempting to grok microservice design patterns, definitely they should go that route of decomposing monolith into microservices. Training wheels aren't needed forever unless they're doing a poor job implementing those patterns, training/selling their teammates on it, or failing to convince their bosses on the efficacy of microservice architecture.
If that's the case, monolith away: let the team balloon around that beast, increase the cost of technical debt, increase the ramp-up time for new engineers, slow down & formalize those release cycles & code freezes, and let's party like it's 2011!!
Microservices is a pattern to solving a particular problem. It's not the hammer for every nail.