311–320 of 721 posts
Earlier quoted context omitted.
If new fields show up in a json response just ignore them. Why would you need to change the client if new fields show up in the response?
Indeed, this is what graphQL solves. Are you proposing just to add new field to a JSON response, even though they are not needed?
I only have one experience with a client using GraphQL and it was horrendous . My biggest complain is there seemed to be no way to just to query all fields. I know that is intentional and the point of GraphQL.. but they should support something for the server side to enable this. Maybe they have over the years, I don't know. But my experience was during the implementation phase the client kept adding new fields that…
You should have looked at the schema. It indeed seems like GraphQL saved your client in this case.
Yeah.. no.
Not just for the content but I love it when someone changes their mind (very very hard thing to do) and details out what led them to change.
Earlier quoted context omitted.
trying to solve org problems with tech just creates more problems, allthewhile not actually solving the original problem.
Yup. And the solution to that org problem is for the front engineers to slow down, and help out the "backend" engineers. The complexity issues faced by the back-end are only getting worse with time, the proper solution is not adding more complexity to the situation, but paying down the technical debt in your organization. If your front-end engineers end up twiddling their thumbs (no bugs/hotfixes), perhaps there is t…
What ends up happening is the clients doing work arounds to backend problems which creates even more technical debt
I 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…
I'm not persuaded there's an avoidance of translating GraphQL. Rather, I think it's largely because of a lack of awareness of that as an option. Most or all of the material written on the subject exclusively presents execution as matter of nested resolvers and that's how pretty much all the libraries work, so I think it's natural to assume that's the only way to do it.
I will say that translating to SQL does remove a convenient arena in which to write business logic in a general purpose programming language, which generates resistance to the idea of translation once it's encountered. But, as the author says, that mixes business logic with data marshalling code anyway.
Earlier quoted context omitted.
I haven't done much more than toy projects in GraphQL. Is there no way to limit the query complexity/cost? Such as a statement timeout in postgres?
I'm not that much into GraphQL but I vaguely remember libraries that provide some kind of atteibutes you apply to entities/loaders and then pre-execution an estimated cost is calculated (and aborted if over a specified threshold).
The one positive to come out of working with it (aside from knowing how to spot a tech black hole) is that it informed the design of the API layer in my framework [1][2]. I realized the sweet spot is starting with a basic JSON-RPC type endpoint and then layering things like input validation [3], authorization [4], and selective output [5] (only requesting certain fields back) on as you need them.
[1] https://docs.cheatcode.co/joystick/node/app/api/getters
[2] https://docs.cheatcode.co/joystick/node/app/api/setters
[3] https://docs.cheatcode.co/joystick/node/app/api/validating-i...
[4] https://docs.cheatcode.co/joystick/node/app/api/authorizatio...
[5] https://docs.cheatcode.co/joystick/ui/api/get (see output array in the function options API)
Earlier 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…
Unpopular opinion: I'm actually a fan of singe page specific endpoints. You get much easier debugging, easier to audit security, easier performance optimization an the imho pretty small price to pay is that it's "not elegant" and a bit of backend code
The GP's idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy.
On the other extreme, we have the HTTP 1.0 developers saying something like "networks are plenty of fast, we can waste a bit of it with legible protocols that are easier to make correct", while the HTTP 2.0 ones are all in "we must cram information into every single bit!"
Every place you look, things are completely bananas.
Earlier quoted context omitted.
This happens anyway.
Not nearly as often with Graphql and happens less and less as your backend and data models stabilizes. Most of our frontend features now don't have backend changes and we were able to increase the ratio of frontend to backend devs.
Making a good API on a large system with many clients is always difficult. GraphQL makes it easier in theory, but if you have average level devs working on it, they’ll make a bigger mess than if they use simple REST. The latter will still be complex, but at least it’s easier to have observability.
GraphQL is the peanut butter to Reacts chocolate at FB. It works there because 1. Every user is logged in. Is there anything you can do at FB without giving up something to the Zuck? 2. Because it's all behind a login, you can front load the first login/request with a giant SPA and then run all the custom queries you want. 3. everything at FB is some sort of blended context (my user, someone else's user, a permission…