[asim]

It goes back to, what is a framework and what qualifies as a big framework here. I think classic rails isn't the fit, but something that's an extension of gRPC definitely works. What gets handcrafted is a lot of layers around gRPC or far more stuff around HTTP.

When I'm working on personal projects, frameworks don't make sense for me. When I'm trying to engineer something at scale e.g https://m3o.com then I need that standardisation at the platform layer, the framework layer, the API layer.

[pdpi]

When you're building something "at scale", there'll be business logic API services, cache services, routing/dispatch services, and many other such things.

What I'm saying is that I find business logic-centric API services to be a good fit for larger frameworks that take ownership of more of the low level logic, and I don't find Go to be a good fit for those, at all. Inversely, I find Go to be a much better fit for the more "technical" services (provided we're not at the must-squeeze-every-ounce-of-performance C++/Rust level of requirements), but I also don't want a framework getting in the way.