15 September 2016
Meteor decided to decouple a lot of its old tech stack and become as transparent as possible. It is clear that the software community is doing its best to publish reactive data quickly, as users expect more from the modern web and mobile apps. To meet these demands, Meteor came up with Apollo, which predicts customer needs, even get in-memory client caching by using a Reactive Apollo GraphQL layer and make it open source.
What are the most common problems in data stack?
The most common feature request for the Meteor framework is better support for different data sources, referring to SQL databases, REST endpoints or Redis and RethinkDB.
The business environment determined the community to create a generation data layer in Meteor which involves a unified layer, that can be used by client applications to communicate with the server endpoints.
Is Reactive GraphQL or Apollo solving the problems?
This is a huge topic, and for those who don’t know, Apollo’s vision is to include both client and server-side components in the UI interface. The core of Apollo is Reactive GraphQL, which comes with a full advantage package as mentioned below:
From a business standpoint, there is an exciting future ahead of Apollo that will bring value to Meteor apps. The companies that adopt it now will have a competitive advantage over the coming years and will be well-positioned to benefit from the advances in this rapidly evolving ecosystem.
Photo source: apollostack.com