9 ms·

Apollo Client 0.5

62 points by clessg 10y ago

saikat 10y ago
Having worked with a lot of Javascript frameworks aimed at creating web applications/SPAs (used Cappuccino to build a wireframing tool, Backbone.js to build a dashboard for a payments provider, React/Relay to build a phone calling tool and events platform, and now React/Apollo to build a peer-to-peer texting tool), I can say that React/Apollo/GraphQL is my new go-to stack for new JS projects. It's a pleasure to work with, and a lot of the pain points of creating large apps with JS in the past are handled very well. Congrats to the Apollo team!
- johntran 10y ago
  What are the pros and cons between Relay and Apollo?
  - kremonte 10y ago
    After working with Apollo for a couple weeks on a non-trivial side project, I'm particularly happy with how unopinionated the library is. While it's super hip to complain about JS fatigue these days, Relay just wanted to make too many decisions. In that sense, it's a pro and a con: Relay will make more decisions for you, but will present difficulty if you've already made some of those decisions yourself. Apollo's using Redux is great. The model and API are well understood so it's easy to bring developers on board. Relay seems to follow the same principles, but does them in its own way. Relay is also opinionated about your server's responses. I know that the cursor pattern with edges and nodes is great for performant pagination, but then our schema has to conform to that spec and I really don't enjoy spending time explaining why we can't just get that user's photos, we have to get that user's photos' edges' nodes. Graph theory has a place, but it's not that close to the frontend, IMO. More than anything, it seemed very easy to get up and running with Apollo. After reading lots of Relay docs, it still took a lot of experimentation and effort to get this running to begin with. I am very happy with Apollo's docs.
  - helfer5 10y ago
    Before we started building Apollo Client, we actually tried Relay, but found it difficult to adopt, so we started a community effort to build a more flexible GraphQL client. Our main goals were to make incrementally adoptable, compatible with all view layers and easy to understand/debug. While Apollo is easier to adopt and use, it's still under active development, so it's not as stable as Relay, and hasn't been optimized for performance the way that Relay has. disclaimer: I work on Apollo Client
    - scoot 10y ago
      /disclaimer/disclosure/ - when you disclose something, it's a disclosure. (Sorry, personal bugbear, along with e.g. / i.e. confusion. Both are rampant on HN! :) )
crucialfelix 10y ago
I spent a day or so with relay and kept being blocked by mysteries or tired out from the amount of code you need to set up for a mutation. Branched and tried it with Apollo and everything has been pretty easy going. Merging Fragments in the style of relay were my main concern with Apollo but they do have this now. All in all much more flexible and readable than relay.
djmashko2 10y ago
One of the developers working on Apollo GraphQL stuff here, happy answer any questions! So exciting to see this on HN.
- pinouchon 10y ago
  Do you plan to make an integration with Meteor ? My main frustration with Meteor have been than it is tied to mongo (and not a relational db). I see Apollo as a way to plug Meteor with any data backend. If I'm not mistaken, that was the original sales pitch of Apollo. So my question is: should I have high hopes of being able to work with Meteor and Postgres with the help of Apollo?
  - djmashko2 10y ago
    A lot of people are doing that already! You can use Meteor as the build and deployment system for your app, and use Apollo for data. The main remaining blocker is the accounts system, since it is still tied to a particular MongoDB schema. We're working with people in the community on some ideas about how to make Meteor Accounts database-agnostic, so once that is possible it will truly be possible to build a Meteor app on top of any backend.
    - pinouchon 10y ago
      Can I find any moderate-size app that uses Meteor with Appolo and Postgres as an example? The Meteor guide and tutorials, as well as most well-known Meteor open source apps (wekan, telescope...) use mongo collections. And since Meteor is a full stack framework, I would love to see a guide about how to best structure an app with Meteor and Apollo (I'm in the camp where I don't like to fiddle around with what's the best js stack. I'm happy to have the framework authors decide that for me, and get down writing my goddamn app)
      - djmashko2 10y ago
        It's meant to be part of a decoupled stack where you can pick and choose different options for UI, backend, etc. We're constantly working towards having clearer integrations and patterns. If you just want to get a thing built without making decisions and putting in some work for integration, I'd just go with the built-in Meteor stuff for now.
