Hacker News new | ask | show | jobs
by bbbbzzz1 1098 days ago
In Apollo server you can add directives to your scehma for authz. It's dead simple.

I'm surprised how so many HN posts about graphql just slander it. If you go to the website and look at the use case of why it was made, it makes it pretty clear when it could be a good to use. My experience with it has been very straight forward and a joy

2 comments

For me it was the prevalence of GraphQL that was annoying. I have worked with it and liked it as a technology, but it was a tell from the org I worked for an was definitely overkill for what we were doing. No matter how you slice it, GraphQL is added complexity compared to REST but of course, as with a lot in our industry, there are all the people bought in who put in the time to learn it who are going to shout, "Naw, it's easy!" To be clear I'm not saying GraphQL is super complex, just more complex than REST and if all you need is REST then that is what you should be using. Yet in my many interviews over the past year I talked to a bunch of companies who used GraphQL and I'd say, "Oh, cool, why did you choose it?" and they'd say something along the lines of, "Well, the CTO who wrote the original app thought it was cool at the time." So I've always got the impression that the backlash mostly comes from the huge evangelism it got making it out to be The New Way. Again, to be clear, I'm not saying it was marketed this way but it's how it felt at the time. Annnd again, I know this happens constantly in our field.
GraphQL (as in the language spec) offers no way to perform authz. Just because there are non-standardized extensions out there for some languages, doesn't mean it is available in whatever language you're using.
Ok, but that’s true whether or not you use GQL.
Sure. I could respond with a 4xx code because you’re not authorized for that field. Ah, but maybe you want to know which field? Too bad GQL doesn’t really support that.
GraphQL has strongly typed errors unlike REST. It is very akin to the Result type in many languages in that you are forced to handle errors even when writing the query, and the query will simply not compile if you don't.

For example, the Pothos library implements this pattern automatically:

    type Error {
      message: String!
    }
    
    type Query {
      hello(name: String!): QueryHelloResult
    }
    
    union QueryHelloResult = Error | QueryHelloSuccess
    
    type QueryHelloSuccess {
      data: String!
    }
    
This field can be queried using fragments like:

    query {
      hello(name: "World") {
        __typename
        ... on Error {
          message
        }
        ... on QueryHelloSuccess {
          data
        }
      }
    } 

https://pothos-graphql.dev/docs/plugins/errors
But now I’m most likely returning a 2xx response. There are asshole corporate middle boxes somewhere that will cache it. If I return a 4xx response, from experience (albeit nearly 5 years ago) I’ll crash your client. Now what?

If someone has solved the asshole corporate middle box problem using GQL, that’s really good news.

Authorization errors can go in the errors array which has a path reference in the standard.

You generally don't want to use HTTP error codes with field level errors in GQL.

So still a 200? Or a 202, 206, 207?
401 or 403. Why is this a question?