3 ms·

I'm currently rewriting our company's customer-facing web app with this stack, as well as the GraphQL backend. I have to say its an amazing experience so far. I

I'm currently rewriting our company's customer-facing web app with this stack, as well as the GraphQL backend. I have to say its an amazing experience so far. IMO it greatly helps facilitate readable and maintainable code, on both ends of the stack. Having a strict, self-documenting contract between frontend and backend is the biggest selling point for me. Coming from a heavy-client implementation using backbone models, or in another instance Ember Data with JSON-API, React+Apollo feels like a breath of fresh air, and simplifies my life to the extent that I wonder why I get paid so much to do what I do. I would suggest looking at Github's API explorer (https://developer.github.com/v4/explorer/ https://developer.github.com/v4/explorer/). You can assemble graphql queries in there, inspect the results, and copy/paste the exact query into an Apollo component to make your own app. REST is still a bit simpler to implement on the server side but once you have the GraphQL API built it is infinitely more maintainable when you're working with multiple teams, and API consumers, each with their own needs and focus. One weakness I've observed is that since each attribute of an object can make its own DB query, you can have a situation where a single GraphQL query can create dozens, or even hundreds, of individual DB queries, creating a performance issue with a naive implementation. This is mitigated with libraries that batch requests transparently, or with clever structuring of your schema that groups similar attributes into one query. Also, tree-like data structures are not well supported (like a comment thread, where comments can have replies that recurse infinitely. GraphQL straight up doesn't do that) However I think that the benefits outweigh the weaknesses considerably.

joshribakoff 9y ago
You can return an array of nodes, with each node having a depth property. Sometimes the client needs it flattened anyways, it is better for normalization.
tannhaeuser 9y ago
> REST is still a bit simpler ... I don't want to take away from your main point, but I wish at least on HN we could use the term "REST" with its proper meaning, but maybe it's a lost cause. REST has nothing to do with JSON-over-HTTP or pretty endpoint URLs. REST and HATEOAS is about minimal, stateless coupling of web clients and server apps. The idea is that you point your browser at an endpoint, and the user/browser drives forward every further interaction and state evolution by hyperlinks and other affordances presented in the return "representation" (eg. HTML). Specifically, the web client isn't supposed to do requests against out-of-band provided URLs for JSON or other payloads with hard-coded endpoints. I know it might not be a realistic application model for what the Web has evolved into today, but misuse of the term REST has frustrated its inventor since at least 2008 [1]. Edit: as discussed many times here eg. [2] [1]: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... [2]: https://news.ycombinator.com/item?id=3635085 https://news.ycombinator.com/item?id=3635085 - Nobody understands REST or HTTP
- bonesss 9y ago
  > I know it might not be a realistic application model for what the Web has evolved into today, but misuse of the term REST has frustrated [basically everyone] Amen, sister. JSON RPC over HTTP is... you know... the 99% use case. HATEOAS has its place, but IMO and IME that place isn't most of what industry is doing. For whatever reason, though, there is a buzz about actual-REST and HATEOAS that seems both ignorant of the original intent of REST/HATEOAS and of practical development considerations. REST-fullness has been an undefined architectural ideal for over a decade now and shows no signs of convergence of clarity... I would really like a new buzzword for JSON RPC so that I know what the heck people are talking about when they talk about REST. I am tired of guessing, and tired of listening to consultants was poetic about HATEOAS who have clearly never read the white paper... :)
- gr__or 9y ago
  I hear this a lot but I think the point is moot. It kind of reminds me of communists telling me that real communism has never been tried. Okay okay I know, analogies are sinful. Sorry! My point is that this pure definition of REST doesn't conflict with what the parent comment outlined. I'd go even further and say that to implement in this purer, Content-Type agnostic, state-evolution by hyperlinks kind of way makes the implementation even harder (around as hard as it is to implement a GraphQL endpoint).
