Comment by kumarvvr | Hacker News Reader

Comment by kumarvvr | Hacker News Reader

Parent Full thread

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.

The 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.

GraphQL 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.

After 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.

The 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.

Aren'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.

Yes, exactly true if you see it from that angle.

From your angle, I guess one other alternative to GraphQL and REST would be RPC. ;)

It absolutely is. It is in fact, one of my preferred ways to design systems when doing it in tight coupling between backend and frontend. Such as in a micro-fronted-style vertical. It’s very effective when the needs of the frontend dictate the needs of the backend.

I 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.

Interesting, 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.

In 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.

Sounds more like SQL, if you ask me.

Either that or something more like OData.

Or datalog.

Reply on news.ycombinator.com