6 ms·

(disclaimer: I worked at Meteor/Apollo for about 5 years) I love the callout to how this is continuing the vision for improving application development started

(disclaimer: I worked at Meteor/Apollo for about 5 years) I love the callout to how this is continuing the vision for improving application development started with Meteor -- it really does feel that way to me. Apollo, supported by GraphQL is IMO really delivering on the vision of making a lot of aspects of client-rendered app development much more straightforward than they have been in the past.

ben_jones 7y ago
Honest question, what about GraphQL is straight forward? As a web developer I've been curious about its hype for a long time but every time I look at its implementation I balk. I have a lot of experience with JSON-REST APIs and RPC systems like gRPC and they both seem clearly superior (especially in tandem with code generators) where as GraphQL seems like a ton of extra work on the client and server side for little gain. When asked most developers say its because you can limit which fields you query, and I have to politely explain to them the existence of an SQL SELECT query...
- apazzolini 7y ago
  The main value prop for me with GraphQL is that it makes data a composable, declarative dependency of a view.
  - ben_jones 7y ago
    So it's a clean abstraction layer? Is that abstraction layer easy to understand, intuitive to train new developers on, and faster to implement then traditional API approaches?
    - apazzolini 7y ago
      - Easy to understand? Yes, I think so. It's very easy to glean what data requirements a component has from its associated GraphQL query. - Intuitive? Queries and subscriptions, yes. In the same sense that a React component using props is intuitive. Mutations and optimistic updates are maybe marginally less intuitive, but not prohibitively so. - Faster to implement? Client-side, absolutely, as there's no need to think about how to retrieve data, you just declare what you want, and Apollo fetches what's necessary. It can also keep track of subscriptions / cache invalidation. Server-side, definitely not. The n+1 problem is tougher than with REST + SQL, and it's harder to make single round trips to the DB to fetch nested data.
      - scns 7y ago
        There are some libraries that hell with that, namely prisma, hasura and postgraphile.
- brad0 7y ago
  It’s understandable that the benefits don’t immediately seem obvious. We have all been working with REST for such a long time that we forgot what didn’t make sense when we were learning REST. A good way to think about GraphQL is it’s data centric as opposed to operation centric. The unit you work with is the object instead of the operation. Object level querying instead of operation level querying Object level auth instead of operation level auth
  - aidos 7y ago
    Wasn’t the whole point of REST that it was object (resource) centric? Not saying graphql isn’t, but there’s not much of a difference in that regard. If anything I’d say graphql is more about the relationships than the objects. Graphql is more composable for querying, so that’s nice. In terms of mutations, it’s basically just RPC again (and a lot of us missed RPC when REST became popular). And then it has a model for subscriptions, but they still feel a little like second class citizens support -wise at the moment. None of these are judgements. Just interesting to compare the 2 ideologies.
- mmckelvy 7y ago
  Completely agree. I think web development is a lot simpler and faster without GraphQL.
  - bigmanwalter 7y ago
    When will people realize that best practices aren't created by Facebook.
  - asark 7y ago
    My issues with it are 1) I already see enough dumb queries (and queries in indefinitely-long loops...) from backend devs, how will the frontend devs have a prayer of writing performant queries with so much distance from the underlying datastore(s)?, and 2) exposing a highly flexible query language to the frontend, given the variety and complexity of GraphQL libraries and the complexity of implementing GraphQL server-side if you don't just use something that does it automagically for you, sets off my spidey-sense "there will be bad security problems here, sooner or later, guaranteed" warnings.
