4 ms·
Have used both, and don’t like either. I actually DO like very statically typed schemas, but you can easily do this with json over REST, and using IDLs to gene
by yashap 8y ago
Have used both, and don’t like either. I actually DO like very statically typed schemas, but you can easily do this with json over REST, and using IDLs to generate SDKs.
For gRPC vs. REST, I just don’t see the benefits. Performance wins of gRPC are extremely minimal for most backends, ”push based” workflows can easily be handled with webhooks (or message queues), so why am I throwing out extremely mature technology (and tooling/middleware!) that every dev is very familiar with?
For GraphQL, reducing client/datacentre round trips is nice, but can also easily be achieved with RESTful “coordination” services, that serve the front end specifically, and do nothing but stringing together calls to backend services. Why force people to learn another complex technology for that? “Returning smaller payloads” makes minimal impact in practice, and GraphQL requests are MASSIVE compared to REST requests, so you often end up with a performance loss, not gain. Also, GraphQL requests are way harder to glance at in the browser, you can’t just look for GET /dog/123, you have to peek into all the request bodies. And again, all the great REST middleware stops working, because you’re doing RPC.
Basically I see them both as extra complexity with little payoff.
- cheapsteak 8y agoCurious to know if you would count "ecosystem" as a point towards either? Afaik there isn't a standardized way of creating statically typed schemas for REST. A standard statically typed schema like GraphQL's allows a community to create and maintain tooling around it. A person would create"[some tool] for GraphQL" instead of "[some tool] for [specific api]"
- bcheung 8y agoThere's Open API Specification (Swagger). It's more documentation than strict protocol enforcement though.
- bcheung 8y agoIn theory, yes, but in the case of GraphQL, I found it was very difficult to generate schemas dynamically. Factoring out common fields was not possible. Common fields in schemas had to be duplicated and there was no concept of an include/mixin/extends/etc. Best technique was generating plaintext strings of GraphQL programmatically (losing any editor or type checking support). Dropping down to the AST layer of GraphQL is a bit more programmatic but not really an ideal level of abstraction to work at. It was too verbose and low level. REST integrates well with native JS constructs (it's just data) so it's much easier to compose and use metaprogramming techniques.
- zbentley 8y ago> For GraphQL, reducing client/datacentre round trips is nice, but can also easily be achieved with RESTful “coordination” services, that serve the front end specifically, and do nothing but stringing together calls to backend services. I mean . . . that's all a GraphQL "server" (or parser/aggregator endpoint) is. > Why force people to learn another complex technology for that? Because most later-stage 'RESTful “coordination” services' like you describe probably already include: 1) a DSL of some kind for expressing what data you like; 2) significant complexity for expressing grouping or deduplication logic; 3) complex requirements for coordinated backend services so that their "raw" data can be rolled up un an efficient and uniform way by the coordinator. That's complex, and new to most people--pretty much everyone who starts work on it, if you built it yourself. GraphQL queries and aggregation layers are similarly complex, but new to fewer people, and better supported. I think there are some big problems with GraphQL as a concept/technology (I am currently pushing back against its adoption in my area), but the above are not the right criticisms.