4 ms·

> without really saying why it sucks I think you've heard quite a lot. There is a reason why people invent GraphQL or BFF In a nutshell, I think today's Web A

by est 2y ago

> without really saying why it sucks I think you've heard quite a lot. There is a reason why people invent GraphQL or BFF In a nutshell, I think today's Web APIs can't be simply descriped as a bunch of "resources" or "states" (which Roy Fielding used in his PhD paper about REST). A database system like PG is much more complex. The SQL itself is an API and comes with a data transfer protocol. You get a leaky abstraction by mapping it to REST.

dventimi 2y ago
> There is a reason why people invent GraphQL or BFF Sure, it was because creating servers--REST or otherwise--with code (looking at you, Spring, Django, and RoR) is such a slow, laborsome task that rapidly iterating frontend teams got tired of waiting around for ill-fitting backends to catch up, that they built their own abstraction layers: BFF and then GraphQL. That wouldn't be a problem if backend teams were as nimble. Things like PostgREST, Prisma, Hasura, etc. allow them to be that nimble. Ironically, that brings folks like Wundergraph full circle, where they relegate GraphQL to being a development language for defining REST endpoints. If you're going to use a query language like GraphQL to define your REST services, then you might as well use the OG query language SQL to define your REST services, if circumstances allow. That's precisely what PostgREST does. So, yes, I have heard a lot arguments for why REST sucks. I just don't think they apply anymore (if they ever did).
- est 2y ago
  so why not just pipeline sql n' everything inside h2? Or else you have to deal with shit like > Essential for the architecture is the conceptual split between data retrieval via HTTP GET and data-modifying requests which use the HTTP-verbs POST, PUT, PATCH, DELETE The whole argument from OP's article is about the god damn HTTP verbs, I totally blame REST on this. Just use the CONNECT or PROXY verb for the sake of it and move on.
hgyjnbdet 2y ago
But surely that abstraction, leaky or otherwise, is there to prevent (hopefully) the security issues related to SQL?

by est 2y ago

dventimi 2y ago

> There is a reason why people invent GraphQL or BFF Sure, it was because creating servers--REST or otherwise--with code (looking at you, Spring, Django, and RoR) is such a slow, laborsome task that rapidly iterating frontend teams got tired of waiting around for ill-fitting backends to catch up, that they built their own abstraction layers: BFF and then GraphQL. That wouldn't be a problem if backend teams were as nimble. Things like PostgREST, Prisma, Hasura, etc. allow them to be that nimble. Ironically, that brings folks like Wundergraph full circle, where they relegate GraphQL to being a development language for defining REST endpoints. If you're going to use a query language like GraphQL to define your REST services, then you might as well use the OG query language SQL to define your REST services, if circumstances allow. That's precisely what PostgREST does. So, yes, I have heard a lot arguments for why REST sucks. I just don't think they apply anymore (if they ever did).

est 2y ago
so why not just pipeline sql n' everything inside h2? Or else you have to deal with shit like > Essential for the architecture is the conceptual split between data retrieval via HTTP GET and data-modifying requests which use the HTTP-verbs POST, PUT, PATCH, DELETE The whole argument from OP's article is about the god damn HTTP verbs, I totally blame REST on this. Just use the CONNECT or PROXY verb for the sake of it and move on.

hgyjnbdet 2y ago

But surely that abstraction, leaky or otherwise, is there to prevent (hopefully) the security issues related to SQL?