Reactivity in Reactions future


Hello all, For the past year my Reaction shops have been humming along on v1.1.1 and I’ve been planning new development pushes for an existing shop and the relaunch of a type foundry shop with Reaction.

I got the roadmap blog post ( in my inbox and I am excited about the direction that was laid out, in terms of performance, separation of storefront and operational features, GraphQL and utilizing tools of choice (eg Gatsby).

I’ve got one question, with the abstraction away from Meteor as a dependency, where does that leave us with reactivity in terms of the core? I have at least 1 use-case where the reactivity of Meteor is a central feature.

Curious to hear more!



Hi Owen,

Thanks for the question.

As you noticed was mentioned in the blog post, performance is one of the reasons that we’re moving away from Meteor. Having all of the data in the application reactive by default is great for demos and development but can become an unnecessary bottleneck for production shops at scale. As part of our migration from Meteor publications and subscriptions to GraphQL we’ll be also migrating from “reactive by default” to reactive when necessary or beneficial.

The good news is that GraphQL supports reactive data subscriptions. See the Facebook RFC GraphQL Subscriptions for a technical deep dive. There’s also this easier to digest blost on GraphQL subscriptions. We’re building our GraphQL API to be relay compatible and we’re leveraging Apollo GraphQL to do it. The other good news is that there are several tutorials and a small module to implement GraphQL subscriptions in node for Apollo.

It’s too early for me to comment on exactly what data Reaction will continue to keep Reactive by default, but we’ll be making these decisions attempting to optimize for performance and user/customer experience.


Thanks for the reply Spencer. I’ll be reading up on these and paying close attention to updates from the Reaction team regarding headless Reaction!