by wawhal on 7/7/20, 12:14 PM with 67 comments
by katet on 7/7/20, 3:59 PM
My two main annoyances are a) GraphQL could be thought of as a custom media type that almost "slots in" to the REST model by defining a request content-type and a response content-type with almost entirely optional fields, and b) the incessant idea that REST has to replicate the n+1 query problem.
For a) "it's strongly typed" has never struck me as much of an argument. It's appealing if you're already lacking a strong definition of your data model, but GraphQL doesn't inherently fix that, it just forces you to confront something you could fix within your existing architecture anyway.
For b), it seems that people tend to map something like /users to `SELECT * FROM users`, and 12 months later, complain that it's retuning too much data, and they have to make N queries to /groups/memberOf.
Am I alone in thinking the obvious solutions are to i) add a comma-separated, dot-notation `?fields=` param to reduce unnecessary data transfer, ii) add an endpoint/content-type switch for `usersWithGroups` and iii) realise this is a problem with your data model, not your API architecture?
As an additional c), my other concern is GraphQL touts "one query language for all your data", but tends to skip over the N+1 problem when _implementing_ the queries to disparate data sources. If your existing queries are bolted into `foreach (input) { do query }` then GraphQl isn't going to give you any speed up, it's just going to give you slightly more simplicity to an already-slow backend.
Granted, I work with "legacy" (i.e. old but functional) code, and I secretly like the idea that adopting GraphQL would force us to fix our query layer, but why can't we fix it within the REST model?
(I happen to be about to sleep, but I am genuinely interested in waking up to see what HN thinks)
by mumblemumble on 7/8/20, 1:30 PM
On the REST side, it's the assumption that the API is for state transfers. Transfer is a heavy word there. You're not just assuming that the service is stateful, and you're not just assuming that clients can ask for state changes. You're assuming that the dominant model for effectuating those state changes is that the client determines what the new state should look like, and transfers a representation of that state to the server.
And then, on the GraphQL side, you're assuming that the service is basically just a big database. Perhaps one with lots and lots and lots of behavior that, from a high level, looks a lot like triggers. But still, a database.
Both these assumptions may work well for a whole lot of applications. If CRUD's your ticket, then both can serve you well. But choosing either might force you to make some compromises if you were instead hoping to do come up with, for example, a more domain-driven design.
by beders on 7/8/20, 2:45 PM
who are your users?
If you develop an API for other users and they expect that API to be around for a while and gradually grow, then you need to think about how much pain are you going to subject your users to when your API changes.
GraphQL: You will not get your domain model right on the first attempt. So you will need to change your "Graph". Your "Graph" might change substantially. How do you deal with that?
REST: Same thing: There are well-known standards how to grow and evolve a true RESTful API. Yet, you may still mess with your users, declare a /v2/ endpoint and discontinue /v1/
by lpellis on 7/8/20, 3:37 PM
by recursivedoubts on 7/8/20, 2:59 PM
REST with JSON has always been a category error: JSON is not a hypertext and thus, as the author says, violates the most important and distinct aspect of the REST architecture.
I have written quite a bit about this:
http://intercoolerjs.org/2016/01/18/rescuing-rest.html
by coding123 on 7/8/20, 2:34 PM
I'm not saying GraphQL is the long term answer, but personally I'd rather be in a project using GraphQL (and hopefully not backed by REST at all)
by ralmidani on 7/8/20, 1:55 PM
https://github.com/yezyilomo/django-restql
It's tempting to think your new paradigm/framework/whatever is so groundbreaking, so purely beneficial, that it warrants asking people to demolish everything and start over. Those kinds of breakthroughs have happened and will continue to happen, but the signal/noise ratio, especially in the world of Web Development, is incredibly low.
by ksri on 7/8/20, 3:07 PM
GraphQL is great during development, but in production you often use "persisted queries" to prevent abuse. Persisted queries are also a way to use HTTP GET instead of POST, and thereby leverage HTTP caching. As such, if you swap out graphql and use sql during the development phase, you perhaps can get similar benefits.
My solution (https://github.com/hashedin/squealy) uses SQL queries to generate the API response. Squealy uses a template language for the sql queries, so you can directly embed where clause from the API parameters. The library internally binds the parameters, and is free from SQL injection.
Handling many-to-many relation, or many one-to-many relations is done in-memory after fetching data from the relational database. This provides the same flexibility as GraphQL, but of course requires you to know SQL.
Here is an example that builds various StackOverflow APIs using just a YAML+SQL based DSL - https://github.com/hashedin/squealy/blob/master/squealy-app/...
Squealy is still work in progress, so don't use it in production. But I would love to get some feedback!
by agustif on 7/8/20, 1:13 PM
Great DX.
GraphQL Modules + TypeGraphQL, Apollo Server, TypeORM (pg for prod and sqlite3 for dev/test)
Works pretty nicely auto-generating both graphql fields/querys/mutations/schema and entities/models from database from a single source of turth. I made a template from type-graphql's graphql-modules example to work as a separate codebase, if someone is interested I could switch it from private to public and share the link here
by 0xBE5A on 7/8/20, 1:30 PM
by stunt on 7/8/20, 1:25 PM
by honkycat on 7/8/20, 6:33 PM
It is a very long list of decisions your team does not have to make. How to handle mutations and queries, how to represent your domain objects, all of this can be decided through referencing the spec and best practice.
Throw in the fact that it REQUIRES you to define a strict schema that has validation, and I am sold. The tooling is great, you get great documentation out of the box, the architecture is good enough, it is totally win-win in my book.
I feel like with REST you have to reinvent the wheel over and over again, and the lack of standards leaves the burden on the team, who may not be senior level engineers.. ( If I have to write another validation library I am going to flip out. )
by aogaili on 7/8/20, 1:22 PM
by gengstrand on 7/11/20, 5:25 PM
1. too many endpoints
2. too much data retrieval
3. too much coupling between clients and servers
The blog does not discuss when to choose REST over GraphQL since that would be in conflict of interest with those who hold Hasura equity.
Technically, GraphQL does decrease the amount of endpoints to one but at the cost of increasing client-side complexity because now client devs have to write what is essentially a query. To do so, they have to understand the backend schema. I would argue that this is not the greatest in terms of clear separation of concerns. I would also argue that this means that there would be even more coupling between client and server.
I won't cover the n+1 point since others here have already done so.
by theonething on 7/8/20, 5:18 PM
Are there any lighter weight RESTful JS client state/cache management solutions out there people can recommend?
by ericls on 7/8/20, 3:58 PM
by superfreek on 7/8/20, 5:01 PM
by rswail on 7/9/20, 8:42 AM
GraphQL isn't. It's a data query mechanism expressed in JSON.
by the_arun on 7/8/20, 3:58 PM
by k__ on 7/8/20, 5:19 PM
AppSync + Amplify DataStore is pretty nice tech!