StackShareStackShare
Follow on
StackShare

Discover and share technology stacks from companies around the world.

Product

  • Stacks
  • Tools
  • Companies
  • Feed

Company

  • About
  • Blog
  • Contact

Legal

  • Privacy Policy
  • Terms of Service

© 2025 StackShare. All rights reserved.

API StatusChangelog
Apollo
ByApolloApollo

Apollo

#12in Platform as a Service
Discussions28
Followers1.78k
OverviewDiscussions28

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 Pros & Cons

Pros of Apollo

  • ✓From the creators of Meteor
  • ✓Great documentation
  • ✓Open source
  • ✓Real time if use subscription

Cons of Apollo

  • ✗File upload is not supported
  • ✗Increase in complexity of implementing (subscription)

Apollo Alternatives & Comparisons

What are some alternatives to Apollo?

Heroku

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.

Google App Engine

Google App Engine

Google has a reputation for highly reliable, high performance infrastructure. With App Engine you can take advantage of the 10 years of knowledge Google has in running massively scalable, performance driven systems. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow.

AWS Elastic Beanstalk

AWS Elastic Beanstalk

Once you upload your application, Elastic Beanstalk automatically handles the deployment details of capacity provisioning, load balancing, auto-scaling, and application health monitoring.

Apache Camel

Apache Camel

An open source Java framework that focuses on making integration easier and more accessible to developers.

Red Hat OpenShift

Red Hat OpenShift

OpenShift is Red Hat's Cloud Computing Platform as a Service (PaaS) offering. OpenShift is an application platform in the cloud where application developers and teams can build, test, deploy, and run their applications.

Azure Websites

Azure Websites

Azure Websites is a fully managed Platform-as-a-Service (PaaS) that enables you to build, deploy and scale enterprise-grade web Apps in seconds. Focus on your application code, and let Azure take care of the infrastructure to scale and securely run it for you.

Apollo Integrations

Canner, Tipe, GraphQL, graphql-yoga, Prisma Cloud and 7 more are some of the popular tools that integrate with Apollo. Here's a list of all 12 tools that integrate with Apollo.

Canner
Canner
Tipe
Tipe
GraphQL
GraphQL
graphql-yoga
graphql-yoga
Prisma Cloud
Prisma Cloud
FullStack Boilerplate
FullStack Boilerplate
Google Code Prettify
Google Code Prettify
PostGraphile
PostGraphile
Gatsby
Gatsby
React Location
React Location
Prisma
Prisma
GraphQL Armor
GraphQL Armor

Apollo Discussions

Discover why developers choose Apollo. Read real-world technical decisions and stack choices from the StackShare community.

Russel Werner
Russel Werner

Lead Engineer at StackShare

Dec 3, 2018

Needs adviceonReactReactGlamorousGlamorousApolloApollo

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

0 views0
Comments
Lee Benson
Lee Benson

Nov 30, 2018

Needs adviceonReactReactGraphQLGraphQLApolloApollo

ReactQL is a React + GraphQL front-end starter kit. #JSX is a natural way to think about building UI, and it renders to pure #HTML in the browser and on the server, making it trivial to build server-rendered Single Page Apps. GraphQL via Apollo was chosen for the data layer; #GraphQL makes it simple to request just the data your app needs, and #Apollo takes care of communicating with your API (written in any language; doesn't have to be JavaScript!), caching, and rendering to #React.

ReactQL is written in TypeScript to provide full types/Intellisense, and pick up hard-to-diagnose goofs that might later show up at runtime. React makes heavy use of Webpack 4 to handle transforming your code to an optimised client-side bundle, and in throws back just enough code needed for the initial render, while seamlessly handling import statements asynchronously as needed, making the payload your user downloads ultimately much smaller than trying to do it by hand.

React Helmet was chosen to handle <head> content, because it works universally, making it easy to throw back the correct <title> and other tags on the initial render, as well as inject new tags for subsequent client-side views.

styled-components, Sass, Less and PostCSS were added to give developers a choice of whether to build styles purely in React / JavaScript, or whether to defer to a #@{css}|topic:477| #preprocessor. This is especially useful for interop with UI frameworks like Bootstrap, Semantic UI, Foundation, etc - ReactQL lets you mix and match #css and renders to both a static .css file during bundling as well as generates per-page <style> tags when using #StyledComponents.

React Router handles routing, because it works both on the server and in the client. ReactQL customises it further by capturing non-200 responses on the server, redirecting or throwing back custom 404 pages as needed.

Koa is the web server that handles all incoming HTTP requests, because it's fast (TTFB < 5ms, even after fully rendering React), and its natively #async, making it easy to async/await inside routes and middleware.

0 views0
Comments
Nick Rockwell
Nick Rockwell

SVP, Engineering at The New York Times

Sep 24, 2018

Needs adviceonMySQLMySQLPHPPHPReactReact

When I joined NYT there was already broad dissatisfaction with the LAMP (AngularJS 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.

0 views0
Comments
Russel Werner
Russel Werner

Lead Engineer at StackShare

Sep 13, 2018

Needs adviceonReact StorybookReact StorybookReactReactRailsRails

Our front-end team decided to use React Storybook for our primary React development environment. It allows us to write components in isolation without the need to fire up our Rails stack. When writing components in isolation; you can focus on styling, behaviour and prop design. It forces you to think about how your component is going to be used by others. React Storybook uses webpack and hot module reloading under the hood. This allows us to write components very quickly since it hot reloads in the browser as you code!

The knobs add-on is great for testing different edge cases for the component props. There is even an add-on that will auto-render and snapshot your components with every prop permutation allows by your defined knobs. These snapshots can then be part of your CI testing.

We have a step in our build process that publishes a static React Storybook site on our production server. This allows our entire team to interactively test components before they are integrated into larger features. Once we are happy with our components in isolation, we integrate them into connected feature components which are wired up to Apollo and GraphQL to provide the data and state.

There are heaps of React Storybook add-ons to checkout. If you aren't using it, you should be.

0 views0
Comments
Russel Werner
Russel Werner

Lead Engineer at StackShare

Sep 13, 2018

Needs adviceonGraphQLGraphQLReactReactApolloApollo

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 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

0 views0
Comments

Try It

Visit Website

Adoption

On StackShare

Companies
528
CMASMI+522
Developers
1.73k
MLRRHC+1728