The Road Ahead: Marketplaces & More

When I’m giving a demo of the Reaction platform, it’s as an evangelist giving a technical deep dive, as quickly as I can, into the architecture of Reaction. It’s also a useful and valuable time for us to sound out ideas, critiques, and table stakes requirements for some unique implementation models. 

During a demo, there’s the usual war story or two involving features that didn’t quite hit the mark, but a recent painful story involving a feature that Reaction doesn’t yet support really emphasized to me, again, how important it is to share our roadmap ideas. It’s that pain of complicated customization and operator workflow friction that is the genesis of Reaction. 

Sometimes, my answer to feature questions has to be a candid admission that some features don’t exist yet, are incomplete, or will need customization. Maybe it’s a technicality, but because I am imagining that the experience that you are looking for is somewhat unique to your vision, without flexible, easy customization, you’ll find any platform restrictive. Brands need to express themselves. 

That all leads me to my point: it’s the flexibility of a platform that is the main feature that should be evaluated, not just the feature set.

allows customization. check.

I believe that platform components should be flexible, focused around adaptable business process, and use the most modular pattern we can adopt. In general, this means I discuss our imports architecture during any tech-focused demo. The core modules provide a layer of separation and implement basic structures. For instance, taxes provide configuration, collections, schemas, and layouts for “taxSettings” and “taxMethods.” It provides some structure, but little more than that. 

The core modules all provide structure and methods that, when used with event, method, and collection hooks, can extend the included and custom modules in an isolated interface. Methods are exported and can be used as services, even remotely. Almost all Reaction methods are server methods and can be connected to from any endpoint with authentication. Modules in the included folder of our imports are well-tested working examples of community contributions that the core team and contributors work to maintain, or are packages we’ve developed as well-tested examples. We try to pick 2–3 providers out of every service type so that we ensure the nature of the core module is sufficiently flexible to deal with a variety of implementation requirements.

Of course, one of the core components of Reaction is the Meteor framework. Meteor has influenced many of our design decisions, to the point where now, when I am asked if Meteor knowledge is necessary to work with Reaction, I hesitate. It’s not about Meteor specifically, but more that I now think of our codebase as Reaction-specific. It’s more important to be familiar with Reaction than Meteor specifically, as our way of using Meteor is the Reaction way. How much Meteor is needed all depends on how deeply you need to learn Reaction.

We’ve seen a shift in the makeup of the Meteor community, but I think the direction set in each iteration of Meteor has produced fundamentally good architecture. We did not adopt Meteor because we thought it was the end-all framework, but because it was a good way for us to mature our own architecture while keeping up with the evolution of JavaScript in a relatively structured way. Meteor remains a part of Reaction, but I see us extending the best parts of the framework through Reaction itself, relying on npm as the general package manager and gradually reducing the Meteor package footprint, paralleling Meteor itself.

great scott! the road ahead has many forks

We’re moving progressively to an architecture that uses both npm and microservices, and thus, my message is this: build your Reaction customizations as an npm package (or in imports). While you can still use Meteor packages, I wouldn’t start any new development that way or publish to Atmosphere. We recently set all our Atmosphere packages to unmigrated status, which effectively hides all the published Reaction packages. At the end of the day, it’s all JavaScript, and we’re working on an overall product vision that is not Meteor-specific.

With an overall strategy of allowing rolling custom deployments, it's important that we always have a well-tested upgrade experience. We’ve really been working hard on ensuring smooth updates, and I believe the days of epic changes from Meteor will be few and far between going forward. Moving forward, I see a path for stable, continuous releases across a modular ecosystem. And, now that we've reached 1.0, we believe table stake items are now well-tested and functional. We believe we can support stable transitions from hereon out, and we are confident in our ability to move forward with future architectural updates.

marketplace, merchandising and content, oh my

Our roadmap after 1.0 will be focused on adding new content management and merchandising capabilities. With new collections for content, as well as a marketplace catalog, we’ll be bringing additional publishing and merchandising flexibility for marketplaces. This shouldn’t change much of the current core, as we’ve been planning for these features as long as we’ve been developing Reaction, but expect that we’ll be adding additional layouts and marketplace admin experiences. We're working on some predictive merchandising layouts using the publishing layer to deliver specific catalog content to the consumer. Naturally, we’re really excited to be nearing our real-time reporting and analytics goals.

imagine we have 2 customers, both popular grocery stores. we build for them an independent online store with their branding colors and so on, but they share some products (for example, Coke). the best way to manage this is one database for all of the tenants, and one back office to administer this. 


While we can have an independent solution like this, we don’t need to limit ourselves to a one database, one back office solution in order to build a highly scalable marketplace. We’re architecting the publishing layer as an independent service, deployed with Reaction, or multiple Reactions. We'll be writing more blog posts on marketplace in the very near future, so stay tuned. More soon.

reaction deploy. wonder twins powers activated.

We’ve put a lot of thought into the deployment process. In particular, we needed a tool that could handle the complicated portions and integrate all the moving parts of rolling update deployments into command line “reaction deploy.”

Our Managed Platform is our multi-tenant deployment orchestration application which deploys unique, independent shop clusters. The Reaction CLI connects to our platform to provide a reliable deployment process for custom Reaction implementations. The initial version supports pushing, building, and deploying custom code with rolling updates, SSL, custom domains, and backups. 

The vision for our platform leads to a future where we can deploy individual plugins as independent versioned services. We can also deploy containers for other applications as services. Long-term, we can see where some custom Reaction services are orchestrated with reaction deploy as versioned micro-service providers, providing a completely orchestrated, open marketplace ecosystem.

We’re working closely with several showcase Reaction implementations with launch dates over the next few months. There’s exciting work ahead, and I’m expecting that some really cool new features, like the publishing layer, will mature and stabilize quickly as more projects are being completed.

Get Involved

As an open source project, community participation—as well as our own evangelism and leadership—is critical to the architecture of Reaction. We continue to see strong contributors to our community, and we’re nearing a point where many features are now being architected and sponsored by the community.

If you'd like to join us on our Roadmap journey this year, or if you're interested in a tech demo, a meetup, or you just want to say hi, we'd love to hear from you. Reach out—and pass the word on.

comments powered by Disqus