5 ms·

I hear this sentiment echoed a fair amount without really saying why it sucks. And sometimes I wonder if the writer omitted it for brevity, or is actually just

I hear this sentiment echoed a fair amount without really saying why it sucks. And sometimes I wonder if the writer omitted it for brevity, or is actually just echoing something they read on the internet without really believing or understanding it themselves, because saying something sucks where clearly other people don’t know that it sucks (or else why would it be so popular) positions the writer in a dialogue as mysteriously knowledgeable. Hard to argue against points you don’t even know the other person is making and all.

tucnak 2y ago
Yeah, he omitted it for brevity alright & you would just have to deal with it. Some day you might, too, become Mysterio Mister Knowledgeable
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?

tucnak 2y ago

Yeah, he omitted it for brevity alright & you would just have to deal with it. Some day you might, too, become Mysterio Mister Knowledgeable

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?