Hello! Sara here. In case you didn’t know, I’m co-founder & CEO at Reaction Commerce. As a part of a renewed commitment to communicating our plans and progress more regularly, I’m here to share some updates on our product roadmap. I recognize that I can do a better job of keeping folks aware of our product initiatives, so this is a new effort where I’ll be communicating updates on a regular basis going forward.
Before I get into the product stuff, let me first share with you a few company updates:
- We’re now a team of 22 across 14 different locations: 6 states, 4 countries, and 3 continents
- So far this year, we’ve rolled out 11 product releases—with many more to come
- We’re closing in on v2.0.0!
- Our GitHub repo recently reached 7,200 stars ⭐
- Over 5,300 users across 117 countries run Reaction’s open source codebase
In short, 2018 has been a big year for us. I want to take this time to thank you for your continued support and enthusiasm. We’re grateful and humbled by the ongoing commitment of our community. If you’d like to learn more about contributing to Reaction, visit our docs. And if you’re interested in joining our team, please check out our careers page for details on open positions.
Without further ado, let’s jump into the product update!
Our product strategy for 2018
Reaction’s performance is a big concern for our users, and frankly, we haven’t done enough to make meaningful progress in this area. It’s long overdue. Our goal is clear: to make Reaction faster for developers, operators, and shoppers. Here’s how we’re going to do it.
You can’t manage what you can’t measure, so the first step is to establish testing benchmarks across a number of different variables. Using a simulation tool, we’re measuring how Reaction performs against enterprise-level datasets. In our last run, we tested a catalog of over 200,000 SKUs, 1 million product images, and an order volume of 2 million. The app loaded within 5 seconds—the goal is to get that down to 3—while on the dev side, we saw 50-90% faster initial startup and server rebuild times. We’ll have more numbers to share in future blog posts.
The next step is to simplify Reaction, which we’ll get to in a bit. This will reduce the overall footprint of the app, making it faster to install and customize.
And finally, we’re making some big changes to architecture. Right now, we’re in the beginning stages of separating the storefront and operator experiences by introducing a GraphQL layer into the app. To make things clear: yes, we will eventually be moving off Meteor.
Less is more—that’s what our general product and design philosophy has always been. Now, we’re simplifying Reaction even further, all the while continuing to deliver quality experiences and results for developers and operators. The move toward simplification stems from the complications of managing and maintaining a large application, and from the performance challenges that exist within the app.
Here’s an example: today, Reaction comes with four different payment packages. We plan on narrowing that down to one. Our belief is that one size does not fit all in commerce, so choice and extendibility are fundamental tenets of Reaction. Focusing on one core payment solution will allow us to maintain this flexibility by providing a map for all other community packages. It’ll also allow our small team to better maintain solutions to our level of standard, as well as focus on new features.
Beyond payments, we’ll continue to follow this approach across other features. More details below.
Our product priorities
Performance & simplification
It’s about quality over quantity. As a part of our initiative to simplify Reaction, we’re focusing on providing one reference application per feature and moving all others over to community-sponsored packages. We’ll be migrating packages, APIs, and schemas over to npm. It’s a standard approach to package management, one that improves the developer experience overall.
Here’s how it will look:
||Stripe, example payment package
||PayPal, Authorize.net, Braintree
||Avalara, TaxCloud, TaxJar
Storefront & Operator experiences
You may have heard of the term headless commerce. It’s something Reaction has always supported, but now it’s infinitely more accessible. Essentially, it means separating the storefront and operator experiences, giving our users more choices in how they develop and design their front-end. We define storefront as the front-end shopper experience, which includes home and category pages, product detail pages, cart, checkout, and profiles. Operator refers to the administrative or dashboard experience, which includes catalog and inventory management, order processing, shop setup (payments, taxes, shipping, etc.), promotions and merchandising tools, and other services essential to running and managing shops and marketplaces.
Right now, we’re building a prototype storefront using Next.js and Material UI, and in the future, we intend on building starter kits for other popular frameworks and libraries as well (e.g. Gatsby). Our current prototype communicates to Reaction via the introduction of a new GraphQL API layer, which means developers can now write their front-end in Angular, Vue, or any framework they want. It also means Meteor will no longer be required. This, in turn, will greatly improve performance for both developers and shoppers alike.
Here are some screenshots of the new storefront prototype:
What does this mean for new & existing shops?
Over the course of our history, we’ve taken an iterative and inquisitive approach to our architecture. We keep evolving, just as the tools around us mature and advance. A short 4.5 years ago, software like React, Gatsby, Next.js, and GraphQL were nowhere near where they are today. It’s important to have a flexible DNA, one that continues to expand. Otherwise, our platform, along with those who adopt us, will become obsolete. That’s why we suggest that new shops take advantage of what’s currently in development: our GraphQL-powered storefront.
The GraphQL API talks to existing Meteor endpoints in the Reaction Commerce core codebase, and the existing Reaction storefront theme (built in React) will still be operable, but as we separate out the storefront from the operator experiences, we’ll be abstracting Meteor as we go. Our focus is to give more options to our clients and community, so that they may build their apps using whatever framework they choose, which may or may not include Meteor. We haven’t decided exactly when or how we will transition other parts of the app away from Meteor, but here’s what we suggest: if you are planning on launching your site within the next 60-90 days, then Meteor is the way to go. If your timeline is farther out, then the GraphQL approach will probably work best.
For existing shops, any breaking changes will always come with documentation and upgrade paths, when possible. Again, if you’re considering adopting Reaction for a new project, we recommend using the GraphQL-powered storefront that’s currently in development over the Meteor storefront.
Part of Reaction’s value proposition is the flexibility to be able to adapt to and employ innovative and proven technologies. As always, we’ll consult our community and clients as we go down this path. If you have any questions related to functionality or development, start with our community channels. Thanks to our active, thriving user base, Reaction’s developer chat is one of our strongest direct resources. If you think that your company would be a great partner for Reaction, feel free to drop us a note at firstname.lastname@example.org to learn more about our professional services.
Expect to see some of these changes in the next release. In v1.13.0, we’re removing our complex product diffing revision system in favor of a simpler, more powerful catalog system for publishing products. We’re also removing dependencies from certain Meteor packages, though we will still be upgrading to Meteor 1.7. Please note that there will be breaking changes in this release, which will be outlined in our release notes.
It’s a few months out, but by the time v2.0.0 release rolls out, our GraphQL Storefront API will be ready for primetime. For developers and operators, this means greater flexibility, more choices, server-side rendering (SSR) for search optimization, and total freedom in how you build your storefronts. To follow along with our progress, check out our open PRs via GitHub.
That was a long update!
Lots to catch up on! Going forward, I’ll keep these brief. As I mentioned, I’m committed to providing progress updates to our clients and community on a more frequent cadence. In next month’s installment, I’ll offer more insight into Reaction’s business model and commercial offers—how we make money, essentially. I’ll also share an update on everything I touched upon in this blog post.
I’d love to hear your feedback. Comment below, or message me with any of your questions, thoughts, or suggestions. Want to hear more updates? Join the next Reaction Action livestream and Q&A on 7/17/18 at 8am PT. RSVP link to follow.
Until next time!