- g_delgado14 7y ago
  I haven't ever used GraphQL (so take what I say with a grain of salt b/c i could be incorrect), but what gets me intrigued by it is that it helps your engineering organization scale by decoupling the back end and the front end. Say, for example, that you have a new UI on your app that requires some data stored on your db. Without graphql, you: A) Re-use existing REST endpoints and compose data that you need on the front end (but remember that browsers have a hard limit on the number of concurrent api requests. Not to mention that some requests can't be sent until others have arrived back with resource id's). So depending on what endpoints you currently have, this may not be a good option given the latency cost of composing many HTTP requests to get all the required data. B) You tell your back end devs to create a brand new route that meets the data requirements of the new UI. With GraphQL, my understanding is that there is zero back end work. You just tell the GraphQL engine what data you need and it magically arrives into your browser.
  - pferdone 7y ago
    > With GraphQL, my understanding is that there is zero back end work. You just tell the GraphQL engine what data you need and it magically arrives into your browser. It doesn‘t quite work like that. Someone still has to implement the backend (resolvers). If you want to request dogs from your backend someone still has to implement the dogs query, but (and I think that‘s one of the greatest things about GQL) as soon as it is implemented, you can introspect your backend and see exactly which properties a dog can have. So you know whether the dog object has a name property, or an isHungry property and so on. So now you can specifically ask for a dog and its name if that‘s all your view needs. Another view might only need the breed, so that‘s what you query for...view specific queries.
- a_wild_dandan 7y ago
  On the front-end, with GraphQL you simply specify exactly the data you want on the client, e.g: `GET localhost/graphql`, with body dogs { name location { city } isAGoodBoy } ...and I get back: dogs: [ { Fido, location: { Boston }, true }, { Spot, location: { Los Angeles }, true }, ... ] No extra fields. My clients page doesn't care about the dog's UUID, weight, etc. No routes. Everything goes to `localhost/graphql`. It makes writing clients an absolute joy, and it works gloriously with React. Tell the server exactly what you want, and get exactly that. On the back-end, every field (name, isAGoodBoy) is a resolver. Maybe it's a simple database call to retrieve that field. Maybe it's some service that pulls crap from an S3 bucket. GraphQL doesn't care. So the level of difficulty of implementing a GQL server is dependent on your back-end. For most folks, you'll just be making calls to a database.
  - dzonga 7y ago
    You can do the same with JSON:API Sparse field-sets. see documentation here https://jsonapi.org/format/#fetching-sparse-fieldsets https://jsonapi.org/format/#fetching-sparse-fieldsets. Hence what you've above is not really an advantage of only Graphql.
    - zbyte64 7y ago
      location in the example is a relationship with it's own fields though. We may want to get the top 5 items related to the locations we are fetching for example. But I think the bigger difference is that we typically expect JSON:API urls to be generated while graphQL queries are more directly edited by the developer. I think that yields an experience that feels more direct.
- seanalltogether 7y ago
  > When asked most developers say its because you can limit which fields you query For me this is one of the biggest headaches I have with a new app I've been assigned to. By allowing all fields to be optional depending on the graphql query, there's no consistency in the objects floating around in your apps data store. When I reference a Person object in my view that I'm using, will phone number be there or not, who knows. Maybe its better when every single page has to request it's own data, but when the model objects are cached to a data store in an app and shared between views, things get really dicey.
  - pferdone 7y ago
    > When I reference a Person object in my view that I'm using, will phone number be there or not, who knows. Well you know, because your view has a query that asks for a Person object with or without a phone number. The cache (your store) is managed by Apollo not yourself.
    - seanalltogether 7y ago
      I theory yes, but in practice react native development seems to be a grab bag of 3rd party libraries and design patterns. Redux, apollo, some typed objects, some untyped objects, stateful wizard views, stateless normal views. Maybe your objects are defined and queried on the view you are looking at, maybe they came from a previous view.
      - pferdone 7y ago
        I‘m not talking about theory here but about my professional experience using GraphQL and Apollo for two years in production code. To be specific: I would hardly have a use-case for Redux when apollo-client already has built in local state handling capabilities. Throw in TypeScript and generate your type interfaces from your schema and your queries and there‘s no second guessing. GraphQL and Apollo is not at fault for people writing bad code who mix patterns and ideas that shouldn‘t go together.
        7y ago
