Since Facebook announced GraphQL in 2012, it has made a serious difference to the way we manage the application data. GraphQL is the data querying language which fetches and syncs the data for web and mobile apps. It describes to a server which type of data needs to be delivered through queries. So you don't need to create endpoints from the server side. Instead, you can deliver data with a single request. And this is the place where Apollo Stack comes out. It can explain all Meteor front-end needs to the server through GraphQL queries and make the process reactive.
As a reminder, Apollo is an incrementally-adoptable MeteorJS data stack that manages the data flow between the clients and backends. It exists as a reactive part of the application front-end layer. At the same time, you can integrate Apollo into existing Meteor backend architecture.
At Meteor Night event Rohit Bakshi, the Product Manager at MDG, was excited to tell us about the Apollo Stack usage experience. The speech was about the integration process with their service for running, monitoring and managing Meteor applications, called Galaxy. Here is our short review of his presentation.
Main Reasons to Use Apollo Stack
- Apollo allows to connect and manage different databases from a MeteorJS app (SQL, MongoDB, REST, etc.) in a more seamless and efficient manner.
- Doing joins with client-server side is hard. But Apollo can give you a single GraphQL query across multiple sources which makes one round-trip between the client and the server. As a result, you can pull from different data sources and get a combined outcome.
- Apollo lets you choose which data refreshing process needs to be reactive and which needs not.
Apollo Stack Integration Process Steps
- Define a GraphQL schema. There is a schema in the core of any GraphQL server. Basically, it defines types, their relationships and specifies which queries you can make against the server. Apollo compiles the GraphQL schema language notation to a GraphQL-JS one. So the real value here is a much simpler way of expressing and doing complex queries.
Here is a code example:
Integrate Apollo Server with MeteorJS backend. Basically, it's not the only way to make data stack work here. You can also use separate servers for these tasks. But in case with Galaxy, Apollo was built into the Meteor backend Node.js process. As Apollo Stack is a production ready GraphQL based server, integration practice looks pretty simple.
Visual examples of integration:
Define resolvers. A resolver is a function that determines the value of a field in a query. The task is to define how queries are going to be parsed and call different backend sources. Solution is to define a resolver, whose function is to figure out how to get the value of a field in any query that has been sent to the GraphQL server.
An example of a resolver in a code snippet:
- Integrate with the View Layer. In Galaxy's case, you have two different types of UI components or classes. The first one is the Presentation Component, the second is the Container.
Presentation Component features:
- Defines layout and visual appearance.
- Doesn't store app or user state in the component, doesn't bind to a Global data object.
- Gets state passed into the component.
Container Component features:
- Is responsible for defining how the interface works.
- Contains state.
- Defines data and behavior for presentation components.
Presentation Component is where you put all your visual code. It's strictly about how you render things on the UI. It actually gets state passed from the parent (Container) Component and defines how layout looks.
Сontainer Component here is like a view controller which knows how to pull data from different sources and pass it to the UI for rendering purpose. If the code is structured in this manner, you can only work with the Container. Parent Component will pull out only those specific Presentational Components you need and put them in Apollo.
Take a look at the code example:
Benefits That Apollo Stack Brings into Modern Apps Development
- Apollo Stack simplifies the way you manage your data, because it's much easier to write queries that span different data sources.
- From performance perspective, it's nice to have the optional reactivity. There are some things that benefit from being reactive and some that don't need that constant CPU usage in the front end.
- Implementation approach is incremental. You don't have to re-architect and throw away your client code and fronting. It can be easily adopted and specified to bring Apollo Stack in.
To sum up, there is an exciting future ahead for Apollo that will bring more value to MeteorJS apps.
Watch full Rohit Bakshi's presentation at Meteor YouTube channel:
Also, check out Apollo Stack: Goals, Challenges, First Components to learn more.