4 ms·

I've decided to go this way for now, at least for CRUD APIs: Frontend | | GraphQL | V Backend | | gRP

I've decided to go this way for now, at least for CRUD APIs: Frontend | | GraphQL | V Backend | | gRPC | V Microservice The situation with gRPC in the browser right now isn't ideal. Moreover, the client-side story -- interaction with React/Redux, client-side catching and prefetching, relationships and so on -- is nearly non-existent. GraphQL is better suited to how JS web apps work. In particular, GraphQL is designed to work with arbitrarily nested graphs of objects at dynamic levels of detail, in a way that makes caching, prefetching and so on fairly simple. And it speaks JSON fluently. gRPC's payloads are fixed, and if you want levels of detail ("fetch posts with creator"; "fetch posts without creator") you have to invent your own scheme for expressing this. gRPC also isn't particularly developer-friendly when it comes to implementing the client or the server. As with any language-agnostic RPC layer, the interfaces tend to be quite sharp-edged: For example, it's relatively awkward to write services that deal with heterogenous collections of objects ("oneof" fields are limited), and arbitrary structured — as opposed to schema-based that can be expressed with the Proto IDL — data (while there's the "well-known" type Value that can effectively express JSON data, it's easier just to wrap JSON in a proto string). GraphQL is much smoother to implement the client. Less so for the server, but it's all about graphs of objects, so it has the benefit that every server is essentially implemented the same way (the "verbs" are the same). GraphQL's introspection story is also better. gRPC has facilities for probing an API without having the schema at hand, but GraphQL arguably has better tools here for now.

pjmlp 8y ago
> GraphQL is better suited to how JS web apps work. If the server side is also JS, because it is just a pain in anything else. I am yet to see a good reason to move away from the flexibility, and most relevant, the tooling of REST.
- scaryclam 8y ago
  A few months ago I'd have agreed with you. However, I've recently created a couple of PoCs that changed my mind. The trick however, is to ignore how a lot of people seem to use GraphQL. Just treat it as another view layer that happens to come with schemas. Keep it as far away from your data layer as you can and it's a lot like working with regular old json and rest, with the added benefit of being able to request data in a more flexible manner.
- snorremd 8y ago
  I've built a simple GraphQL server in Clojure using the Lacinia (https://github.com/walmartlabs/lacinia https://github.com/walmartlabs/lacinia) library. It is about as nice as Apollo to be honest, but you would obviously need to know your way around Clojure. Lacinia tries to be feature complete (as defined by Apollo Server and GraphQL spec), but obviously does not support everything Apollo does (remote schemas and graphql endpoints for example). I have not tried any GraphQL server libraries in other languages, so I can't speak for people using C#, Java, or some other language. I think the tooling around GraphQL is quickly approaching a point where it is better to use GraphQL then REST for client facing services. The fact that you can more precisely define your data needs and don't have to fetch the world, or make multiple round trips, is a big win. The contract a GraphQL schema provides both during development and runtime is also nice.

pjmlp 8y ago

> GraphQL is better suited to how JS web apps work. If the server side is also JS, because it is just a pain in anything else. I am yet to see a good reason to move away from the flexibility, and most relevant, the tooling of REST.

scaryclam 8y ago
A few months ago I'd have agreed with you. However, I've recently created a couple of PoCs that changed my mind. The trick however, is to ignore how a lot of people seem to use GraphQL. Just treat it as another view layer that happens to come with schemas. Keep it as far away from your data layer as you can and it's a lot like working with regular old json and rest, with the added benefit of being able to request data in a more flexible manner.
snorremd 8y ago
I've built a simple GraphQL server in Clojure using the Lacinia (https://github.com/walmartlabs/lacinia https://github.com/walmartlabs/lacinia) library. It is about as nice as Apollo to be honest, but you would obviously need to know your way around Clojure. Lacinia tries to be feature complete (as defined by Apollo Server and GraphQL spec), but obviously does not support everything Apollo does (remote schemas and graphql endpoints for example). I have not tried any GraphQL server libraries in other languages, so I can't speak for people using C#, Java, or some other language. I think the tooling around GraphQL is quickly approaching a point where it is better to use GraphQL then REST for client facing services. The fact that you can more precisely define your data needs and don't have to fetch the world, or make multiple round trips, is a big win. The contract a GraphQL schema provides both during development and runtime is also nice.