Request validation is the probably the most boring but critical layer of any web framework. Today I will show you how to do it right in gin framework in golang.
Simply because Rails is not designed to solve frontend problem where complex user interactions and client side state are included, not to mention partial rendering and transition. Rails is a backend framework after all, spitting a HTML is all it can do in terms of a frontend part. Just don’t know why you think you can solve all the modern frontend user interaction with a backend framework like rails and Django,,,,,,,,,,,,,,
Github, Hey, and so many others are examples of Rails applications with complex interactions. Server templates and partials rendering doesn't mean "I reload the page on every click and can't write any javascript because I only do ruby". You have tools for doing dynamic html too, just not your usual redux/rxjs/thunk/observable/typesafeactions stuff.
Agree that Django is a backend framework, but Rails is not, you can certainly do frontend in Rails. Just not SPAs, but you need a more open mindset for understanding how it is intended to be used.
Of course, if you are building Google Docs or Maps then you're probably better with a SPA framework. But not for 90% of applications out there which are just CRUD apps.
Because in 21st century, not everyone likes a website with a lower-bar rendering experience… SPA or hybrid rendering is just plain better, but I get the point where time is limited for human being, so if modern frontend is hard to grasp for you, perfectly to stick with old tech. Pretty safe.
It is not for your end users, just for the developers building it because it has a better dev experience. As a proof of this try most sites out there which are built as an SPA vs the ones built with more traditional approaches.
Also, building SPAs is incredibly more difficult and time consuming, that's why most of them work like shit.
Backend is probably a lot easier than the frontend, which is why you can see service like hasura and supabase. Backend is a highly patternized work, which is why it can be low to no code, whereas front end as a service is merely just deployment as a service.
> The ORM layer is not a DSL but some nicely done JS/TS functions
You are splitting hairs here as far as I'm concerned. You need to learn the an API so you can do 70% of your queries. Then you need to learn SQL so you can do the other 30% of your queries and actually understand how to design a database. The queries that the "nicely done JS/TS functions" are replacing are almost always the simplest, most basic queries. Do you really need a special query language to say `select * from widgets`?
The big problem with every ORM layer is you are essentially learning a disposable language. Every ORM says it's the best way to Query ever, and yet here we are, 5000 ORMs later and SQL is still an essential skill for developers.
