It's not graph, and it's not QL.
It is QL.
After 6 years, I'm over GraphQL
201–210 of 721 posts
Re: After 6 years, I'm over GraphQL
#202Earlier quoted context omitted.
GraphQL is very good for places where frontend and backend developers are isolated from each other (separate teams). Or rather places where you have data-producers and data-consumers as separate teams. If you have a big enough org eventually there will be many of such teams, interdisciplinary teams are not feasible at scale for everything. It allows teams to work with less communication overhead. It solves more of a…
The problem is you delegate a lot of the query building to the client, hoping that it will not suddenly change your performance profile by being creative and that you will have not missed an obviously expensive use case coming. That's a huge bet, especially given that GraphQL is expensive in the first place, and given that the more you grow the API in size, the less you can actually map the cartesian product of all r…
When the client’s data requirements change, isn’t there always a risk that the data loading performance profile will change?
Surely that is always the case, if the client is composing multiple REST requests, or if there’s one RPC method per client page, or with any other conceivable data loading scheme.
Re: After 6 years, I'm over GraphQL
#203Earlier quoted context omitted.
Not a fan of GraphQL (the problems mentioned in the post are very real), but GraphQL specification does not say anything about the DB design / queries. It is still an API layer and you are free to model it in any way you want.
Indeed, from one of the authors of graphQL on this very forum: "That would be one way to implement the system in a DB-centric way. However we believe that intermediate application code is pretty critical to any GraphQL implementation." [1] "GraphQL is a client-server dance that needs server-side capabilities, not just CRUD semantics." [2] [1] https://news.ycombinator.com/item?id=9879870 [2] https://news.ycombinator.c…
I do not share that author's belief about application code.
Re: After 6 years, I'm over GraphQL
#204One of the major issues I have with GraphQL from the get go is that it introduces it's own syntax instead of using a commonly understood and established _data_ format like JSON or similar. Same problem with Prisma Model definitions and other such things. Please, if you make a new thing and it fits neatly into a data format, use a data format! Let me use all of those well established libraries, schema definitions and…
What do you mean? Both GraphQL queries and results are JSON. The query expression is just a json string. Are you referring to the schema language?
[deleted]
Re: After 6 years, I'm over GraphQL
#205Earlier quoted context omitted.
> [0] https://blogs.windows.com/msedgedev/2024/05/28/an-even-faste... Maybe I'm missing something obvious, but React isn't mentioned in that post. Maybe you put the wrong URL?
Odd, I thought I saw something about React in Microsoft's communications as well. Anyway, here is the horse's mouth: https://toot.cafe/@slightlyoff/112521248529973776
As I read this thread, it's not like "React was the issue, let's move to [other framework]", it's more like moving closer to the plattform brought a performance boost.
And that's something I would totally agree. Moving from WebUI to native UIs would even be more performant, and if one would care that much about performance (as said in the thread), one would probably not look at WebUI/Electron/Browser at all and prefer native apps.
Re: After 6 years, I'm over GraphQL
#206For something like OpenAPI+JSON REST API, does anyone have recommendations on tooling that would make my life easier?
I am also over GraphQL but I really like the api explorers, code completion, type safety, etc.
Re: After 6 years, I'm over GraphQL
#207Earlier quoted context omitted.
> With internal REST for companies I have seen so many single page specific endpoints. Gross. Hardly gross. It is what it is and it’s universal across the domain. I bet Windows has internal APIs or even external ones that were created just for one page/widget/dialog of one app. It’s the nature of things at times.
Its gross because it is a waste. An engineer had to spend time to make that specific API for that page instead of the frontend consumer using what was already defined and get all the resources with one call and 0 backend engineer needed for that new page.
Is the flexibility worth the tradeoffs? Maybe in a company where you are adding new pages all the time with deeply nested relational data needs. But I would argue this is more rare than not. And I often find that frontend engineers aren’t as familiar with database queries and the load they are putting on the system with some of the graphql queries they are making. Flexibility for frontend has its own tradeoffs and I totally understand why a frontend engineer doesn’t want to have to wait for an endpoint to be finished. But this article outlines some of the issues you encounter later as you scale your team and system.
We use a schema first design where I am at and if a frontend person needs a new endpoint because the resource-only endpoints aren’t enough then they submit a pull request to the schema repo with a design for their endpoint they need. It gets approved and boilerplate is auto generated. Yes you have to wait longer, but 90% of the time (for our software) the resource endpoints work great.
Re: After 6 years, I'm over GraphQL
#208Working with GraphQL over 6 years, I have seen (and created) many mistakes mentioned in the article. GraphQL is not great but it has worked well for me, you just need to adapt & change mindset to create better interface for your graphQL endpoint.
For example, having nested queries more than 2 levels is a no go for me (just like having nested inheritance is basically anti pattern)
Focus more on your interface. One way to avoid N+1 and nested query is to required parameter for related fields. For example
```
user(id: $userId) { {
id
friends {
id
...
}
to
```
user(id: $userId) {
id
friends(id: $userId) {
id
...
}
Re: After 6 years, I'm over GraphQL
#209Having worked extensively with OpenAPI, GraphQL, plain JSON/HTTP, and gRPC/Buf Connect services, most of this rings true for me. One thing the author doesn't mention is that you can limit the set of queries clients can call in a GraphQL service, by hash or signature. This mitigates a lot of the gnarly performance and security issues because the attack surface goes from "arbitrary queries" to "queries you've already '…
+1 for Buf Connect. Great CLI, simple codegen configuration, basically no added runtime complexity — it’s just the serialization layer at that point. It’s also great to be able to use it for both the API layer using JSON while also allowing full gRPC inter-op between backend services, with the same library and workflow.
Re: After 6 years, I'm over GraphQL
#210when will people learn - you're not Facebook, or will never likely reach facebook scale. Graphql, Relay, React were things etc made for Facebook at facebook scale i.e whether that's in terms of engineers, resources or actual tech problems. There's plenty of other sites / services that receive almost as close to FB properties in terms of traffic yet you never hear them pushing all those tools. Trading firms, Porn firm…
I think an aggravating factor in the software world (that's maybe not as prevalent in other fields), is that developers tend to want to use the latest and newest technologies, even if said technology is not really appropriate for the task. It looks good on your resume to say that you used the same technology Facebook uses - the ol' "resume driven development".
Jobs ASK for that B.S.
Instead of hiring a generally capable person that can learn everything during an on ramping.
So devs respond in kind with equal amounts of bullshit.
It's a cycle of bullshit in the industry.