←back to thread

153 points michaelanckaert | 4 comments | | HN request time: 0.303s | source
1. crabmusket ◴[] No.23488357[source]
> Another (potential) advantage of GraphQL is the ability to compose many different APIs into a single, federated GraphQL schema.

If anyone else can share experiences of this sort of problems and solution, I'd be really interested to hear it. I've written non-GQL APIs before that back onto other internal and external services; what am I missing?

replies(2): >>23488403 #>>23491138 #
2. maddyboo ◴[] No.23488403[source]
I think Drew is referring to composition in terms of API end-user code, not sr.ht code, e.g. making it possible for the user write a single GQL query that combines data from multiple sr.ht services.
replies(1): >>23495197 #
3. GordonS ◴[] No.23491138[source]
I've mentioned my (negative) experience elsewhere in this thread. It wasn't actually me doing the implementation, but the result was a horrendous, unmaintainable and slow code base. Ultimately, no part of the team benefited from the use of GraphQL instead of REST.

To be fair, the same devs that built it using GraphQL would likely have made many of the same mistakes with a REST API, but I do feel it would at least have been easier to reason about the code.

4. crabmusket ◴[] No.23495197[source]
Ah, I think that makes a little more sense. Thanks!