Having experimented with something that wasn't GraphQl, but used similar concepts (let the front-end fish out whatever it wants from the back-end), it seemed like paradise at first, but then:
1-We wanted to make schema changes on the back-end, but the front-end queries were tied to it.
2-We had no great way of knowing what was safe to move, and what wasn't. Sure, we could look at requests, but we have multiple environments we support. What was our API, and where did it end? Now it was the entire database!
3-When we had to source data from elsewhere, or provide it via logical abstraction, we ended up piling hacks on top of the data structure's "API" from the back end that was now replicated in the front-end in order to "maintain it.
Separately, on REST itself, it gets kind of weird if you want to map upsert onto REST, but upserts are useful, and sometimes a requirement. The "single resource path, multiple operations" gets diluted a bit.
Going to mention postgrest a bit, which the article also mentioned via supabase.
> We wanted to make schema changes on the back-end, but the front-end queries were tied to it.
The recommended way is to expose SQL views, that way you can modify the tables as long as what you return is compatible.
> What was our API, and where did it end? Now it was the entire database!
With postgrest the api is the schema you expose. That can be the raw tables, it can be views, it can be SQL functions. You get an openAPI definition for how to use it and what is in it. I like that.
> it gets kind of weird if you want to map upsert onto REST
Is upsert not just a PUT? Or do you mean if you have generated paths like /article/{id} and generate the id serverside but still want to upsert from the client?
Because REST assumes that every action you could ever want to take is acting upon some object. So you rename /login to /users/login and pat yourself on the back. Then you realize that the silver bullet failed to get you one inch closer to your goal and you turn against it. Then you go look into GraphQL and spend weeks perfecting your schema. Then you realize you wasted your time yet again, and you go just use whatever Google uses (gRPC) like you should have in the first place.
I generally find that the subject-verb idea is powerful, well represented in langauge, & helps form a better groundwork for others to elaborate the pattern on top of. I also don't see grpc or whatever as a good counter-answer/clash to this kind of anti-meaning nihilism: api design there often ends up facing many of the same quandries.
Not even on the map right now, but interesting to me, is a thicker front end alike GraphQL sort of systems, but using REST.
There's no reason we can't have a good intermediated rest client, no reason we can't re-emerge many of the same ideas of the client-side data-store that GraphQL happens to promote. Ideally there'd be some good service worker implementations, linked-data powering the thing.
As usual though, the radical though is rarely channeled into improving the status quo, revamping it, reconceptualizing & reframing it: radical thought starts over, rebuilds, ignores the current, breaks for something new, fresh, unconstrained.
> As usual though, the radical though is rarely channeled into improving the status quo, revamping it, reconceptualizing & reframing it: radical thought starts over, rebuilds, ignores the current, breaks for something new, fresh, unconstrained.
1-We wanted to make schema changes on the back-end, but the front-end queries were tied to it.
2-We had no great way of knowing what was safe to move, and what wasn't. Sure, we could look at requests, but we have multiple environments we support. What was our API, and where did it end? Now it was the entire database!
3-When we had to source data from elsewhere, or provide it via logical abstraction, we ended up piling hacks on top of the data structure's "API" from the back end that was now replicated in the front-end in order to "maintain it.
Separately, on REST itself, it gets kind of weird if you want to map upsert onto REST, but upserts are useful, and sometimes a requirement. The "single resource path, multiple operations" gets diluted a bit.