> 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.

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.

"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.

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.

  Location: Philippines
  Remote: Yes
  Willing to relocate: Yes
  Technologies: React, Typescript, GraphQL, deck.gl/Mapbox, Electron, Node, Express, PHP, Laravel, PostgreSQL, MySQL, Docker, AWS
  Résumé/CV: https://ralphstodomingo.com/CV.pdf
  Email: yo@ralphstodomingo.com

With 5+ years in the commercial real estate industry and experience in leading teams and projects to accomplish business objectives, also an avid learner and note-taker. Not afraid to start projects and develop organizations, but can also fit in well with existing teams. Open to work in any industry as well.

Currently looking for a full-time long-term engagement, in roles that will benefit from someone like me that's on the practical side of things. Always up to solve problems.

just made me realize how much I appreciate HN even more. Stuff just loads.

Also, I'm not sure if it's just me, but the font used is barely readable.

[0]: https://en.wikipedia.org/wiki/Sturgeon%27s_law

I've always been interested not just in the ideas per se (which are often useful, no doubt) but also how they came to be, and I've had more than one instance where I wanted to trace back where they adapted the idea and I can't find it that easily.

That said, it may be the medium's fault, as the inherent character limit only allows for so much information that references and relevant information are considered way lesser in terms of priority... which in turn I think says something about the nature of ideas themselves.

This can't be farther than the truth. I advise you at least try to peruse it a bit before resorting to such commentary. The point isn't to make money at all.

Also, I prefer to keep the ad blockers off when I'm on the site just to support those who I want to support, and I'm not on it for most of the time.