5 ms·

Nice idea. Any plans on supporting GraphQL? I've moved all my API's over to that standard.

asim 4y ago
Yes we'd love to support graphql in the long term. I guess the question is the best approach. Everything in the backend is a microservice written using grpc. So we wondered whether we'd need to stitch the relationship between them all together first or just offer a straight up graphql API per service. Would love some thoughts on the best approach here.
- RedShift1 4y ago
  My first instinct is definitely together, but perhaps namespaced, which will lead to some redundant naming but makes sure there are no conflicts. As a consumer you don't want to run to different endpoints all the time to get different things done, you want one endpoint and change the operation through the GraphQL query/mutation/subscription.
  - asim 4y ago
    I thought this might be the case. Hence needing to do something federated. But initially we might be able to group all the schemas into one giant graphql server. I don't have enough experience with graphql personally so will probably need some help with this.
    - ricopags 4y ago
      You might consider checking out www.onegraph.com and www.stepzen.com if you do go the GraphQL route [OneGraph as competition, StepZen as perhaps a solution]
- tough 4y ago
  You don't need to choose. You can do both. As graphQL let's you build extending other graphql api's, you could do one for each service, and a general one, this should work nicely with you current setup I think. Thegraph is mainly this for web3 stuff no?
  - asim 4y ago
    Ok interesting. Then I'll try to figure something out. I think we can probably find a way to handle all the graphql requests through a single endpoint. Thanks for the info.
    - tough 4y ago
      https://www.graphql-mesh.com/ https://www.graphql-mesh.com/ https://www.the-guild.dev/ https://www.the-guild.dev/ https://www.apollographql.com/docs/federation/ https://www.apollographql.com/docs/federation/

asim 4y ago

Yes we'd love to support graphql in the long term. I guess the question is the best approach. Everything in the backend is a microservice written using grpc. So we wondered whether we'd need to stitch the relationship between them all together first or just offer a straight up graphql API per service. Would love some thoughts on the best approach here.

RedShift1 4y ago
My first instinct is definitely together, but perhaps namespaced, which will lead to some redundant naming but makes sure there are no conflicts. As a consumer you don't want to run to different endpoints all the time to get different things done, you want one endpoint and change the operation through the GraphQL query/mutation/subscription.
- asim 4y ago
  I thought this might be the case. Hence needing to do something federated. But initially we might be able to group all the schemas into one giant graphql server. I don't have enough experience with graphql personally so will probably need some help with this.
  - ricopags 4y ago
    You might consider checking out www.onegraph.com and www.stepzen.com if you do go the GraphQL route [OneGraph as competition, StepZen as perhaps a solution]
tough 4y ago
You don't need to choose. You can do both. As graphQL let's you build extending other graphql api's, you could do one for each service, and a general one, this should work nicely with you current setup I think. Thegraph is mainly this for web3 stuff no?
- asim 4y ago
  Ok interesting. Then I'll try to figure something out. I think we can probably find a way to handle all the graphql requests through a single endpoint. Thanks for the info.
  - tough 4y ago
    https://www.graphql-mesh.com/ https://www.graphql-mesh.com/ https://www.the-guild.dev/ https://www.the-guild.dev/ https://www.apollographql.com/docs/federation/ https://www.apollographql.com/docs/federation/