4 ms·
A few weeks ago, I was pondering over the pain involved in designing and implementing a REST api, for an simple backend. After much deliberation, it was clear
by kumarvvr 7y ago
A few weeks ago, I was pondering over the pain involved in designing and implementing a REST api, for an simple backend.
After much deliberation, it was clear to me that I dont understand the HATEOS part of REST and that I have been using the url as a filter and get or post parameters as variables for calling some functions on the backend server. And often, for an SPA, I would have to do multiple queeies in quick succession.
Then I realised, why cant I simply group those multiple query calls into one giant post request, with custom codes for querying or mutation, send a post request with a body that is a DSL i have thought of, and let my backend decode that DSL and send the replies. No longer would I be limited by URL structure, no longer would I have to make multiple query calls for getting a complex nested entity.
The only downside is that I have to docume t it more thoroughly and that my api does not have easy discoverability.
But since I have only one client, my frontend that I program,this is not an issue.
After pondering over the DSL a bit, I realised I am actually conceptualizing GraphQL.
- barrkel 7y agoThe complexity is just moved somewhere else; instead of being explicit in an API, it's implicit in a behaviour. If you want to permission those bits you're doing CRUD ops on, or refactor how they're stored, change their normalization in the database, split them out of a monolith into separate services, ensure you're not permitting the UI team (or worse, your customers writing direct to your API) take dependencies on stuff you want to deprecate, well, the complexity just comes back; it's just in the code handling those custom codes, and all you've invented is a multiplexer that obscures the complexity. I think there's value to it though, to GraphQL, but mostly on the read side rather than CUD side. Often all sorts of widgets need to knit together data from different sources, and if your data is relational under the hood, with REST endpoints per relation, the knitting is work better left to a library. I'm less convinced for updates.
- vailripper 7y agoGraphQL actually makes a fantastic frontend for a microservices architecture. We have several GRPC services that drive a suite of applications, we wrap those in a graphql schema and we've now made consuming those services much easier while maintaining the original underlying services.
- kumarvvr 7y agoAfter years of programming, I am convinced that complexity cannot be overcome. For any non-trivial application, complexity is inevitable. In my view, we, as developers, should take up complexity, so that the user is unburdened from it. Ultimately, that is the value addition of software. Remove complexity and improve productivity. Fundamentally, data is relational and hierarchical, no matter how we store it (Documents / SQL). The value added by GraphQL, and often touted in documentation, is that the client, has control over the shape of the data received from the server. Though packaged in a slightly easier to read syntax, GraphQL is essentially SQL. Sending a GQL query is fundamentally sending an SQL query set, with joins and where clauses, and having a layer of abstraction that understands the query and converts it into lower levels calls to data storage systems. In my view, this is a more powerful syntax and more flexible than using a REST API. To achieve the same with REST calls, you would have to do something akin to multiple simpler SQL queries, with manual linking of relational data. I am sure, there will be more innovation in this area, particularly with pairin GQL with Document databases.
- je42 7y agoThe options are not only GraphQL vs REST. In a lot of cases, you can also render server side and push just plain html / components to the client instead.
- korla 7y agoAren't you just moving the client to the backend here? As I understand it we are talking about how whoever needs to render the data gets the data. GraphQL vs. REST vs. whatever is still as relevant in the backend-rendered case.
- je42 7y agoYes, exactly true if you see it from that angle. From your angle, I guess one other alternative to GraphQL and REST would be RPC. ;)
- 7y ago
- AlphaSite 7y agoI think the issue is more with framing. GraphQL is excellent for when you’re implementing an external facing api or a data focused api. Internal APIs where you also own the client or have operation (side effect) heavy clients. These imo would be far better suited to REST.
- kumarvvr 7y agoInteresting, I was thinking the complete opposite. GraphQL for internal api or single client api, while a REST api for external consumers. Internal graphql api can be iterated and broken faster, adapting it for internal use as the app grows, while an external REST api would be more carefully generated and thoroughly documented.
- kumarvvr 7y agoIn addition to my other reply, it serves well to finely granularize an external facing API so that consumers can mix and match to their requirement. This granularity is best accomplished by a REST Api.
- zo1 7y agoSounds more like SQL, if you ask me. Either that or something more like OData.
- tirpen 7y agoOr datalog.