Here's how i replace Rails with the "modern stack":
- Compile Graphql schema into Typescript typings + Fragments for "Active Record"
- React Hooks as controllers action.
- React Suspense for HTML rendering.
- Apollo for graphql caching
- ExpressJS for middlewares.
- @reach/router for routing.
- @loadable/component for code splitting.
- Serverless for API.
I missed Rails, too. But i found that the "modern stack" is not bad at all. It just needs more time to investigate to find out the best way to reuse features.
Your post is a perfect example of why the "modern stack" is a horrible developer experience (and lets be honest, probably crummy user experience) compared to Rails.
I hope the DX will get better soon. But this stack beats rails on scalability, universality, user experience, and many more. It's a trade-off that i found worth the effort.
This sounds exhausting! But I'm betting there's some pretty solid benefits or you wouldn't do it. Could you expand on why someone might pick this a little?
I guess this just seems like a massive amount of hoop jumping that, from the outside, looks like OCD levels of premature optimization for future demands that might well not occur.
Put differently: how much more time and energy would you have had to work on your MVP if you had just used Rails?
Actually, the time spent to setup correctly all the toolings is much more than the MVP itself.
The ratio is about 6/1.
Once setup, it took me about 1-2 weeks to complete a MVP.
Want new feature ?
- Add a graphql API (if not exists) and compile to Typescript typings.
- Develop and deploy a React Component for that feature.
Let’s talk in 6 months as those packages evolve and diverge. While rails core team does the work of maintaining all the packages as a consistent whole.
You can’t “take care of it with responsibility” if you have a lot of dependencies since you don’t control the library’s maintenance, or how it evolves with other libraries. So then you have to chose between adding dependency (with very real maintenance downsides) vs writing things yourself and reinventing things that should be solved.
Further, being stuck in a box also means that the community can rely on that very box and add more extensions with the architecture of the box in mind. A box gives assumptions to build on top of. Sure if you really really need a triangle it’s painful, but then you should ask, do I really need a triangle?
I think the real insight of DHH is that most web apps are not as “unique” as developers would like to believe and that the harmony that comes with conventions, the speed that comes with a unified end to end integrated system, and the focus developers gain for actual impactful choices when many unimportant choices are made for them is an amazing improvement.
He said recently, that insight is as controversial today as when he launched rails, and he is surprised more rails competitors haven’t emerged.
I think the first end to end GraphQL > Single Page App framework that has a similar level of integration to rails will dominate.
Actually, this stack is deployed as a serverless function !
"Serverless for API" means i could use any language to develop API.
Serverless provides better scalability in my opinion.
- Compile Graphql schema into Typescript typings + Fragments for "Active Record"
- React Hooks as controllers action.
- React Suspense for HTML rendering.
- Apollo for graphql caching
- ExpressJS for middlewares.
- @reach/router for routing.
- @loadable/component for code splitting.
- Serverless for API.
I missed Rails, too. But i found that the "modern stack" is not bad at all. It just needs more time to investigate to find out the best way to reuse features.