- adamkl 7y ago
  One thing to keep in mind is that GraphQL really supports a different use case than something like gRPC or REST. One of the places where it really shines is providing a queryable API entry point to a graph of interconnected data. This makes it ideal for generally reusable APIs for consumption by a variety of clients (e.g. GitHub's GraphQL API). gRPC interfaces are typically use-case specific, and performance oriented (though GraphQL doesn't specify any sort of transport protocol, so you could always serialize GraphQL request/responses with protobufs to gain some performance over the wire), making them well suited for server-to-server communication, but not generally reusable. REST is resource (i.e. nodes in a graph) based, but doesn't necessarily do a good job of making the relationships explicit and easy to traverse (I'm sure there are good HATOAES implementations out there that address this, but I haven't seen one). Both REST and gRPC have their place, but I think GraphQL is a clear winner when you want to build a single API to service a large number of distinct clients. It really does offer a clear, easy-to-use API abstraction over where ever you might get your data from. Also, since you call out code generation specifically; GraphQL provides a strongly-typed schema that can be introspected against, and the tooling to parse queries/schemas into abstract syntax trees. A large number of tools have been built with these capabilities including a number of different code generators. I've even used a GraphQL schema to generate a matching XSD (ugh) for import into an internal business rules engine. Made integration a breeze.
diveanon 7y ago
Please don't take this as a personal attack, but I was severely dissapointed with Meteor after being a strong proponent for it for several years. I advocated for its use on several projects and was bitten by major performance bottlenecks and its over reliance on MongoDB. GraphQL implementation is great, but does it support relational dB's yet? I am happy to hear that it is still doing well, and I may end up using it for some personal projects. I believe that the problem it is trying to solve is worthwhile. However I became very frustrated when the push for monetization started while the framework itself still seemed like it was in the prototype phase. Please correct me if I am wrong, but Meteor has a place in my memory similar to an ex that I really cared about but hurt me once more than I could stomach.
- NickBusey 7y ago
  As someone who also jumped on the Meteor bandwagon, and is now stuck maintaining a project created with it, run away and do not look back. It is not being maintained by anyone as far as I can tell, more and more packages are breaking by the week it seems like, and the basic 'features' listed 'on the box' of Meteor have never worked. Save yourself some headache and pick a stack with an active community.
  - diveanon 7y ago
    I was afraid I would hear that. Best of luck, don't forget to use all your vacation time.
  - kabes 7y ago
    1. It is being maintained (albeit less active), version 1.9 is in the works. Communication could improve a lot though. 2. What's so hard about maintaining the Meteor project? It's been mostly backwards compatible since versions before 1.0 (released over 5 years ago, when the JS ecosystem was a very different universe). What other JS framework has a comparible track record towards backwards compatability? 3. Third party packages may break and become unmaintained, but this is just as much true on NPM. In the end Meteor is mostly a build-tool (and a pretty good one, with zero-configuration, code splitting, ...) creating a Node application with full NPM compatability.

ben_jones 7y ago

Honest question, what about GraphQL is straight forward? As a web developer I've been curious about its hype for a long time but every time I look at its implementation I balk. I have a lot of experience with JSON-REST APIs and RPC systems like gRPC and they both seem clearly superior (especially in tandem with code generators) where as GraphQL seems like a ton of extra work on the client and server side for little gain. When asked most developers say its because you can limit which fields you query, and I have to politely explain to them the existence of an SQL SELECT query...

apazzolini 7y ago
The main value prop for me with GraphQL is that it makes data a composable, declarative dependency of a view.
- ben_jones 7y ago
  So it's a clean abstraction layer? Is that abstraction layer easy to understand, intuitive to train new developers on, and faster to implement then traditional API approaches?
  - apazzolini 7y ago
    - Easy to understand? Yes, I think so. It's very easy to glean what data requirements a component has from its associated GraphQL query. - Intuitive? Queries and subscriptions, yes. In the same sense that a React component using props is intuitive. Mutations and optimistic updates are maybe marginally less intuitive, but not prohibitively so. - Faster to implement? Client-side, absolutely, as there's no need to think about how to retrieve data, you just declare what you want, and Apollo fetches what's necessary. It can also keep track of subscriptions / cache invalidation. Server-side, definitely not. The n+1 problem is tougher than with REST + SQL, and it's harder to make single round trips to the DB to fetch nested data.
    - scns 7y ago
      There are some libraries that hell with that, namely prisma, hasura and postgraphile.
