3 ms·

GraphQL is another one of those "perfect technical solutions" that ends up being annoying as hell. Basically, managing multiple different endpoints is complicat

GraphQL is another one of those "perfect technical solutions" that ends up being annoying as hell. Basically, managing multiple different endpoints is complicated, so they wanted to make one interface for multiple endpoints. But that one interface is now complicated, whereas before each of the multiple different endpoints was simple. I would suggest avoiding it until you're certain you need it, and consider how annoying it might be for the user. (Don't make me learn a language, then syntax check it, just to ask your API to give me some basic info)

teaearlgraycold 3y ago
It’s clearly one of those tools meant for big teams with big scale problems.
- lobsterthief 3y ago
  I disagree; in my experience, it’s really great for small teams with fewer full-stack engineers. More specialized frontend engineers can rapidly iterate and prototype interfaces without needing to make corresponding API changes to endpoints, nor requesting massive payloads with a bunch of frontloaded crap. But also in my experience it’s better to go all-in on either REST or GQL; supporting both is a time suck.
hot_gril 3y ago
I've been down the route where GraphQL eventually becomes important after months of trying to avoid it, specifically as the main gateway for a frontend to fetch stuff. Good news is you don't have to start with it for that use case, you can add it on when it starts making sense. You sacrifice a little performance and have a small mess in the meantime, not a game-changer, so I can see the YAGNI argument. But I might start with GQL from square 1 next time. For public APIs, you have to choose further in advance whether or not to use it. Never been in that situation myself, but I'd be on the fence because I agree it's annoying for the user.
- ysavir 3y ago
  What made GraphQL become important?
  - hot_gril 3y ago
    We had a NodeJS backend and an iPhone/Android app frontend communicating over JSON-over-HTTP with an OpenAPI spec. It was a social-like app with endpoints like /getUsers, /getPost, /makePost, whatever. There were lots of cross-references, such as a post having the posting user, and we were just sending IDs from the backend so the frontend could look up the referenced objects on its own. The idea was the frontend would cache things, avoiding tons of lookups. This is probably what a backend-backend interaction would look like, but it wasn't suitable for frontend. Frontend dev team didn't want to own this much logic and started asking for nested objects in the API, usually with only a few fields. Like they needed the poster's handle and avatar for each post, and they'd only request more detail when visiting the profile. So we started cramming it all in there. A bit wasteful and tedious, not the end of the world, but GraphQL would have been a much more elegant solution. Also, frontend and backend teams were on opposite sides of the world. If backend team added a new endpoint but missed something the frontend needed, it'd be a full day before they heard back. So it was best to err on the side of sending too much info back then remove parts of it later.
    - endisneigh 3y ago
      This is a good example of why planning is important. The front end team should have stubbed out the backend, iterated as they liked, and told the backend team we need these requests for these pages Graphql is popular in part due to communication dysfunction.
      - hot_gril 3y ago
        They did some stubbing as needed, but that doesn't change how it's still messy and tedious for the backend team to support so many different combinations of data instead of just handing them a GQL. Also, to be frank, frontend team was paid a lot less per head than backend team. Their expertise was just in building the UI according to what the backend team and designers gave them, and they were very good at that. Stubbing wasn't an efficient use of their time.
Justsignedup 3y ago
What would you recommend as an alternative? I have been using json-api but unfortunately the only good server-side impl I found was graphiti.dev (ruby). Are there other recommendations?
- hot_gril 3y ago
  OpenAPI aka Swagger is one
satvikpendem 3y ago
I wouldn't use GraphQL for an external API, it's best for internal data sharing in a type safe way between the frontend and backend.
jbverschoor 3y ago
It’s difficult to migrate away from. How do you know what you can stop if you don’t know what the exact requirements of client are? I think it’s a stupid thing to deploy

teaearlgraycold 3y ago

It’s clearly one of those tools meant for big teams with big scale problems.

lobsterthief 3y ago
I disagree; in my experience, it’s really great for small teams with fewer full-stack engineers. More specialized frontend engineers can rapidly iterate and prototype interfaces without needing to make corresponding API changes to endpoints, nor requesting massive payloads with a bunch of frontloaded crap. But also in my experience it’s better to go all-in on either REST or GQL; supporting both is a time suck.

hot_gril 3y ago

I've been down the route where GraphQL eventually becomes important after months of trying to avoid it, specifically as the main gateway for a frontend to fetch stuff. Good news is you don't have to start with it for that use case, you can add it on when it starts making sense. You sacrifice a little performance and have a small mess in the meantime, not a game-changer, so I can see the YAGNI argument. But I might start with GQL from square 1 next time. For public APIs, you have to choose further in advance whether or not to use it. Never been in that situation myself, but I'd be on the fence because I agree it's annoying for the user.

ysavir 3y ago
What made GraphQL become important?
- hot_gril 3y ago
  We had a NodeJS backend and an iPhone/Android app frontend communicating over JSON-over-HTTP with an OpenAPI spec. It was a social-like app with endpoints like /getUsers, /getPost, /makePost, whatever. There were lots of cross-references, such as a post having the posting user, and we were just sending IDs from the backend so the frontend could look up the referenced objects on its own. The idea was the frontend would cache things, avoiding tons of lookups. This is probably what a backend-backend interaction would look like, but it wasn't suitable for frontend. Frontend dev team didn't want to own this much logic and started asking for nested objects in the API, usually with only a few fields. Like they needed the poster's handle and avatar for each post, and they'd only request more detail when visiting the profile. So we started cramming it all in there. A bit wasteful and tedious, not the end of the world, but GraphQL would have been a much more elegant solution. Also, frontend and backend teams were on opposite sides of the world. If backend team added a new endpoint but missed something the frontend needed, it'd be a full day before they heard back. So it was best to err on the side of sending too much info back then remove parts of it later.
  - endisneigh 3y ago
    This is a good example of why planning is important. The front end team should have stubbed out the backend, iterated as they liked, and told the backend team we need these requests for these pages Graphql is popular in part due to communication dysfunction.
    - hot_gril 3y ago
      They did some stubbing as needed, but that doesn't change how it's still messy and tedious for the backend team to support so many different combinations of data instead of just handing them a GQL. Also, to be frank, frontend team was paid a lot less per head than backend team. Their expertise was just in building the UI according to what the backend team and designers gave them, and they were very good at that. Stubbing wasn't an efficient use of their time.

Justsignedup 3y ago

What would you recommend as an alternative? I have been using json-api but unfortunately the only good server-side impl I found was graphiti.dev (ruby). Are there other recommendations?

hot_gril 3y ago
OpenAPI aka Swagger is one

satvikpendem 3y ago

I wouldn't use GraphQL for an external API, it's best for internal data sharing in a type safe way between the frontend and backend.

jbverschoor 3y ago

It’s difficult to migrate away from. How do you know what you can stop if you don’t know what the exact requirements of client are? I think it’s a stupid thing to deploy