Blackstone4 9y ago
>One weakness I've observed is that since each attribute of an object can make its own DB query, you can have a situation where a single GraphQL query can create dozens, or even hundreds, of individual DB queries, creating a performance issue with a naive implementation. This is mitigated with libraries that batch requests transparently, or with clever structuring of your schema that groups similar attributes into one query. From my experience writing a GraphQL server, I completely agree. This could really impact performance. I looked at multiple solutions including join-monster[0] and prisma [1] and settled on Prisma which I run on docker between my graphql server and my AWS RDS database. It translates queries into SQL for you :) [0]https://github.com/stems/join-monster https://github.com/stems/join-monster [1]https://github.com/graphcool/prisma https://github.com/graphcool/prisma
- headcanon 9y ago
  I wish I could use those, but the backend I'm working with is DynamoDB, with a relatively normalized data model. As in, we're using a non-relational database in a relational way, which means we're doing joins in javascript. GraphQL for us is a way to at least keep from doing that and abstract our client/server interactions so we can eventually transition to a more sane SQL environment.

joshribakoff 9y ago

You can return an array of nodes, with each node having a depth property. Sometimes the client needs it flattened anyways, it is better for normalization.

tannhaeuser 9y ago

> REST is still a bit simpler ... I don't want to take away from your main point, but I wish at least on HN we could use the term "REST" with its proper meaning, but maybe it's a lost cause. REST has nothing to do with JSON-over-HTTP or pretty endpoint URLs. REST and HATEOAS is about minimal, stateless coupling of web clients and server apps. The idea is that you point your browser at an endpoint, and the user/browser drives forward every further interaction and state evolution by hyperlinks and other affordances presented in the return "representation" (eg. HTML). Specifically, the web client isn't supposed to do requests against out-of-band provided URLs for JSON or other payloads with hard-coded endpoints. I know it might not be a realistic application model for what the Web has evolved into today, but misuse of the term REST has frustrated its inventor since at least 2008 [1]. Edit: as discussed many times here eg. [2] [1]: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... [2]: https://news.ycombinator.com/item?id=3635085 https://news.ycombinator.com/item?id=3635085 - Nobody understands REST or HTTP

bonesss 9y ago
> I know it might not be a realistic application model for what the Web has evolved into today, but misuse of the term REST has frustrated [basically everyone] Amen, sister. JSON RPC over HTTP is... you know... the 99% use case. HATEOAS has its place, but IMO and IME that place isn't most of what industry is doing. For whatever reason, though, there is a buzz about actual-REST and HATEOAS that seems both ignorant of the original intent of REST/HATEOAS and of practical development considerations. REST-fullness has been an undefined architectural ideal for over a decade now and shows no signs of convergence of clarity... I would really like a new buzzword for JSON RPC so that I know what the heck people are talking about when they talk about REST. I am tired of guessing, and tired of listening to consultants was poetic about HATEOAS who have clearly never read the white paper... :)
gr__or 9y ago
I hear this a lot but I think the point is moot. It kind of reminds me of communists telling me that real communism has never been tried. Okay okay I know, analogies are sinful. Sorry! My point is that this pure definition of REST doesn't conflict with what the parent comment outlined. I'd go even further and say that to implement in this purer, Content-Type agnostic, state-evolution by hyperlinks kind of way makes the implementation even harder (around as hard as it is to implement a GraphQL endpoint).

Blackstone4 9y ago

>One weakness I've observed is that since each attribute of an object can make its own DB query, you can have a situation where a single GraphQL query can create dozens, or even hundreds, of individual DB queries, creating a performance issue with a naive implementation. This is mitigated with libraries that batch requests transparently, or with clever structuring of your schema that groups similar attributes into one query. From my experience writing a GraphQL server, I completely agree. This could really impact performance. I looked at multiple solutions including join-monster[0] and prisma [1] and settled on Prisma which I run on docker between my graphql server and my AWS RDS database. It translates queries into SQL for you :) [0]https://github.com/stems/join-monster https://github.com/stems/join-monster [1]https://github.com/graphcool/prisma https://github.com/graphcool/prisma

headcanon 9y ago
I wish I could use those, but the backend I'm working with is DynamoDB, with a relatively normalized data model. As in, we're using a non-relational database in a relational way, which means we're doing joins in javascript. GraphQL for us is a way to at least keep from doing that and abstract our client/server interactions so we can eventually transition to a more sane SQL environment.