Another Meteor Love Story

Hi all - I like reading inspirational Meteor posts as much as the next Meteor dev, so I thought I’d chime in with an inspirational post of my own (I’ve been meaning to post about this for a while, but better late than never). Just a heads up - this isn’t an ad - actually, I’m leaving the company/product details out intentionally, to put the focus on Meteor itself.

The Problem

A while back I was contacted by a past client who needed help fixing issues with their Wordpress/WooCommerce based store. They’re a sports nutrition company that offers customizable subscriptions for sports nutrition products to their customers, on an on-going basis. They were using a great WooCommerce Subscriptions plugin to help manage their subscriptions, making sure proper subscription renewal orders were created and billed as needed.

Unfortunately, the subscription plugin they were using wasn’t really designed to handle fully custom subscription orders. That is, having a customer browse around their store, picking and choosing the different products they want (with quantities, flavors, etc.), then when happy with their shopping cart, turn that cart into an on-going subscription. Customers would then need to be able to come back to their account at a later date and easily modify their on-going subscription. They had wired up an approach for handling this with a bunch of custom PHP/Woo plugin code, but it was really janky. Subscription changes weren’t being picked up, wrong amounts were being charged, adding/removing products from subscriptions was a nightmare, etc. Not only were customers complaining about the process, but they were canceling their subscriptions and not coming back.

After a quick process review, we came to the conclusion that trying to force the subscription plugin to do something it wasn’t really intended do, just wasn’t the way to move forward. After looking into other available third party subscription plugins/systems, we realized we needed something custom. We also realized that a lot of the subscription functionality we were looking for could almost sit by itself, without having to integrate that closely into WooCommerce. Being the Meteor fan that I am, I said I’d give them a new subscription system, with a proper dynamic box management interface for customers, and a proper admin interface for managing and maintaining subscriptions. I was a bit tight on time, so I said I’d give them a rough POC within a week using Meteor.

The Solution

Well, long story longer, it worked. We built a new standalone subscription system that ties into WooCommerce (and ultimately any ecom store), allowing customers to easily turn any cart into a subscription, then come back and modify that subscription in realtime. Here’s a quick overview of the technical flow:

  • Customers shop via WooCommerce as they would normally, but have the option in their cart to turn that cart into a subscription, and select a renewal frequency (e.g. every 2 weeks, monthly, etc.).

  • When checking out via WooCommerce, and payment is finalized, all subscription details are fired into the Meteor based subscription system via simple:rest.
  • The subscription system has an admin built using mfactory:admin-lte, that shows all customers, subscriptions and subscription products. Admins can fully manage subscriptions (modify, pause, cancel, etc.).

  • The subscription system routinely pulls in an updated full product list from the WooCommerce API, with the help of percolate:synced-cron, so admins can see and control all subscription products (e.g. instantly remove a product from all subscriptions if it’s discontinued).
  • The subscription system also leverages synced-cron to routinely check to see if any subscriptions need to be renewed; if so that subscription’s details are packaged up and fired back into WooCommerce via a custom REST endpoint, that then creates the renewal order in WooCommerce, and proceeds with billing.
  • On the customer side, after purchasing a subscription, customers can manage their subscriptions via their account area. Customers get access to a dynamic subscription builder, that applies their subscription changes instantly within the subscription system. For now this box builder is an iframe wrapped page pulled in from the Meteor based subscription system itself (ugh iframes, I know - it was a 1 week deadline remember), but will eventually be refactored to be a little more robust (standalone non-meteor based client calling home via DDP).

  • Current subscription customers can browse the store catalog and click on an “add to subscription” button for any product, which fires the subscription changes back into the subscription system via REST, having it instantly added to their subscription (and ultimately instantly showing up in their account area thanks to the magic of Meteor).

The Conclusion

Ready for the real Meteor awesomeness? Within a week the POC was done, but the amazing thing was it was really done - as in not a POC, hosted in prod, and turned on. Customers started using it right away and the rest is history.

I just can’t stress enough how amazing this experience was. Working with Meteor is really, really, really a wonderful thing. MDG talks about how important developer happiness is and they’ve really nailed it, but I can’t stress enough how that developer happiness directly and positively affects customer/product happiness. Seriously - a HUGE thanks to all at MDG, and everyone in this community - you guys are awesome!

Sigh - inspirational post done == procrastination done, so back to work I guess … kidding, I’m working with Meteor and having a blast! :smile:


Using Meteor for the time reminded my heavily of the first Rails experience. Everything works great, intuitive, out of the way, zero ceremony.

I’m curious are you using Blaze or React? I’m building a pretty ambitious app with React as the view layer, and while it’s technically ‘better’, I can’t help but feel it’s a hamstring. Like I would probably be more productive if I used Blaze but I would not be able to test things better.

I’m really interested in how testing will work with 1.3, if it’s good enough, I may just switch to Blaze. I value productivity with my tools the most. If testing Blaze is good enough, why not.

Blaze - I’ve worked with React on a few newer Meteor projects since then and really get the appeal, but I still miss working with Blaze. I’m not sure if that’s because of muscle memory, the Blaze package ecosystem, or something else. I’m really torn on which to use as well though. I’m planning on sticking with React moving forward, but I’m constantly asking myself if the real reason for that choice is more because so many other people are, than an actual preference. I agree - I can’t wait to see the full 1.3 testing story!

1 Like