anonova 10y ago
I've been wanting to try out vue.js and have a GraphQL endpoint. Apollo seems like a Relay alternative that's not tied to React. Can anyone compare the two (Vue.js+Apollo and React+Relay)?
- djmashko2 10y ago
  I haven't used Vue.js yet (but really want to try!) There's a community integration with Apollo here: https://github.com/Akryum/vue-apollo https://github.com/Akryum/vue-apollo
duaneb 10y ago
This looks really cool. The name is completely unrelated to its function; I thought this was NASA's code. Imagine my disappointment when I saw a javascript library for working with GraphQL!
- sumobob 10y ago
  and then your excitement after checking it out?
  - duaneb 10y ago
    Well it's a nice client! Just had to alter my expectations.
    - djmashko2 10y ago
      Thanks - we went through a ton of different names, and almost all of them had some sort of collision. We try to mention GraphQL up front on all of the content to avoid extended confusion :]
      - clessg 10y ago
        I probably should have included the fact that it's a JS GraphQL client in the title, but I wasn't sure if that would violate HN's "editorializing" rule. On the bright side, we apparently got a few people who thought it had something to do with NASA. Muahaha!
- glasser 10y ago
  Don't worry — you can find that code at https://github.com/chrislgarry/Apollo-11 https://github.com/chrislgarry/Apollo-11
- stevefolta 10y ago
  And I thought it was some kind of retrocomputing project related to Apollo workstations.
bgentry 10y ago
I started a new Ember.js project recently and got frustrated with Ember Data and JSON API. In my experience, it's the weakest part of Ember by far. Out of curiosity, I tried wiring up Apollo Client to my backend instead. Turned out to be very easy to get going. So far I like apollo-client and GraphQL much more than Ember Data. I get full control over what data is being loaded on each route and only fetch exactly what's needed. Mutations with explicit arguments are also much better than the blob.save() / save-everything style encouraged by ember-data. With client-side resolves in the next release, this integration should get even better. Hopefully they'll also switch to using GETs for non-mutation queries to enable some much better caching options.

62 points by clessg 10y ago

Having worked with a lot of Javascript frameworks aimed at creating web applications/SPAs (used Cappuccino to build a wireframing tool, Backbone.js to build a dashboard for a payments provider, React/Relay to build a phone calling tool and events platform, and now React/Apollo to build a peer-to-peer texting tool), I can say that React/Apollo/GraphQL is my new go-to stack for new JS projects. It's a pleasure to work with, and a lot of the pain points of creating large apps with JS in the past are handled very well. Congrats to the Apollo team!

johntran 10y ago
What are the pros and cons between Relay and Apollo?
- kremonte 10y ago
  After working with Apollo for a couple weeks on a non-trivial side project, I'm particularly happy with how unopinionated the library is. While it's super hip to complain about JS fatigue these days, Relay just wanted to make too many decisions. In that sense, it's a pro and a con: Relay will make more decisions for you, but will present difficulty if you've already made some of those decisions yourself. Apollo's using Redux is great. The model and API are well understood so it's easy to bring developers on board. Relay seems to follow the same principles, but does them in its own way. Relay is also opinionated about your server's responses. I know that the cursor pattern with edges and nodes is great for performant pagination, but then our schema has to conform to that spec and I really don't enjoy spending time explaining why we can't just get that user's photos, we have to get that user's photos' edges' nodes. Graph theory has a place, but it's not that close to the frontend, IMO. More than anything, it seemed very easy to get up and running with Apollo. After reading lots of Relay docs, it still took a lot of experimentation and effort to get this running to begin with. I am very happy with Apollo's docs.
- helfer5 10y ago
  Before we started building Apollo Client, we actually tried Relay, but found it difficult to adopt, so we started a community effort to build a more flexible GraphQL client. Our main goals were to make incrementally adoptable, compatible with all view layers and easy to understand/debug. While Apollo is easier to adopt and use, it's still under active development, so it's not as stable as Relay, and hasn't been optimized for performance the way that Relay has. disclaimer: I work on Apollo Client
  - scoot 10y ago
    /disclaimer/disclosure/ - when you disclose something, it's a disclosure. (Sorry, personal bugbear, along with e.g. / i.e. confusion. Both are rampant on HN! :) )

