>1. Write a succinct human readable TypeSpec schema
>2. Generate an OpenAPI YAML spec from it
Why? Isn't YAML human readable?
After 6 years, I'm over GraphQL
281–290 of 721 posts
Re: After 6 years, I'm over GraphQL
#282Worked on two GraphQL projects; I was quickly cured from the hype. I recognize a lot of points in this article. In both these projects the GraphQL had started small. I came in during a more mature phase of these projects (2 and 4 years). That's where the requirements are harder, more specific, and overall complexity has grown. Adoption and demand on the API were growing quickly. Hence you logically spend more time de…
Now where does Braid-HTTP fit in?!
Re: After 6 years, I'm over GraphQL
#283I generally agree and am likewise "over" GraphQL. Having said that, I disagree on some of the finer points. First, some of these issues--authorization, security, N+1--can be mitigated by using something like Prisma, PostGraphile, or Hasura, instead of crafting GraphQL backends with code. Second, there are gains to be made by compiling a GraphQL operation to a single operation in the underlying database's query langua…
I don’t want to overly generalize, but N+1 problems are very real and frequently occur in code written by more junior developers. Their impact and occurrence rate are dependent on the nature of the application though.
I also think there’s an avoidance to simply “translate” a GQL query into an SQL query. Not that it can’t be done, but it allows a lot less flexibility in the backend as far as code patterns that can be adopted. Basically it minimizes the use of ORM models, which may be a pro for some and a con for others.
I haven’t worked with GraphQL in over 4 years since I left my last job. I actively made a choice not to use it at my current job and steered the ship towards REST endpoints, mostly because it would be easier to build authorization middleware. Also like the author of the article discovered, code littered with dataloaders is a pain to maintain.
Re: After 6 years, I'm over GraphQL
#284Earlier quoted context omitted.
That backend engineer wrote a single SQL query that joined some tables, ensured indices were used, and always executed in In graphql land you'd be doing multiple SQL queries, "joining" in the API layer, and spending 50ms per API call.
What? GraphQL is purpose built to solve that in 1 Query. Not doing it in 1 query is on you not the protocol. In practice with REST the frontend engineer didn't want to wait and tried to use the existing REST endpoints, did N+1 API HTTPS calls and then joined them client side in javascript.
> What? GraphQL is purpose built to solve that in 1 Query. Not doing it in 1 query is on you not the protocol.
1 graphql query maybe. But that translated to a dozen SQL queries.
> In practice with REST the frontend engineer didn't want to wait and tried to use the existing REST endpoints, did N+1 API HTTPS calls and then joined them client side in javascript.
The point you're missing is that for 1 graphql query the API did N+1 SQL queries, and then also joined them in JavaScript.
In the REST case the front end can switch to the efficient custom endpoint when it is implemented. In the graphql case it will never get any faster because the API has to stay generic.
Re: After 6 years, I'm over GraphQL
#285Earlier quoted context omitted.
> if you have to involve a backend team to add restrictions to the graphql endpoints and try to make good educated guesses where those might be, then the idea of frontend not needing backend engineers No because if you dont do that you have to involve more engineers anyways to build the REST endpoints and keep modifying the rest endpoints. GraphQL is also default restrictive (i.e. exposes nothing). You don't need to…
> With GraphQL the only time you need to update the backend is when those "utility" functions change (i.e. 3rd party api calls, etc) or the data model changes. This is akin to saying that "directly exposing the database is easier, you only have to change things if the data changes". And yes this is true, but when the data changes, or the environment changes, the paradigm falls apart a bit, no? Which is what the backe…
> This is akin to saying that "directly exposing the database is easier
Far from it actually. I am saying that in practice the data and queries that you perform on your Database actually tend to stabilize and you add less and less as time goes on.
By Allowing the frontend to select what combination of these pre-approved queries that you already approved it can use, you have to do less and less backend work when compared to REST where you have to do backend work for every query combination you want to serve.
> maybe that's fine for most small apps (that will never scale far).
I mean saying GQL doesn't scale for big apps is over looking one of the largest Corporate Software Orgs (FB) created and use it in production purposefully for managing large software APIs.
Re: After 6 years, I'm over GraphQL
#286Earlier quoted context omitted.
REST APIS suck for nested resources. GraphQL is a huge breakthrough in managing them. Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think because they don't want to have to create a backend ticket to add related resources to a call. With internal REST for companies I have seen so many single page specific endpoints. Gross. > There have been different opinions ab…
One place I was at we used REST with a hydration service that ran as a proxy in front of the requests. That gave us most of the benefits of GraphQL and we only implemented it for the main resources (users, photos, and maybe one other thing). To minimize latency/faults the hydration service ran locally on every webapp/API server. I wasn't around for far too long after though to see how it turned out as it grew (if it…
you don't think it's a benefit that you could get the benefits of a "hydration service that ran as a proxy in front of the requests" out of the box?
there's lots of other benefits for GQL: multiple queries per request, mutation/query separation, typed errors, subscriptions support.
Re: After 6 years, I'm over GraphQL
#287Odata is 80% of GraphQL with only 20% of the hassle.
Re: After 6 years, I'm over GraphQL
#288Earlier quoted context omitted.
What? GraphQL is purpose built to solve that in 1 Query. Not doing it in 1 query is on you not the protocol. In practice with REST the frontend engineer didn't want to wait and tried to use the existing REST endpoints, did N+1 API HTTPS calls and then joined them client side in javascript.
A lot of graphql implementation end up moving the n+1 problem to the query resolver.
Every GQL implementation I have seen explicitly has a way to avoid n+1 queries.
Re: After 6 years, I'm over GraphQL
#289Earlier quoted context omitted.
Couldn't disagree more. GraphQL encourages tight-coupling--the Frontend is allowed to send any possible query to the Backend, and the Backend needs to accommodate all possible permutations indefinitely and with good performance. This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates. It is far better for the Backend to provide Frontend a contra…
> It is far better for the Backend to provide Frontend a contract It sure is better for the backend team, but the client teams will need to have countless meetings begging to establish/change a contract and always being told it will come in the next sprint (or the one after, or in Q3). > This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates. I…
I never understood why this was such a big deal... "Hey, we need an endpoint to fetch a list of widgets so we can display them." "Okay." Is that so difficult? Maybe the real problem lies in poor planning and poor communication.
Re: After 6 years, I'm over GraphQL
#290Earlier quoted context omitted.
It would be the same thing except with Benje's approach, you're basically using GraphQL as a developer tool to create those end points instead of writing code to do it. And you don't have to write something to convert them to SQL if you're using PostgreSQL, because Benje's already written it for you.
postgraphile does look like it'll handle basic cases pretty nicely but I've gone through the docs and didn't find anything like an explanation of what SQL queries it ends up mapping to - do you happen to know if there's one I missed, or a list of examples of GraphQL + corresponding SQL, or something?
PostGraphile compiles GraphQL directly to SQL. The SQL is "custom" in that it's specific to the GraphQL operation, though naturally it does follow rules. For example, Hasura does the same thing, and among the rules that it follows is that it uses `LEFT LATERAL JOIN` between tables (at least, on PostgreSQL). Full disclosure, I work for Hasura, so I'm not super familiar with the style of SQL PostGraphile generates but one thing you can do is just have PostGraphile report back the generated SQL for inspection:
https://www.graphile.org/postgraphile/debugging/#via-postgra...