Thanks for sharing your journey @jamesmillerburgess very insightful case study.
Correct me if Iâm wrong, but that product doesnât seem to be a typical SaaS application, it looks more like an online public portal for a shipment company, perhaps thatâs why an optimized public static site generator with a GraphQL API gateway and microservices backend are better fit, although Meteor development speed, it seems, was the needed catalyst to get the project approved. An ideal framework, in my opinion, would allow you to start as tightly coupled full-stack in the early stages yet has the right flexibility to decouple the clients from the API as things evolve, and I think Meteor is heading in that direction, the frontend and backend are pretty much decoupled now but you start as full-stack to ensure quick delivery.
For the re-build times, I agree, itâs a pain point especially for large React projects. The issue is that these modern front-end frameworks (React, Vue) do a lot of work on refresh, unlike Blaze (handlebars) for example. That is why those communities needed HMR, but for that, Iâm rooting for the HMR API initiative by @zodern, and as I said in that thread, the community need to support that effort even fund this initiative, I think itâs critical yet solvable issue.
Lastly, you can still use Gatsby, NextJS, CRA with Meteor as a backend, weâve several apps like that, unless of course, youâve the resources internally to refactor and manage the backend, DevOps, and various integrations completely in-house or the appetite for vendor lock-in with things like Firebase.
But once again, thanks for your contribution and sharing your story, I think it was very insightful.