I don't think the tech advances these companies made were irrevocably tied to the anti-competition practices. If anything, if we made it easier and cheaper for anyone to build on top of the things already existing, we could have had much more.
I am dubious about the actual value of feedback given just to trade. You want feedback coming from people looking to actually use and/or pay, not from people who also have something to sell of their own.
A lot of the sentiment coming from non-gql people in this thread start with: "gql is impossible to X, Y, Z" which is immediately untrue by inference if you base it from how well existing companies in the wild have adapted to it, and provable on your own if you just went out and tried it yourself.
"from what I can see in the landing page, REST can do everything it does anyway" is partially true, but is not useful, because how else would have gql picked up adoption if it can't provide similar benefits as REST? I'm smelling a lot of cope from people who have buried their heads so deep in the sand that they cannot fathom a world that doesn't prefer REST anymore. At least try the tech for your own and make informed opinions.
My problem isn’t that graphql can’t do X. It’s the opposite, that I don’t know what it’s supposed to do really well – the core value prop. I still haven’t heard any one-sentence explanation of what it is, and importantly, what it isn’t.
To me it sounds like they try to solve numerous problems: (1) be a query language, ie an improvement over sql, (2) a type safe alternative to REST ie web APIs (3) allow frontend developers to write queries without having to write endpoints, (4) keep clients lightweight, (5) be a single entry point to this hyper graph thing, and more.
None of these things seem compelling in isolation: simply replacing REST adds resolver complexity and doesn’t handle things like file uploads. Substituting sql restricts you to whatever sql is generated and you end up with two query planners. Allowing frontend to query db directly is insecure so you must have fool proof row level security or more resolver complexity. Clients I guess started out thin but now there are all these intelligent caching layers. And this hyper graph thing is only valuable with other graphql services.
So, I guess graphql can be good if you marry it and go 100% all in? But to me it’s a smell when technology claims that your pains can be resolved by using more of the same tech. How am I wrong?
It's perfectly fine to use graphql for fetching metadata and then using REST API for file upload and downloads.
On a gql server, you implement resolvers for the schema. There might be some frameworks that abstract SQL away from the resolver implementation but a resolver may need to make a combination of sql and network calls to other services. Or only network calls to other services.
> Allowing frontend to query db directly is insecure so you must have fool proof row level security or more resolver complexity.
I'm not sure why you are thinking that graphql means the frontend is querying the db directly; a graphql server implementation is implement a callback for each graph node that returns the object. It's the server code logic to implement permission checks and the actual SQL or network calls to resolve the object. What part of this results in frontend code querying SQL directly?
It seems like you are getting caught up in the name of "query language" which may be partially a misnomer. It's more like a data fetching protocol
(You missed a line break so my quote extended into your response).
> It seems like you are getting caught up in the name of "query language" which may be partially a misnomer. It's more like a data fetching protocol
Yes, I gave multiple definitions and that’s one of them (2). While that’s certainly true, is that how it’s used in practice and sold? All popular frameworks I’m aware of are selling themselves as having automatic db resolvers with SQL dbs. And thus fast frontend iteration. N+1 solution. Etc.
> It's the server code logic to implement permission check
Isn’t that very difficult to do? Resolvers have recursive relations that can be very tricky to secure, since it’s a high abstraction level. So you tend to rely on RLS or another system to be configured, no?
> Isn’t that very difficult to do? Resolvers have recursive relations that can be very tricky to secure, since it’s a high abstraction level. So you tend to rely on RLS or another system to be configured, no?
I really don't think it's any more difficult than if you're not using graphql. If you're hitting a db then you can store auth/permission context for the lifetime of the request. Each time you hit the db to resolve a node, you're going to use the same types of patterns you'd use when fetching objects from the db using sql or an orm. It's customary to have a request context object available in all of the resolvers for just this reason.
If you resolving by calling other services, auth scopes would typically be forwarded on in request headers.
> All popular frameworks I’m aware of are selling themselves as having automatic db resolvers with SQL dbs.
I think I agree if some frameworks for full stack aimed at prototyping where a solo frontend-focused developer needs a backend it abstracts too much, including the db. In these cases, it's probably unnecessary and if you're solo dev on a full stack framework and probably doesn't matter either way.
I've worked on graphql at scale as an frontend service that acted as an API gateway of sorts. The resolvers were not accessing the db but calling other services.
When working on a new application, I would probably use REST and probably would be a long while and would need to have a set of problems to solve with graphql. I think it's quite good at federating services.
To put it simply, even with REST, you're already dealing with the concept of "how does clients get a handle of a particular entity?" With REST, the answer is usually muddled by client data fetching mechanisms and backend architecture that you've opted to use - so just because two projects are doing REST does not mean they're handling these entities in a similar, understandable nature and it requires a lot of background context, same with auth.
graphql makes all that a deliberate matter instead. So take whatever's in your db, decide which fields are you going to expose, and write resolvers that return just that - you can't get any more foolproof than that, it's basically the same thing you do with REST, just without all the client-side fumbling and coordination.
But what I'd argue the thing it does best, is that with REST, you'd probably write code for handling Entity A, and if Sub-Entity A and B rely on Entity A, you'd probably write specific code to ensure the right entities are returned in your endpoints. With graphql, you just reference that entity and it's resolved automatically, because you have written the resolver for that entity already. Resolvers have access to the parent entity that's referencing it, so if Sub-Entity B has stricter controls in what it should expose, the Entity A's resolver can be written to accommodate that (see directives among other ways for how to scale this better).
As for auth, whatever middleware you're already using in your REST endpoints can also be reused one way or another for the gql endpoint, no issue.
> this hyper graph thing is only valuable with other graphql services.
Even without other graphql consumers/services, there's huge value in not having to write multiple ways of handling a certain entity anymore, among other things.
> So, I guess graphql can be good if you marry it and go 100% all in?
All of my recent work related to graphql happened in projects that incrementally adopt it - there's no requirement whatsoever to fully commit to it 100%. It definitely helps that you can reuse whatever your REST endpoints use to comprise code that builds up towards resolvers, like util/helper fns. Nothing stops you from serving the same entity in both REST and graphql forms, heck there's specific usecases that benefit from it (i.e. maybe your mobile app can't keep up with it yet, and you're trying it out for web for now etc)
Say, in such kinds of projects, what I can recommend is identifying a subset of entities that your backend serves that you think (at least superficially) will benefit from it e.g. a relatively new entity that is essentially WIP across releases, and you'd benefit from at least not having to redo the entire REST API endpoint subset for this entity whenever you're making drastic changes, or a particularly old one that could use a rethinking anyway, among other use cases. After a couple of releases you'll get a feel for how it works, and then it'll be enjoyable to port more of the entities later on.
> decide which fields are you going to expose, and write resolvers that return just that
To be clear this means writing custom resolvers? That seems like the most sane way to use graphql, should I ever revisit it.
What’s the logical authorization entity? In rest, it’s (typically) the endpoint itself. What is it in graphql? Does a specific entity resolver have authorization? What does it look like in pseudocode?
How hard is it to write custom resolvers that also produce efficient sql? A gql query can be arbitrarily complex (ie nested), no? How to curb that complexity in practice?
Hmmm I'm not aware if the word 'custom' applies to resolvers - to an extent, you're always going to write them out as such for optimal benefit, can't imagine a non-custom one if that's what you meant.
> What’s the logical authorization entity? In rest, it’s (typically) the endpoint itself. What is it in graphql? Does a specific entity resolver have authorization? What does it look like in pseudocode?
You can have both API-wide and resolver-defined auth. In your graphql server config, there's a `context` config option you can pass a function to, and it has access to the whole HTTP request (typically, depends on the integration but I assume all of them treat it the same), it's where you'd probably e.g. check for auth headers and run them against db or the cache layer for auth etc. You can already throw errors and whatnot within this function, so that's the API-wide part.
The returned value of this context function is then included in the params of any executing resolvers, so you can have that resolver throw if e.g. the user stored in context does not have the sufficient roles to access this entity.
There's also directives: say you want to have an `@auth` directive that you can just slap on typedefs that makes auth logic reusable across a subset of entities, but you don't want to handle it on both API-wide and resolver levels, you just write a transform fn, register it in the config, and put that directive on the schema itself.
> How hard is it to write custom resolvers that also produce efficient sql? A gql query can be arbitrarily complex (ie nested), no? How to curb that complexity in practice?
Yes, a gql query can be complex and nested, but you only need to write the resolver in a way that all the ways you need to resolve that entity are taken into account. A query resolver returning one instance of Entity A via their unique ID in most cases is enough, for example - it does not matter how deep into the gql query the entity appears, graphql will do the heavy lifting and refer or run every resolver fn until all entities in that query have been resolved.
The next question is, that means graphql will hit the db one-to-many-times depending on the schema, and yes, that'll happen, but there are again, granular ways to handle that depending on the integration - Apollo at least lets you configure your own in-memory cache or use Redis for example, and be able to cache results in the schema-wide, resolver and response levels.
Exactly, what merit is there to putting a manager that pushes failure onto the team? Might as well have the team itself report to senior management if one is too eager to get out of the way.
With the right team/leader, there'd be room for your inputs on the matter. Even if you find yourself in a not-so-good team setup, I'd argue there's still merit in letting your opinion be known, regardless of whether you end up implementing said solution in the way you were told or not.
> Using "clever" as a criticism is implicitly an ad personam argument, passing value judgement on the person who wrote it ("Oh, they must have written it to show off") instead of an argument about the code itself.
I don't know how you got this conclusion.
I can see judgement being passed to the code with respect to not just who wrote it, but also who's going to need to understand it later, who's going to need to make changes to it. In that sense, calling code "too clever" makes sense, right?
There's hyper-specific reasons why you'd need code that's going to be complex/too clever for that group, esp if it saves cost or is faster than the simpler alternatives, but in most cases there's nothing that justifies it.
The fun, intellectually stimulating part definitely takes a back seat in priority over keeping the lights on for customers/colleagues most of the time, except in personal/weekend projects.
See, this will just cause additional communication overhead for the maintainers, too. And for what benefit, just to accommodate the behavior we see here?
