News for hackers. Stuff that matters.
Re:Rails adds support for Fiber-safe ActiveRecord Connection... by midrus on Thursday February 24, 2022 @01:13PM (#30458144)
Also, note that when not going the microservices/spa/kubernetes route, the alternative is not "old style reloads on every click and jQuery spaghetti", I'd say that's equally as bad.

Nowadays there are alternative middle ground solutions such as Livewire, Hotwire, LiveView, Unpoly, Htmx, etc which provide a great way to organize the code and keep it maintainable.

Re:Rails adds support for Fiber-safe ActiveRecord Connection... by treis on Thursday February 24, 2022 @04:27PM (#30460539)
I think these are all bad ideas on the other extreme. Once you incur the cost of a round trip to the server the additional latency due to sending HTML instead of JSON is pretty close to 0. You really only need something like Turbolinks to avoid a full page reload/render.

Amusingly enough at $Current_Job the JSON we send back that is larger in size than the HTML it's rendered into. We'd likely have better performance doing all server side rendering + Turbolinks.

Re:Rails adds support for Fiber-safe ActiveRecord Connection... by midrus on Thursday February 24, 2022 @04:38PM (#30460674)
Yeah, this is the case I was talking about with the 90% of cases I was referring to.

At a previous job, we had a many, many thousand lines codebase of typescript, redux, observables, epics, thunks, custom server API libraries, websockets, Elixir backend, Kafka to communicate with other microservices, etc, etc..for...a frigging signup wizard.

Which then failed in so many stupid ways, had almost no server validation (everything unexpected was a 500) and it took days to do the smallest of the changes. But hey, don't dare to suggest doing this with Laravel would take 2% of the effort because you'd be crucified in the next frontend guild meeting.