First: Blitz looks like an awesome project! I really hope it grows in popularity, because a sane convention over configuration approach is extremely welcome in the JS world, imho.
«Blitz is for building tiny to large database-backed web applications (and in the future, mobile apps). It's not for building extremely large web apps, like Facebook.com.»
But say you do want to be able to become an extremely large web app in the long run. How would you go about decoupling from Blitz.js? Would it be an easy path, or a nightmare? Does Blitz.js take this into account, so that decoupling from it it is made easy (or atleast easier than with Rails)? I’m thinking especially about the potential to decouple from Blitz.js architecturally, to enforce modularity and separation of concerns as an app evolves.
I’m thinking about situations companies have run into with Rails such as:
I think every developers wet dream is to build something which would at least be able to become the next facebook. So having to make an up front decision that would preclude that possibility, or knowingly set oneself up for a potential decoupling or scaling nightmare, would be a barrier to adoption for Blitz. Especially since people have learned from experiences with Rails.
I think a sweet spot would be if Blitz gave startups a good architecture to start with, which could also be extended and remodelled later when the scaling phase (and multiple independent teams/microservices) necessitated it.
Would it be easy to «date Blitz but not marry it» (like Uncle Bob advised in general for frameworks)?
If the (gradual/total) exit is made easy, I think there would be no reason not to start off with Blitz.js!
It will take time to tell, but I fully expect Blitz to scale much easier and further than Rails.
1) By default we organize code by domain context (as shown in that Shopify blog post). So all your pages, queries, mutations, etc for a specific model or domain context all live together. And you can can easily reorganize these folders without any code changes.
2) You can certainly isolate domain contexts from each other with a defined public API, similar to the Shopify blog post. However we don't have this by default. But it is something we could explore adding in the future, perhaps as code scaffolding.
3) You can deploy a Blitz monolith via serverless. So each page, query, mutation, etc has it's own serverless function so everything can scale automatically and independently of each other!
The majority of your code is not tightly coupled to Blitz. Most of your code are normal react pages, and queries and mutations. Queries and mutations are plain async javascript functions, so they can be used anywhere by anything.
If a company gets really large, they will almost certainly want to use GraphQL. In this case, you would probably use less and less Blitz queries and mutations and instead use your GraphQL API in your pages. You can do this without having to move away from Blitz. A blitz app without any blitz queries and mutations is simply a glorified Next.js app that allows you to organize your code by domain context (Next.js doesn't allow you to do that)
Hopefully that helps answer your questions! :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
First: Blitz looks like an awesome project! I really hope it grows in popularity, because a sane convention over configuration approach is extremely welcome in the JS world, imho.
But say you do want to be able to become an extremely large web app in the long run. How would you go about decoupling from Blitz.js? Would it be an easy path, or a nightmare? Does Blitz.js take this into account, so that decoupling from it it is made easy (or atleast easier than with Rails)? I’m thinking especially about the potential to decouple from Blitz.js architecturally, to enforce modularity and separation of concerns as an app evolves.
I’m thinking about situations companies have run into with Rails such as:
avdi.codes/jim-weirich-on-decoupli...
engineering.shopify.com/blogs/engi...
I think every developers wet dream is to build something which would at least be able to become the next facebook. So having to make an up front decision that would preclude that possibility, or knowingly set oneself up for a potential decoupling or scaling nightmare, would be a barrier to adoption for Blitz. Especially since people have learned from experiences with Rails.
I think a sweet spot would be if Blitz gave startups a good architecture to start with, which could also be extended and remodelled later when the scaling phase (and multiple independent teams/microservices) necessitated it.
Would it be easy to «date Blitz but not marry it» (like Uncle Bob advised in general for frameworks)?
If the (gradual/total) exit is made easy, I think there would be no reason not to start off with Blitz.js!
Hey! Great questions!!
It will take time to tell, but I fully expect Blitz to scale much easier and further than Rails.
1) By default we organize code by domain context (as shown in that Shopify blog post). So all your pages, queries, mutations, etc for a specific model or domain context all live together. And you can can easily reorganize these folders without any code changes.
2) You can certainly isolate domain contexts from each other with a defined public API, similar to the Shopify blog post. However we don't have this by default. But it is something we could explore adding in the future, perhaps as code scaffolding.
3) You can deploy a Blitz monolith via serverless. So each page, query, mutation, etc has it's own serverless function so everything can scale automatically and independently of each other!
The majority of your code is not tightly coupled to Blitz. Most of your code are normal react pages, and queries and mutations. Queries and mutations are plain async javascript functions, so they can be used anywhere by anything.
If a company gets really large, they will almost certainly want to use GraphQL. In this case, you would probably use less and less Blitz queries and mutations and instead use your GraphQL API in your pages. You can do this without having to move away from Blitz. A blitz app without any blitz queries and mutations is simply a glorified Next.js app that allows you to organize your code by domain context (Next.js doesn't allow you to do that)
Hopefully that helps answer your questions! :)