brad0 7y ago
It’s understandable that the benefits don’t immediately seem obvious. We have all been working with REST for such a long time that we forgot what didn’t make sense when we were learning REST. A good way to think about GraphQL is it’s data centric as opposed to operation centric. The unit you work with is the object instead of the operation. Object level querying instead of operation level querying Object level auth instead of operation level auth
- aidos 7y ago
  Wasn’t the whole point of REST that it was object (resource) centric? Not saying graphql isn’t, but there’s not much of a difference in that regard. If anything I’d say graphql is more about the relationships than the objects. Graphql is more composable for querying, so that’s nice. In terms of mutations, it’s basically just RPC again (and a lot of us missed RPC when REST became popular). And then it has a model for subscriptions, but they still feel a little like second class citizens support -wise at the moment. None of these are judgements. Just interesting to compare the 2 ideologies.
mmckelvy 7y ago
Completely agree. I think web development is a lot simpler and faster without GraphQL.
- bigmanwalter 7y ago
  When will people realize that best practices aren't created by Facebook.
- asark 7y ago
  My issues with it are 1) I already see enough dumb queries (and queries in indefinitely-long loops...) from backend devs, how will the frontend devs have a prayer of writing performant queries with so much distance from the underlying datastore(s)?, and 2) exposing a highly flexible query language to the frontend, given the variety and complexity of GraphQL libraries and the complexity of implementing GraphQL server-side if you don't just use something that does it automagically for you, sets off my spidey-sense "there will be bad security problems here, sooner or later, guaranteed" warnings.
g_delgado14 7y ago
I haven't ever used GraphQL (so take what I say with a grain of salt b/c i could be incorrect), but what gets me intrigued by it is that it helps your engineering organization scale by decoupling the back end and the front end. Say, for example, that you have a new UI on your app that requires some data stored on your db. Without graphql, you: A) Re-use existing REST endpoints and compose data that you need on the front end (but remember that browsers have a hard limit on the number of concurrent api requests. Not to mention that some requests can't be sent until others have arrived back with resource id's). So depending on what endpoints you currently have, this may not be a good option given the latency cost of composing many HTTP requests to get all the required data. B) You tell your back end devs to create a brand new route that meets the data requirements of the new UI. With GraphQL, my understanding is that there is zero back end work. You just tell the GraphQL engine what data you need and it magically arrives into your browser.
- pferdone 7y ago
  > With GraphQL, my understanding is that there is zero back end work. You just tell the GraphQL engine what data you need and it magically arrives into your browser. It doesn‘t quite work like that. Someone still has to implement the backend (resolvers). If you want to request dogs from your backend someone still has to implement the dogs query, but (and I think that‘s one of the greatest things about GQL) as soon as it is implemented, you can introspect your backend and see exactly which properties a dog can have. So you know whether the dog object has a name property, or an isHungry property and so on. So now you can specifically ask for a dog and its name if that‘s all your view needs. Another view might only need the breed, so that‘s what you query for...view specific queries.
a_wild_dandan 7y ago
On the front-end, with GraphQL you simply specify exactly the data you want on the client, e.g: `GET localhost/graphql`, with body dogs { name location { city } isAGoodBoy } ...and I get back: dogs: [ { Fido, location: { Boston }, true }, { Spot, location: { Los Angeles }, true }, ... ] No extra fields. My clients page doesn't care about the dog's UUID, weight, etc. No routes. Everything goes to `localhost/graphql`. It makes writing clients an absolute joy, and it works gloriously with React. Tell the server exactly what you want, and get exactly that. On the back-end, every field (name, isAGoodBoy) is a resolver. Maybe it's a simple database call to retrieve that field. Maybe it's some service that pulls crap from an S3 bucket. GraphQL doesn't care. So the level of difficulty of implementing a GQL server is dependent on your back-end. For most folks, you'll just be making calls to a database.
- dzonga 7y ago
  You can do the same with JSON:API Sparse field-sets. see documentation here https://jsonapi.org/format/#fetching-sparse-fieldsets https://jsonapi.org/format/#fetching-sparse-fieldsets. Hence what you've above is not really an advantage of only Graphql.
  - zbyte64 7y ago
    location in the example is a relationship with it's own fields though. We may want to get the top 5 items related to the locations we are fetching for example. But I think the bigger difference is that we typically expect JSON:API urls to be generated while graphQL queries are more directly edited by the developer. I think that yields an experience that feels more direct.
