I'd like to add that I'm seeing more and more companies unifying synchronous and asynchronous APIs. With the concept of GraphQL Federation, it's possible to "extend" Entities by defining their (primary) keys in a GraphQL Schema. If we're combining this with Async APIs, e.g. NATS or Kafka, we can enable teams to build APIs around events, while still being able to distribute the implementation of how certain fields can be resolved. The Federation Router then joins the Stream with additional data from synchronous services, a very powerful pattern I believe. I wrote a bit more on the topic here: https://wundergraph.com/blog/distributed_graphql_subscriptio...
Comments
I'd like to add that I'm seeing more and more companies unifying synchronous and asynchronous APIs. With the concept of GraphQL Federation, it's possible to "extend" Entities by defining their (primary) keys in a GraphQL Schema. If we're combining this with Async APIs, e.g. NATS or Kafka, we can enable teams to build APIs around events, while still being able to distribute the implementation of how certain fields can be resolved. The Federation Router then joins the Stream with additional data from synchronous services, a very powerful pattern I believe. I wrote a bit more on the topic here: https://wundergraph.com/blog/distributed_graphql_subscriptio...