3 ms·
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 li
by ericb 5y ago
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.
- SahAssar 5y agoGoing 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?