seanalltogether 7y ago
> When asked most developers say its because you can limit which fields you query For me this is one of the biggest headaches I have with a new app I've been assigned to. By allowing all fields to be optional depending on the graphql query, there's no consistency in the objects floating around in your apps data store. When I reference a Person object in my view that I'm using, will phone number be there or not, who knows. Maybe its better when every single page has to request it's own data, but when the model objects are cached to a data store in an app and shared between views, things get really dicey.
- pferdone 7y ago
  > When I reference a Person object in my view that I'm using, will phone number be there or not, who knows. Well you know, because your view has a query that asks for a Person object with or without a phone number. The cache (your store) is managed by Apollo not yourself.
  - seanalltogether 7y ago
    I theory yes, but in practice react native development seems to be a grab bag of 3rd party libraries and design patterns. Redux, apollo, some typed objects, some untyped objects, stateful wizard views, stateless normal views. Maybe your objects are defined and queried on the view you are looking at, maybe they came from a previous view.
    - pferdone 7y ago
      I‘m not talking about theory here but about my professional experience using GraphQL and Apollo for two years in production code. To be specific: I would hardly have a use-case for Redux when apollo-client already has built in local state handling capabilities. Throw in TypeScript and generate your type interfaces from your schema and your queries and there‘s no second guessing. GraphQL and Apollo is not at fault for people writing bad code who mix patterns and ideas that shouldn‘t go together.
      - 7y ago
adamkl 7y ago
One thing to keep in mind is that GraphQL really supports a different use case than something like gRPC or REST. One of the places where it really shines is providing a queryable API entry point to a graph of interconnected data. This makes it ideal for generally reusable APIs for consumption by a variety of clients (e.g. GitHub's GraphQL API). gRPC interfaces are typically use-case specific, and performance oriented (though GraphQL doesn't specify any sort of transport protocol, so you could always serialize GraphQL request/responses with protobufs to gain some performance over the wire), making them well suited for server-to-server communication, but not generally reusable. REST is resource (i.e. nodes in a graph) based, but doesn't necessarily do a good job of making the relationships explicit and easy to traverse (I'm sure there are good HATOAES implementations out there that address this, but I haven't seen one). Both REST and gRPC have their place, but I think GraphQL is a clear winner when you want to build a single API to service a large number of distinct clients. It really does offer a clear, easy-to-use API abstraction over where ever you might get your data from. Also, since you call out code generation specifically; GraphQL provides a strongly-typed schema that can be introspected against, and the tooling to parse queries/schemas into abstract syntax trees. A large number of tools have been built with these capabilities including a number of different code generators. I've even used a GraphQL schema to generate a matching XSD (ugh) for import into an internal business rules engine. Made integration a breeze.

diveanon 7y ago

Please don't take this as a personal attack, but I was severely dissapointed with Meteor after being a strong proponent for it for several years. I advocated for its use on several projects and was bitten by major performance bottlenecks and its over reliance on MongoDB. GraphQL implementation is great, but does it support relational dB's yet? I am happy to hear that it is still doing well, and I may end up using it for some personal projects. I believe that the problem it is trying to solve is worthwhile. However I became very frustrated when the push for monetization started while the framework itself still seemed like it was in the prototype phase. Please correct me if I am wrong, but Meteor has a place in my memory similar to an ex that I really cared about but hurt me once more than I could stomach.

NickBusey 7y ago
As someone who also jumped on the Meteor bandwagon, and is now stuck maintaining a project created with it, run away and do not look back. It is not being maintained by anyone as far as I can tell, more and more packages are breaking by the week it seems like, and the basic 'features' listed 'on the box' of Meteor have never worked. Save yourself some headache and pick a stack with an active community.
- diveanon 7y ago
  I was afraid I would hear that. Best of luck, don't forget to use all your vacation time.
- kabes 7y ago
  1. It is being maintained (albeit less active), version 1.9 is in the works. Communication could improve a lot though. 2. What's so hard about maintaining the Meteor project? It's been mostly backwards compatible since versions before 1.0 (released over 5 years ago, when the JS ecosystem was a very different universe). What other JS framework has a comparible track record towards backwards compatability? 3. Third party packages may break and become unmaintained, but this is just as much true on NPM. In the end Meteor is mostly a build-tool (and a pretty good one, with zero-configuration, code splitting, ...) creating a Node application with full NPM compatability.