3 ms·

They often do that because of the REST/CRUD chokehold where the backend does a bunch of stuff, squeezes the resulting data into extremely basic primitive action

They often do that because of the REST/CRUD chokehold where the backend does a bunch of stuff, squeezes the resulting data into extremely basic primitive actions (e.g. GET, POST, PATCH, DELETE), forcing the frontend to recreate a complex state all over again. GraphQL tries to solve this, and usually frontends that rely on that avoid a lot of that duplication of the backend, but devs sometimes manage to scream up even that. If we kill REST, a lot of the complexity around frontends would be reduced significantly. You don't even need GraphQL or RPC protocols to do that.

skydhash 2y ago
REST is not a browser concept, it’s just a pattern. There’s no need to “kill” it. The HTTP protocol is more than enough to interact with a server that store resources and a client that display them. If you’re sure you need another set of verbs and nouns, use http as a tunnel.
- ravenstine 2y ago
  > REST is not a browser concept I didn't say that it was specifically. REST is still a convention that is usually tied to and influenced by HTTP and its methods. It doesn't necessarily have to be that way exactly, but that's how many web applications are typically written. > There’s no need to “kill” it. We don't necessarily need it around either. > If you’re sure you need another set of verbs and nouns, use http as a tunnel. That is somewhat along the lines of what I'm suggesting. REST is not necessarily better than an API that just takes POST requests in a way that serves the application's needs directly rather than some abstract standard that homogenizes data in ways that require extra work to be done. For some odd reason, many frontend-oriented developers look at me like I've got bugs crawling out of my ears when I say this, yet the idea of allowing the server to do the bulk of the work is both old and resurging in popularity (e.g. Hotwire, LiveView, HTMX).

skydhash 2y ago

REST is not a browser concept, it’s just a pattern. There’s no need to “kill” it. The HTTP protocol is more than enough to interact with a server that store resources and a client that display them. If you’re sure you need another set of verbs and nouns, use http as a tunnel.

ravenstine 2y ago
> REST is not a browser concept I didn't say that it was specifically. REST is still a convention that is usually tied to and influenced by HTTP and its methods. It doesn't necessarily have to be that way exactly, but that's how many web applications are typically written. > There’s no need to “kill” it. We don't necessarily need it around either. > If you’re sure you need another set of verbs and nouns, use http as a tunnel. That is somewhat along the lines of what I'm suggesting. REST is not necessarily better than an API that just takes POST requests in a way that serves the application's needs directly rather than some abstract standard that homogenizes data in ways that require extra work to be done. For some odd reason, many frontend-oriented developers look at me like I've got bugs crawling out of my ears when I say this, yet the idea of allowing the server to do the bulk of the work is both old and resurging in popularity (e.g. Hotwire, LiveView, HTMX).