Earlier quoted context omitted.
Shrug, databases have been doing the same thing since the 1970s (and consider also e.g. regexes). Turns out a flexible, expressive language for writing queries isn't always the most secure or performant thing to use as your wire format.
That's the exact argument against exposing GraphQL to the frontend.
We fell out of love with Next.js and back in love with Ruby on Rails
531–533 of 533 posts
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#532Is this article comparing apples and oranges? For example > loading the entire homepage only takes one query [if you're logged out] You can do this with Next.js SSR - there's nothing stopping you from reading from a cache in a server action? They also talk about Vercel hosting costs, but then self host Rails? Couldn't they have self hosted Next.js as well? Rails notoriously takes 3-4x the resources of other web frame…
> You can do this with Next.js SSR Yep! It'd be possible with Next.js. The difference is how it's organized. In Next.js with RSCs, we were fetching data for each part of the page where it's used (trending books, Live events, blog posts, favorite books). Each of those could be their own cache hit to Redis. One advantage of Rails is the controller. We can fetch all data in s single cache lookup. Of course it'd be possi…
This is my exact criticism of RSCs, they basically encourage the N+1 query problem. Basically nobody should be organizing their data fetches like this.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#533Earlier quoted context omitted.
imo, even if the only "interactivity" a web app has is just a login page, then even that alone is enough to warrant using a framework rather than doing direct DOM manipulation (or even worse, full page refreshes after a form submit). It's not about using the most powerful tool always, it's about knowing how to leverage modern standards rather than reinventing and solving problems that are already solved.
> ...a web app has is just a login page, then even that alone is enough to warrant using a framework rather than doing direct DOM manipulation (or even worse, full page refreshes Maybe, but it doesn't necessarily need to be a SPA framework though. There are simpler libraries/frameworks like htmx that considerably reduce complexity and also let you avoid direct DOM manipulation.
Yeah, the debate about which framework is best is like debating which programming language is best, in that they all have pros and cons, that can be debated endlessly.
However, in general, whatever's most popular is a strong signal (like a crowd-sourced signal) that it's probably indeed "the best" all around, which are two words that can also, of course, be debated endlessly based on one's personal definition of "best".