1.3K
1K
+ 1
10

What is Apollo?

Build a universal GraphQL API on top of your existing REST APIs, so you can ship new application features fast without waiting on backend changes.
Apollo is a tool in the Platform as a Service category of a tech stack.
Apollo is an open source tool with 9.6K GitHub stars and 1.4K GitHub forks. Here’s a link to Apollo's open source repository on GitHub

Who uses Apollo?

Companies
276 companies reportedly use Apollo in their tech stacks, including Stack, The New York Times, and Graphy.

Developers
938 developers on StackShare have stated that they use Apollo.

Apollo Integrations

GraphQL, Gatsby, Prisma, Google Code Prettify, and Prisma Cloud are some of the popular tools that integrate with Apollo. Here's a list of all 10 tools that integrate with Apollo.
Private Decisions at about Apollo

Here are some stack decisions, common use cases and reviews by members of with Apollo in their tech stack.

Seun Kola
Seun Kola
CTO at Virtualrobe Limited · | 7 upvotes · 15.3K views
Shared insights
on
GraphQLGraphQLReactReactPrismaPrismaApolloApollo

Using GraphQL for queries and mutation on React app and Prisma database is so cool, easy and fast to learn. i often use Apollo client to integrate both ends. Most times working has a frontend developer and trying to build a MVP product quickly requires tools that require less setup on both production and development in order to test functionalities, and using GraphQL for queries surpasses Rest queries for me because of the flexibility in requesting the data you actually need and not requesting the whole dataset everytime.

But in all, Rest is still the king since most public api support its CRUD processes more than GraphQL but lot of top companies are using it and am definitely using it for various project including my recent pet project(Delivery buddy - A platform that allows pair-to-pair delivery service).

See more
Obsaa Abdalhalim
Obsaa Abdalhalim
CEO, Founder at Kafali PAY inc. · | 1 upvotes · 64.2K views

React Native NativeBase redux-saga Apollo GraphQL Node.js PostGraphile PostgreSQL PubNub . @PLAID Dwolla.js . Zube GitHub Yarn npm AWS Elastic Beanstalk

See more
Zach Holman
Zach Holman
Founder at Signed · | 44 upvotes · 494.9K views

Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.

But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.

But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.

Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.

See more
Zach Holman
Zach Holman
Founder at Signed · | 7 upvotes · 9.6K views
Shared insights
on
ApolloApolloGraphQLGraphQLRelayRelay

Apollo is my favorite open source project.

Two things you need to worry about when making a statement like that: is the tool good, and how is the tool being built?

From a tool perspective... yeah, Apollo is great. I'm convinced that GraphQL is the way forward for me, and Apollo's just a great way to tackle it. Even beyond that, it just offers a good mentality to how you should build your database-backed app. I've used Relay in the past, back before they made a bunch of changes with Relay Modern (which all seem positive!), but switching to Apollo is just night-and-day. They've been doing better in the last 12 months or so at making smart abstractions in the React Apollo library, to the point where I'd just get these monster all-red pull requests where I can delete all my cruddy code and replace it with far fewer lines of their great abstractions.

But from a build perspective... Apollo fares even better, I think. By this, I mean their project inertia, their progress, their ability to ship stable code — but still ship meaningful new functionality, too. They're not afraid to move their ideas in other directions (integrating with React Native, for example). Kills me to see projects that are just heads-down on their little world as the world passes them by, and so far... yeah, Apollo's been on top of it.

Anyway, big fan. It's really changed how I write frontend code, and I feel hella confident while working with it.

See more
Divine Bawa
Divine Bawa
at PayHub Ghana Limited · | 14 upvotes · 225.8K views

I just finished a web app meant for a business that offers training programs for certain professional courses. I chose this stack to test out my skills in graphql and react. I used Node.js , GraphQL , MySQL for the #Backend utilizing Prisma as a database interface for MySQL to provide CRUD APIs and graphql-yoga as a server. For the #frontend I chose React, styled-components for styling, Next.js for routing and SSR and Apollo for data management. I really liked the outcome and I will definitely use this stack in future projects.

See more

React @typed-graphqlify GraphQL Apollo TypeScript Laravel Docker

See more
Public Decisions about Apollo

Here are some stack decisions, common use cases and reviews by companies and developers who chose Apollo in their tech stack.

Zach Holman
Zach Holman
Founder at Signed · | 44 upvotes · 494.9K views

Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.

But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.

But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.

Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.

See more
Nick Rockwell
Nick Rockwell
CTO at NY Times · | 37 upvotes · 1M views

When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

See more
Adam Neary
Adam Neary
Engineer at Airbnb · | 30 upvotes · 801.4K views

At Airbnb we use GraphQL Unions for a "Backend-Driven UI." We have built a system where a very dynamic page is constructed based on a query that will return an array of some set of possible “sections.” These sections are responsive and define the UI completely.

