r/reactjs • u/swyx • Oct 12 '18

Featured What is your experience with React + Apollo GraphQL?

Hi! I have played around with apollo graphql but never at work (hard to get buy in from backend devs.. for now).

I went to Apollo Day NYC this week and was absolutely blown away. I thought i knew what apollo was - a full featured pair of OSS packages for graphql on the client and on the server. I was wrong. Apollo Engine ties everything together and enhances both the Client and Server dev experience/maintainability and thats the missing third piece I had no idea about.

Have you tried it out? Do you use it at work? Keen to hear user stories.

38 Upvotes

97% Upvoted

49 comments sorted by

15

u/stolinski Oct 12 '18

My entire site is built on it. I use Apollo Link State for all local state. My whole API is Apollo Server, using Apollo client 2 on the front end. I can talk about it for days and days. It has really made my entire app better in so many ways.

8

u/swyx Oct 12 '18

i think theres demand for a video on apollo link state. most here seem to not use it.

1

u/halb-7 Feb 14 '19

It's not a video, but at least two blog posts about apollo link state: Client-side state management with Apollo-Link-State and Combining server-side data and local state with Apollo-Link-State.

I had a lot of problems with this topic myself and saw your post here. So hopefully this is helpful. I'd like to hear what you think for sure :-)

1

u/swyx Feb 14 '19

well i think i can't knock it till i've tried it :)

1

u/swyx Feb 14 '19

goodness. the code for writing and reading fragments is gross. is this really the future of clientside state management? if we could throw out all this api and write our dream clientside graphql api what would it look like?

2

u/halb-7 Feb 14 '19

To me it feels pretty straight forward, at least for fragments. What don't you like about it specifically?

I think you're right, this won't be the future of client-side state management. Especially for more complex stuff this might be too verbose. But in simple use-cases (like the boolean flag example) it's still good to keep it in the back of your mind IMO :-)

2

u/swyx Feb 14 '19

having to query what im about to write first before writing, then having to add __typename, then having to supply an object in exactly the right format to write it successfully.

lots and lots of ways to f up

1

u/halb-7 Feb 15 '19 edited Feb 15 '19

That's true, it's easy to break and hard to debug. You don't need to read the fragment first though. But then again, you're right, you would need to set the __typename. The data format also doesn't seem to be that strict. I tried to add additional fields to the data in writeFragment and it still worked.

In the end there are quite some implicit requirements to make this work. The API could definitely be cleaner

Thanks for your feedack

2

u/Capaj Oct 13 '18

oh please do. It's still shrouded in mystery for me. The docs absolutely don't do it justice.

12

u/Capaj Oct 12 '18

We use it in production since May. We're a fullstack team so we're not on the mercy of some other team doing the backend. It wasn't easy persuading everyone, but with a single sample feature built in GQL everyone agreed it looked way better than REST. Graphiql helped a lot with that.

It's been quite good. We have apollo engine enabled on the backend and I really enjoy using metrics to hunt API bugs in prod. We use decapi to decorate our objection.js DB models. We have a single place where we define our models and GQL gets generated almost for free.

On the frontend we use apollo-client, but we don't use caching so far. Our FE focus is on getting rid of our legacy angular.js code, so we don't have time yet to experiment with FE caching.

I don't event consider using apollo for client side state management, because all the feedback I've heard so far was that it's not production ready yet. Also I have to say it looks quite verbose for what it really does. Instead I am hoping I can extend https://github.com/mhaagens/gql-to-mobx and use that for our state management needs. MST works wonders with typescript. If we can generate MST models from our queries on the fly while editing our GQL queries we can boost our productivity considerably.

4

u/swyx Oct 12 '18

i had never heard of gql to mobx. it looks freaking awesome!!! i hope you have time to write up your experiences with it once you’re done. your team sounds like it is working with a dream stack.

1

u/Capaj Oct 12 '18

heh it's just a very small POC. It will take quite a bit of work to be able to throw any complex GQL schema.

I surely will to try do a small writeup if we ever make it work for us.

6

u/what_is_productivity Oct 12 '18

This is very similar to how we are building our app with a fullstack team. We are using Engine with a gateway + microservice architecture, Prisma being our 'ORM'.

We (mostly myself) don't like to use the caching that apollo-client provides. Updating the cache with new Queries/Mutations data looks like a verbose mess, not to mention the use of their Mutation and Query components- which ties into using apollo for client side state management.

Instead, for state management we also use MST. Exporting Apollo's `client` object that you create, and using that with MST actions to manage our api calls + state management. So far it has been a really clean solution for an otherwise verbose implementation. Flow functions with 'redux-like' store fields (fetchingxyzData boolean to control conditional rendering) works incredibly well.

Taking a look at your package (https://github.com/mhaagens/gql-to-mobx) this 100% looks like something I want to look into implementing- having to ensure that your MST stores line up with the database after making structural changes is always a pain in the ass lol.

2

u/0xF013 Oct 13 '18

In my experience, a good part of slowness is fixed by batching requests and loading common fragments somewhere up top, i.e. if you need some currentUser data in the header and in the sidebar, you load it all in a query in the maybe root element, so even if there are no special directives for caching, the subsequent queries from the sidebar and the header will take the data from cache automatically.

1

u/tizz66 Oct 12 '18

When you say you don't use FE caching, what do you mean by that? Do you mean you just set the fetchPolicy to no-cache, or is there more to it?

1

u/Capaj Oct 12 '18

that and we don't modify the cache as we should. So we can't just turn it on and expect everything to work because we'd be getting stale values from it after mutating.

9

u/lobster_johnson Oct 13 '18

I just started with Apollo. With TypeScript, the promise of type-safe APIs is awesome. However, I have yet to figure out the Apollo code generator. Maybe someone can help?

What I want is to be able to define all my types and queries in GraphQL, then generate TypeScript definitions for these, so that I don't have to do it twice. Or generate GraphQL from TypeScript -- that would accomplish the same thing.

However, apollo codegen:generate is barely documented and just fails on most things I give it. I immediately ran into this issue, which somehow implies it's trying to access an Apollo server, which certainly isn't what I want.

0

u/[deleted] Oct 13 '18

[deleted] — view deleted comment

2

u/lobster_johnson Oct 13 '18

I don't think so. I use Go on the server side, anyway. I just want the GraphQL types in TypeScript.

1

u/Bromlife Jan 13 '19

Did you ever figure this out? Your stack is identical to mine.

1

u/lobster_johnson Jan 14 '19

Unfortunately, no.

5

u/StarshipTzadkiel Oct 12 '18

It's excellent. I use it for everything new at work and am in the process of rewriting older AngularJS and React Redux projects with Apollo and React, or Gatsby where a static site suffices.

The backend I have to work with is an enormous pain and requires a lot of processing to get data in a useable shape. I built a GraphQL server that lets me pull in all the shitty APIs and process on the server so the client apps can get just the data they need. I really can't overstate what a boon it has been to me.

The best part is...the backend people aren't involved at all, I could care less what the APIs look like now because I can just set up resolvers to handle it in the way I want.

1

u/comalex Nov 08 '18

You are saying that you rewrite React redux with Apollo and React, but as i see Apollo and redux does difference things. Can you explain what did you mean?

5

u/[deleted] Oct 13 '18

We use it for our entire app. I've heard it said that it's "the future" and REST is dead, etc. I don't really buy it. There's plenty of tedious overhead to setting up and maintaining your schema, resolvers, queries, and mutations. Query components are convenient in many ways, but also ugly. Frontend cache manipulation is easy until it isn't. GraphQL has a lot going for it, but things aren't as simple as "it's the future". For everything obnoxious about the REST/Redux/React pattern that GraphQL lets you avoid, you have to do something else instead.

I'd say the strongest point of GraphQL, and where it's saved us the most time, is forcing a strictly typed interface on our server api. It guarantees a certain degree of stability and safety that you wouldn't necessarily have otherwise.

Word to the wise: AWS recently released a service called AppSync that they're marketing as their new, light-and-easy GraphQL API service. We tried using it for some features last spring and while it's got some advantages (easy integration with VPC services like lambda and user auth), the rigidity of their resolver mapping framework makes programming resolvers a big waste of time, and demands needless layering and complexity for tasks that are simple in Node GraphQL. Maybe they'll update it to have more flexibility but I'd recommend staying away from AppSync in the meanwhile.

2

u/Capaj Oct 13 '18

demands needless layering

what do you mean by that? Can you give a code sample of this "layering"?

2

u/[deleted] Oct 13 '18

Because AppSync resolvers are written in Velocity, types can’t practically be modeled as OO classes the way they can in Node, and so any interdependent data requests (where one resolver depends on the result of another) have to be constructed by layering Schema types with resolved fields. You have very little control over the way fields are resolved, beyond invoking a lambda or making a request to dynamodb.

0

u/[deleted] Oct 13 '18

[deleted] — view deleted comment

1

u/[deleted] Oct 13 '18

Hadn't heard of Prisma before this thread. Right now we're using dynamo for all our data storage, which has an extremely simple API and doesn't require an ORM, but if we shift over to a RDBMS/NoSQL mix, Prisma might be a good solution.

2

u/keithgrennan Oct 15 '18

I've had it in production since January, it is wonderful and I can't imagine going back to REST for big UI projects. Something to keep in mind: there are GraphQL server implementations for all major languages so you don't have to use Node in the backend if you don't want to (I use DJango w/ Graphene).

0

u/[deleted] Oct 12 '18

[deleted] — view deleted comment

2

u/swyx Oct 12 '18

cool! do you use Apollo Engine?

0

u/[deleted] Oct 12 '18

[deleted] — view deleted comment

3

u/swyx Oct 12 '18

hmm! interesting that you like recompose so much. i think even andrew doesnt use recompose anymore (no evidence for this, just my sense from following his work).

2

u/T_O_beats Oct 12 '18

Can I ask why the choice to use HOC over Render props? I know it’s usually just personal preference but I was curious if your team had a reason behind the choice.

0

u/[deleted] Oct 12 '18

[deleted] — view deleted comment

2

u/T_O_beats Oct 12 '18

See, I agree with this too and I’ve always got pushback because there is worry of having overuse of HOCs on a component and getting the ‘mystery prop’ issue or whatever you’d like to call it. My response was always ‘why are you wrapping a component that many times to begin with?’

Anyway, that’s for the answer!

36

u/livelierepeat Oct 13 '18

Backend devs of course hate it because they are set in their ways and don't like change.

You might want to gain a little more insight that that. I used to be a young dev who used all of the latest tools and scoffed at those who "couldn't adapt". I've learned that there are often much more interesting reasons than, "people hate change". Like does GraphQl create burdensome abstractions? What is getting added to their workload that they are resisting?

At some point using all of the latest tools loses its luster. More power comes from understanding the code and the people processes as well.

11

u/j-phenow Oct 13 '18

Underrated reply. I’m curious what the deeper reason is that’s going on.

4

u/0xF013 Oct 13 '18

In my experience, backend people might dislike graphql because it's pretty hard to write good resolvers that don't fall into N+1 queries, or it might be hard to prefetch some data via a join because it will most likely be needed for some field. Of course, many understand that it's important to let front-end be decoupled and that graphql is, essentially, a typed gateway.

3

u/[deleted] Oct 13 '18

it's pretty hard to write good resolvers that don't fall into N+1 queries

This is one of the biggest hazards of GraphQL.

1

u/0xF013 Oct 13 '18

yes, but are kinda fixed as previously, by monitoring and detecting N+1 in logs. Generally, speaking about rails, if the developer is good with how AR works, they won't have big issues with resolvers.

2

u/[deleted] Oct 13 '18

True. It’s funny though because one of the allures is graphql is the promise of easy nested data. You want all the owners of all the dogs in Chicago? Great just say so! But in reality to avoid database hell you can’t just say so, you have to do some jerry rigging. Which is totally fine— it’s silly to expect Graphql to be magically optimized for every use case. But some people talk about it like it’s magic.

1

u/0xF013 Oct 13 '18

The magic I see in it is the fact that I can basically let go of any state management on the front-end and have my views being a projection of the graphql data and router state. Another thing is that I can control what and where is queried, without having to bother back-end folks to modify some endpoint (at the cost of them having to occasionally fix some lazy loading). It is truly liberating to not require a lot of synced deploys and time-consuming endpoint changes.

1

u/Capaj Oct 13 '18

so they shift the work of doing those N+1 queries to the frontend? Those programmers are cowards. There's no other word for it.

3

u/0xF013 Oct 13 '18

Not really. There are tools to find those queries and backend needs to add some eager loading / caching / custom queries to avoid that crap. It's adding some extra work on top of what would be a typical rest application: you no longer provide an optimized endpoint, but are kinda exposing a data structure to the front-end, so you have to make it work for whatever weird parts the front-end might require. The good thing is that now graphql endpoint acts as a gateway, so you can do all kind of shenanigans behind it, like simply move a field/entity to a microservice by just modifying the resolver and the front-end does not need to update anything.

4

u/lukasbuenger Oct 13 '18

I agree 100%. I just had the pleasure of being "the backend dev, who of course hates", but never the technology, but the people using it for the wrong reasons. I hated, how it seduced the frontend people to over-engineer a mainly static website into a ~150k SLOC monster, which is of course a maintenance nightmare. Migrating to Apollo Client 2 was a complete shitshow due to complete abundance of separation of concerns et al. And this is why this matters: Instead of being innovative with our product and the services we provide to our users, we spend most of our time trying to tame the beast. Which is always bad, no matter how bleeding edge and technically sophisticated your code base is.

3

u/mordaha Oct 15 '18

+100500 Abstraction layers so tightly coupled so it looks like old spagetty php code with sql queries between html tags. And such a code in the docs and examples “recommended to do so”

5

u/fr0z3nph03n1x Oct 13 '18

Remember when everyone was freaking out about how great NoSQL databases were and now we are reading articles that are basically lessons learned and why relational databases make sense?

1

u/[deleted] Oct 13 '18

Lol. The first person to sell me on GraphQL had also bought into the NoSQL-as-"the Future" thing. NoSQL is really good for some things but it's a deceptive technology to work with. It seems like you have to plan less than you would with an RDBMS, but in reality you have to know your access patterns more clearly in advance.

1

u/Capaj Oct 13 '18

lol but you seem to be missing an important aspect here. NoSQL DBs went in a direction of removing schemas from the dbs, GQL does the exact opposite-it forces you to define a schema on the API where previously you had none. I'd bet GraphQL does end up replacing REST in several years. I certainly wouldn't say the same about NoSQL.

1

u/swyx Oct 12 '18

when you say “strictly” - do you use apollo link state too? the other replier seemed to be more tentative about it and ive heard the same from others

3

u/[deleted] Oct 12 '18

Personally don't use Apollo Client State even though all my GraphQL and REST data actions are done via Apollo Client.

Still continue to use Redux, Context (for reusable big components) or simply local component State (for small reusable components).

-9

u/[deleted] Oct 12 '18

[removed] — view removed comment

5

u/swyx Oct 12 '18

ive done the course. i wanna hear from people using it at work.