The Road Ahead: Product Updates, October 2018
Hello, Reaction community! As you know, we’re committed to keeping you up to date on what’s happening with Reaction, including our product priorities and roadmap. We have a lot to cover this time, so let’s get right to it.
Reaction Action recap
First, thanks to all of you who signed up, and showed up, for our latest Reaction Action livestream last Wednesday morning. We fielded a lot of great questions, which I’ll address below. If you missed the live broadcast, head over to our YouTube channel and watch the recording.
As we continue the work on v2.0.0, I wanted to share an update on our product development priorities for the next four to six months. We’re working on a lot of other things as well, but these are the core features that are currently in our development queue.
- A flexible promotions engine that allows promotions to be easily applied to specific products or categories
- Shipping rules for configuring specific products to be included (and excluded) in specific shipping categories
- A routing engine for redirects that enables operators migrating to Reaction, and migrating product catalogs within Reaction, to set up detailed routes for redirecting from certain pages to other pages
- Flexible tag management that allows more customization for enabling and disabling certain tags, adding products to tags, and more
As this work progresses, and our roadmap evolves, we’ll be sure to keep you updated through future blog posts, Twitter, and other social channels.
Our product principles
As we make these roadmap decisions, there are some higher-level principles that help keep us moving in a good direction. We are all committed to:
- Expanding support and coverage for our GraphQL API
- Continued focus on performance, including monitoring, toolsets, and benchmarking
- Enhancing the Reaction experience to meet the needs of “mid-erprise” (yes, we made up that word) retailers
Which brings me to addressing some topics that have come up in our community channels, namely: marketplace support, reactivity, storefront UI, and performance.
Marketplaces and multi-shop
Before we get any further, some definitions:
We define a “marketplace” (or multi-vendor commerce marketplace) as a shop where products, either physical or digital, are provided by multiple merchants or vendors on a single marketplace site.
“Multi-shop” refers to merchants—often those managing multiple brands or regions—creating more than one user-facing storefront connected to a single backend. It offers an easier way to manage catalogs, products, orders, customer data, reports, and content for multiple websites, from a single master admin panel.
We are committed to marketplace and multi-shop experiences on Reaction. Starting in v1.5.0, Reaction introduced capabilities for managing multiple merchants or vendors in a single marketplace, with split order fulfillment and payment processing. That implementation of the marketplace model, though it met the requirements at the time, does have some limitations:
- No differentiation between marketplaces and multi-shops
- Relationships between various entities such as Products, Carts, Orders, and Tags are complex and inflexible
- Permissions issues: In a multi-shop scenario, all sellers are trusted actors, whereas a marketplace involves untrusted third party merchants
- Performance and efficiency problems: Duplicating data across multiple shops slows the app significantly
- Inflexible shop routing
All these limitations make it tough to architect for a multi-shop scenario while maintaining compatibility with the way our existing marketplace works. So our focus in our v2.x branches for the near term will be on improved support for multi-shop orchestration tools, for merchants who have multiple properties or sales channels. That means we will not be recreating our current implementation of marketplaces in v2.x, though we do plan to bring back an improved marketplace architecture at some point.
Reactivity and Reaction
When we first started building Reaction five years ago, real-time reactivity was the default and was included just about everywhere in the app. As time went on, this approach created some challenges, namely with performance.
We also came to realize that frontend reactivity wasn’t necessary or even useful everywhere in the app, so we’ve been moving away from “reactivity by default” to “reactivity where it adds value.” Reactivity is still very much a core part of our vision, and we plan to keep reactivity in the frontend where it makes the most sense—for example, in merchandising, promotions, and analytics.
Backend reactivity is a different story—our commitment to reactivity on the server side is stronger than ever. That’s where we’ll focus our efforts to build reactive architectures that make use of streaming data, allowing Reaction operators to respond in real time to the events that drive and impact their business, without compromising performance.
“Classic” Meteor storefront vs. GraphQL-powered storefront
As we covered in our v2.0.0 announcement, the Reaction platform now includes a GraphQL API layer that connects to our existing Meteor-based backend. So you can now build a storefront UI with technologies other than Meteor—such as our own Next.js Storefront Starter Kit, which is also free to use and modify. Going forward, this will be the recommended way to build a storefront UI on Reaction. In fact, our engineering teams will not be making any further updates to the “classic” Meteor storefront UI.
So what does that mean for Reaction v1.17? To make a long story short, we are fully dedicated to building on the the modular architecture and improved performance of v2.0, which unfortunately means we won’t be able to support Reaction v1.x beyond the end of this year. Beginning in January 2019, we will no longer accept community pull requests for v1.x branches, though we will continue to resolve major security issues in v1.17 only, for the following six months (until June 2019).
Our commitment to improving performance continues, and we know there’s still work to do. Better application performance, for both developers and end users, is not a line item on our roadmap. It’s the goal that’s woven through all of the updates and improvements we’ve addressed above.
And we’re making progress. Some early tests from our new GraphQL-based headless storefront show dramatic improvement in load times over the “classic” Meteor-based application, which means a dramatically better shopper experience.
That said, we know we still have work to do. We’re working on new benchmark tooling and testing protocols, which we will share with you in an upcoming post.
It got away from me again
I keep meaning to make these updates shorter and simpler. Maybe next time, when I’ll be back for my annual year-end wrap-up. Until then, we’d love to hear your feedback in the comments below, on Twitter, or in our public Gitter chat.
Thanks for reading, and thanks for being part of the Reaction community. See you next time!