How complete is Apollo? How to prepare to use in near future?


#1

I’m starting at a startup that got funded and rebuilding their product, and wondering if we may be able to use Apollo right now on this greenfield project. Apollo may not be quite ready for production use, if that’s the case, how can we prepare (i.e. set up our app) for using Apollo in the near future?

Is Apollo client ready for production use? What features of Apollo are stable and what features are missing? (how complete is it compared to Relay?) What are considerations when deciding to use Apollo or not? It would be nice if there’s some document and/or roadmap about this (maybe there is somewhere?) I think maybe @sashko is most qualified to answer!

Can Apollo server be used independently from Apollo client? For example could I use Apollo server with Relay and can I use Apollo client with another GraphQL server? (I assume the answer is Yes, but want to check). I saw recommendation to use dataloader, but I’m not sure if this duplicates functionality in Apollo or if it is something independent.

Sorry for so many questions, but I could not find very much info on the Apollo website and I think other people could also benefit from understanding these answers!


#2

I’ve been using Apollo Client for a while and have also tried Lokka and plain old fetch to send an AJAX call. I haven’t had the change to use Apollo server yet but plan to this month.

Is Apollo client ready for production use?

I’m using Apollo Client on 2 prod apps and it’s been working very well. Overall i’m extremely impressed. Recently they’ve changed the API of the apollo-react so that it’s much less verbose than it was before. It’s actually more clean than Relay now IMHO. This was a breaking change but very easy to migrate (about 2min per query). Overall the breaking changes have been very impressively low compared to Redux and React Router. Those changed so fast that it was painful to just build an app. I also started with Lokka thinking it would be more stable than Apollo but there is missing functionality and it requires a lot of wiring if using with Redux.

What features of Apollo are stable and what features are missing?

Everything has been stable so far. I haven’t used watchQuery in prod yet (no need) but from my sandbox tests it worked great. Query batching seems like it (and other Apollo server only features) has “potential” for being more bug prone as well because it’s a newer feature. I also haven’t used these as I have a non node server.

Of the 75 open issues, 7 of them are bugs and most are a few days old:

I previously thought that a better error handling solution on the client was missing because handling errors manually is also a bit verbose. However, it has an afterWare (like middleware but after) method in the initialize.This can be used to handle all graphql/http errors on a global level so it can display an alert automatically.

I’ve discovered not all errors should be shown to the client but it’s helpful to send them to client for error logging or behind the scenes action. What i’ve started doing is returning an error like this: "[sanitized] Your password is too short" and then the afterware will use a regex for [sanitized] and it will alert ``Your password is too short".

Can Apollo server be used independently from Apollo client?

You could use something like Lokka or jQuery to send requests to an Apollo server and that would work as well.

For example could I use Apollo server with Relay

I’m not sure but I dont’ think so. I’m pretty sure the server has to be “relay ready” because it adds more complexity on top of GraphQL.

can I use Apollo client with another GraphQL server?

Yes. I’m using Apollo Client with Absinthe GraphQL and it’s working great. There are some Apollo specific features like query batching or whitelisting that I can’t use but not a big deal.

I saw recommendation to use dataloader5, but I’m not sure if this duplicates functionality in Apollo or if it is something independent.

I don’t know a lot about it but as far as i’m aware Apollo doesn’t have anything to cache database queries so you could use dataloader with Apollo if needed. I think it’s main use case is to prevent expensive n+1 queries and seems to be most useful with SQL. I’m using Elixir and the Ecto library lets you preload joins to prevent n+1 queries and in general Russian doll caching has proven to be slower on that platform in benchmarks i’ve seen. I think it’s safe to say you can skip it for day 1 of a greenfield and reach for it when queries get expensive. IMHO caching can make simple things very complex. The one case where it might save a lot of DB resources is when you need to use watchQuery for long polling with a fast refetch rate.

If you have any other GraphQL questions i’d love to know so I can add them to my upcoming Meteor subscriptions to Apollo migration screencast!


#3

By the way the answer is yes, you can use Relay with Apollo Server, but just like with any GraphQL server you need to put in effort to make it compatible with Relay (this is the case with every GraphQL server I’m aware of).

You can think of Apollo server as a replacement for express-GraphQL with a few nice features added and a simpler implementation.


#4

This is very helpful @SkinnyGeek1010. Some great tips here!

There’s just a lot new technology to keep up with. I guess this is Javascript fatigue 2016. Good stuff, but lots new to learn. Currently we are also evaluating Angular 2 + Ionic. I prefer React, but I also understand why people go for Angular. There’s so many choices and new things to learn with React. With Angular, there is the perception that it’s “batteries included”. But then I think GraphQL will be a huge win, and it will work initially better with React.

Look forward to seeing your Apollo migration screencast. Where can I follow you to find out about your screencast?


#5

Apollo stuff works just as well with Angular as React right now. I don’t see any reason that GraphQL would be better to use with React! It did come from the same company (Facebook) but the GraphQL ecosystem isn’t just React-specific.


#6

Keep an eye out here:

I’m shooting for the next week or two depending on how many other tasks bump priority but I def. have to spike it out.


#7

Ok, it may be more of matter of perception. At least there is better documentation, more examples of using GraphQL with React.

To be honest I wish GraphQL would work better with React, I’m trying to convince my team to use React, I’m fighting the perception that Angular is better, just because it has more popularity and momentum. React is a hard sell among people who aren’t hardcore JS devs. I believe there’s still the perception that OOP (Angular) is easier than React, which a little esoteric for some developers due to its declarative approach. :frowning:


#8

If it makes you feel any better, I’m talking about Angular 2, so you can still argue it doesn’t work as well with Angular 1 :]


#9

Not much help, I’m afraid. True believers have already latched on to Angular 2 as the next big thing. This ionic 2 page which seems like it was penned by Steve Jobs isn’t helping me either.


#10

which seems like it was penned by Steve Jobs

:joy: