11–20 of 182 posts
Yes, it's generally quite a bit nicer. It's not as nice as I hoped, but it's better. The old APIs are JSONAPI-style. The main disappointment is that input types are not nearly as expressive as output types.
I'm only familiar with REST and not GraphQL, but this sounds interesting. Just from the name GraphQL sounds like a query language -- how can one do operations that change state (i.e., analogous to PUT/POST) rather than just query it? Thanks.
Earlier quoted context omitted.
I'm only familiar with REST and not GraphQL, but this sounds interesting. Just from the name GraphQL sounds like a query language -- how can one do operations that change state (i.e., analogous to PUT/POST) rather than just query it? Thanks.
The name is a little misleading in that regard. GraphQL has mutations that tell the server to change data rather than just return a query.
I tend to write publicly facing APIs so this conversation is colored a little by that. An internal API or Microservice is a different story. I don't think it is either of. I use both. In the same API. The two are largely compatible. All REST APIs can be modeled in RPC style APIs and that's no different with GraphQL. I've done APIs where I have a GraphQL facade in front of REST and REST Facades infront of GraphQL by h…
> I tend to write publicly facing APIs so this conversation is colored a little by that Out of curiosity, how do you secure your public-facing APIs and how do you authenticate/rate-limit users?
I don't centrally track rates unless a signature comes close to 1/N the limit where N is the number of nodes. At which point I will talk to the other nodes Peer to Peer.
Can still be abused but works pretty well most of the time. It also doesn't work if you have a number of nodes that is approximating your rate limit because if you do, you hit 1/N on request #1.
For that reason I tend to choose pretty lenient rate limits (call it one request a second with bursts in a 5 minute window)
For write I use OAuth2 with bearer tokens being a JWT token with a short expiry. I only need to maintain a blacklist of invalidated tokens for the length of the expiry. Rate limiting would work the same way as reads.
The productivity gains from having a client-server interface that is dead simple to reason about more than made up for the initial investment cost. We can refactor API schemas without worrying about breaking existing client code. We also saw performance gains from saving on network round trips.
There are some quirks (error handling), performance issues (e.g. fixing n+1 queries) and DOS concerns, but again, it isn't all that bad.
(we're using rails/graphql-ruby on backend | react/relay on frontend)
Earlier quoted context omitted.
> I tend to write publicly facing APIs so this conversation is colored a little by that Out of curiosity, how do you secure your public-facing APIs and how do you authenticate/rate-limit users?
For read and search operations I typically rate limit per machine based on probability that machine gets hit using machine signature. And as a secondary (more leniant metric, just IP). I don't centrally track rates unless a signature comes close to 1/N the limit where N is the number of nodes. At which point I will talk to the other nodes Peer to Peer. Can still be abused but works pretty well most of the time. It al…
if you have db schemas on the backend if using orm, get ready to duplicate them again for graphql.
and on the frontend, get prepared to write out every songle fields you need from the backend. i can imagine it may be brutal for those who have a lot of changes in their schemas.
my conclusion is that, since im a fullstack who does both frontend and backend, i feel myself getting a bit more fatigued than when i was doing rest style api. i find myself wanting rest time to time, esp at times i dont feel like writing out all the fields i need back that i cant remember off top of my head.
As a frontend dev, I had a positive experience with one service because the backend was far more willing to add new query options. The much publicized "only get what you ask for" part was largely irrelevant.
I am, however, unsettled at the prospect is losing all the built in network and browser caching for idempotent calls (mostly I'm unsettled because no one else seems to seriously consider the issue - it may end up too small to matter, but I dont trust that anyone else here has honestly evaluated it).
Another poster mentioned the issue with partial errors, which sounds like something else that will not get the upfront attention it deserves, while not being an immediate dealbreaker. Add in to that how to manage deprecation of particular query statements as they can no longer be distinguished as distinct endpoints.
My other concern is how much magic frontend libraries provide. This magic looks great if your app is nothing more than input/output over CRUD calls, but sounds very brittle if your app has client side logic (and while perhaps a webapp should ideally avoid that, other services can also be clients.)
So far I have concerns but not concrete problems, I just worry that we wont be able to confirm the severity until we've already invested and committed, particularly when our initial adopters are so enthusiastic. At the same time I don't want to be the guy unwilling to change and adopt new things.
my experience is just ok. as someone here puts it, great for frontend devs but bad for backend devs. if you have db schemas on the backend if using orm, get ready to duplicate them again for graphql. and on the frontend, get prepared to write out every songle fields you need from the backend. i can imagine it may be brutal for those who have a lot of changes in their schemas. my conclusion is that, since im a fullsta…
Wouldn’t you need to do this in some form anyway (since those fields would be displayed or used in some way)?