The central file that manages this would be a generated file. Since the list of possible sections is quite large (~50 sections today for Search), it also presumes we have a sane mechanism for lazy-loading components with server rendering, which is a topic for another post. Suffice it to say, we do not need to package all possible sections in a massive bundle to account for everything up front.

Each section component defines its own query fragment, colocated with the section’s component code. This is the general idea of Backend-Driven UI at Airbnb. It’s used in a number of places, including Search, Trip Planner, Host tools, and various landing pages. We use this as our starting point, and then in the demo show how to (1) make and update to an existing section, and (2) add a new section.

While building your product, you want to be able to explore your schema, discovering field names and testing out potential queries on live development data. We achieve that today with GraphQL Playground, the work of our friends at #Prisma. The tools come standard with Apollo Server.

#BackendDrivenUI

See more
Russel Werner
Russel Werner
Lead Engineer at StackShare · | 28 upvotes · 1M views

StackShare Feed is built entirely with React, Glamorous, and Apollo. One of our objectives with the public launch of the Feed was to enable a Server-side rendered (SSR) experience for our organic search traffic. When you visit the StackShare Feed, and you aren't logged in, you are delivered the Trending feed experience. We use an in-house Node.js rendering microservice to generate this HTML. This microservice needs to run and serve requests independent of our Rails web app. Up until recently, we had a mono-repo with our Rails and React code living happily together and all served from the same web process. In order to deploy our SSR app into a Heroku environment, we needed to split out our front-end application into a separate repo in GitHub. The driving factor in this decision was mostly due to limitations imposed by Heroku specifically with how processes can't communicate with each other. A new SSR app was created in Heroku and linked directly to the frontend repo so it stays in-sync with changes.

Related to this, we need a way to "deploy" our frontend changes to various server environments without building & releasing the entire Ruby application. We built a hybrid Amazon S3 Amazon CloudFront solution to host our Webpack bundles. A new CircleCI script builds the bundles and uploads them to S3. The final step in our rollout is to update some keys in Redis so our Rails app knows which bundles to serve. The result of these efforts were significant. Our frontend team now moves independently of our backend team, our build & release process takes only a few minutes, we are now using an edge CDN to serve JS assets, and we have pre-rendered React pages!

#StackDecisionsLaunch #SSR #Microservices #FrontEndRepoSplit

See more
Robert Zuber
Robert Zuber

We are in the process of adopting Next.js as our React framework and using Storybook to help build our React components in isolation. This new part of our frontend is written in TypeScript, and we use Emotion for CSS/styling. For delivering data, we use GraphQL and Apollo. Jest, Percy, and Cypress are used for testing.

See more
Russel Werner
Russel Werner
Lead Engineer at StackShare · | 17 upvotes · 318.2K views

Earlier this year we decided to go "all-in" on GraphQL to provide our front-end API. We needed a stable client library to power our React app. We decided to use Apollo Client for a few reasons:

1) Stability 2) Maturity 3) Heaps of features 4) Great documentation (with use cases) 5) Support for server-side rendering 6) Allowed us to stop using Redux and Mobx

Overall we've had great success with this library, along with a few minor hiccups and work arounds, but no show stoppers. If you are coming from Redux.js land, it takes a bit of time to settle into a new way of thinking about how your data is fetched and flows through your React app. This part has been the biggest learning curve of anything to do with GraphQL.

One of the downsides to Apollo Client, once you build a larger application, (past the size of most of the documented use cases and sample apps) the state management tends to get distributed through various places; and not just components. Apollo Client has a state management feature that relies on a normalised local cache. Mastering the knowledge of how this works is key to getting the most out of the library and to architecting your component hierarchy properly.

#FrontEndFrameworks

See more

Apollo Alternatives & Comparisons

What are some alternatives to Apollo?
Helios
Helios is a Docker orchestration platform for deploying and managing containers across an entire fleet of servers. Helios provides a HTTP API as well as a command-line client to interact with servers running your containers.
GraphQL
GraphQL is a data query language and runtime designed and used at Facebook to request and deliver data to mobile and web apps since 2012.
Python
Python is a general purpose programming language created by Guido Van Rossum. Python is most praised for its elegant syntax and readable code, if you are just beginning your programming career python suits you best.
Relay
Never again communicate with your data store using an imperative API. Simply declare your data requirements using GraphQL and let Relay figure out how and when to fetch your data.
Heroku
Heroku is a cloud application platform – a new way of building and deploying web apps. Heroku lets app developers spend 100% of their time on their application code, not managing servers, deployment, ongoing operations, or scaling.
See all alternatives

Apollo's Followers
1048 developers follow Apollo to keep up with related blogs and decisions.
Maddy Mandar
jiyeon ahn
Killian Mary
dsdunn
Bryce Hall
David RATIER
Pietro Bertarini
Austin Gilbert
enzzoperez
Vladimir  Shakurov