crucialfelix 10y ago

I spent a day or so with relay and kept being blocked by mysteries or tired out from the amount of code you need to set up for a mutation. Branched and tried it with Apollo and everything has been pretty easy going. Merging Fragments in the style of relay were my main concern with Apollo but they do have this now. All in all much more flexible and readable than relay.

djmashko2 10y ago

One of the developers working on Apollo GraphQL stuff here, happy answer any questions! So exciting to see this on HN.

pinouchon 10y ago
Do you plan to make an integration with Meteor ? My main frustration with Meteor have been than it is tied to mongo (and not a relational db). I see Apollo as a way to plug Meteor with any data backend. If I'm not mistaken, that was the original sales pitch of Apollo. So my question is: should I have high hopes of being able to work with Meteor and Postgres with the help of Apollo?
- djmashko2 10y ago
  A lot of people are doing that already! You can use Meteor as the build and deployment system for your app, and use Apollo for data. The main remaining blocker is the accounts system, since it is still tied to a particular MongoDB schema. We're working with people in the community on some ideas about how to make Meteor Accounts database-agnostic, so once that is possible it will truly be possible to build a Meteor app on top of any backend.
  - pinouchon 10y ago
    Can I find any moderate-size app that uses Meteor with Appolo and Postgres as an example? The Meteor guide and tutorials, as well as most well-known Meteor open source apps (wekan, telescope...) use mongo collections. And since Meteor is a full stack framework, I would love to see a guide about how to best structure an app with Meteor and Apollo (I'm in the camp where I don't like to fiddle around with what's the best js stack. I'm happy to have the framework authors decide that for me, and get down writing my goddamn app)
    - djmashko2 10y ago
      It's meant to be part of a decoupled stack where you can pick and choose different options for UI, backend, etc. We're constantly working towards having clearer integrations and patterns. If you just want to get a thing built without making decisions and putting in some work for integration, I'd just go with the built-in Meteor stuff for now.

anonova 10y ago

I've been wanting to try out vue.js and have a GraphQL endpoint. Apollo seems like a Relay alternative that's not tied to React. Can anyone compare the two (Vue.js+Apollo and React+Relay)?

djmashko2 10y ago
I haven't used Vue.js yet (but really want to try!) There's a community integration with Apollo here: https://github.com/Akryum/vue-apollo https://github.com/Akryum/vue-apollo

duaneb 10y ago

This looks really cool. The name is completely unrelated to its function; I thought this was NASA's code. Imagine my disappointment when I saw a javascript library for working with GraphQL!

sumobob 10y ago
and then your excitement after checking it out?
- duaneb 10y ago
  Well it's a nice client! Just had to alter my expectations.
  - djmashko2 10y ago
    Thanks - we went through a ton of different names, and almost all of them had some sort of collision. We try to mention GraphQL up front on all of the content to avoid extended confusion :]
    - clessg 10y ago
      I probably should have included the fact that it's a JS GraphQL client in the title, but I wasn't sure if that would violate HN's "editorializing" rule. On the bright side, we apparently got a few people who thought it had something to do with NASA. Muahaha!
glasser 10y ago
Don't worry — you can find that code at https://github.com/chrislgarry/Apollo-11 https://github.com/chrislgarry/Apollo-11
stevefolta 10y ago
And I thought it was some kind of retrocomputing project related to Apollo workstations.

bgentry 10y ago

I started a new Ember.js project recently and got frustrated with Ember Data and JSON API. In my experience, it's the weakest part of Ember by far. Out of curiosity, I tried wiring up Apollo Client to my backend instead. Turned out to be very easy to get going. So far I like apollo-client and GraphQL much more than Ember Data. I get full control over what data is being loaded on each route and only fetch exactly what's needed. Mutations with explicit arguments are also much better than the blob.save() / save-everything style encouraged by ember-data. With client-side resolves in the next release, this integration should get even better. Hopefully they'll also switch to using GETs for non-mutation queries to enable some much better caching options.