This is a guest post by Max Savin, the creator of Meteor Toys, a popular suite of development tools for Meteor.

A lot of people have asked me what Meteor Toys are, and how they came to be. As they pave the way for a new type of development tools, I thought it’d be a good time to tell the story. And what better place to do it than on the website where I first learned Meteor?

Meteor Toys are a set of development packages made specially for Meteor, created as a solution to my own needs and development frustrations.

Meteor Toys.

On the first level is the open source Mongol and JetSetter. When toggled, these packages let you view and edit your MongoDB documents and Session variables visually instead of having to run it through console. As of writing, both are quickly rising through Meteor’s top 100 packages.

On the second level are the premium Meteor Toys, which extend Mongol and JetSetter, provide an additional set of convenient tools, and are the first paid package for Meteor.

But let’s start from the beginning.

Just Toying Around

In December 2014, my third start-up had crashed and thoughts about getting a job were running through my mind. Around that time, I had become proficient in Meteor, and decided to interview at what may have been the only Meteor-based company in New York. During the interview, the team encouraged me to build and maintain a package, and it seemed like a fun challenge.

In search of an idea, I recalled a widget I created while building my first Meteor app. It was a box that displayed a reactive count of how many documents were in each collection, and let you browse through them.

The Meteor NYC meetup.

Seeing the convenience it could bring to any Meteor developer, I extracted it into a package called MongoInspector and began to promote it at the Meteor NYC meet-up. Each month, I gave a lightning talk to spread the word and gather feedback, and each time, I was delighted by the community.

During my first presentation, I explained how I hacked up a way to keep MongoInspector out of production. Right after, Abigail Watson and Adrian Lanning introduced me to the undocument debugOnly property for packages. The property was implemented into Meteor at the request of the Meteor team, which they were a part of, and in effect opened up an interesting door.

debugOnly Packages

The debugOnly property tells Meteor’s build process to exempt a package from your production code. To see how its implemented, take a look at this package.js file.

Expanding the Scope

After the launch, MongoInspector began to rack up downloads, and it was exciting to think that there were hundreds of people using it throughout their day! And now, with debugOnly at my disposal, I realized developer’s could safely open up all kinds of convenient “security holes” to gain super powers in development mode without losing sleep over security issues in production.

The first thing I did was equip MongoInspector with a special set of method’s that allow it to perform any action on the database. This turned it from an inspector to an editor, and lead to the rebrand from MongoInspector to Mongol. The response to the new version was phenomenal!

Choosing the Method approach proved itself to be very practical because it respects your application security and doesn’t require the insecure package to work. It worked a lot like a database admin tool, except it was right in your app and focused on the documents in use.

MongoInspector and SessionInspector, before they grew up and got their super powers.

Parallel to this, I launched SessionInspector, which evolved into JetSetter, which is the same concept as Mongol but for Session variables. JetSetter carries a similar narrative - whatever happened on the MongoDB side, happened slightly later on the Session variable side.

Hacking the Development Environment

Mongol and JetSetter’s rise through the top 100 packages, and the convenience of the debugOnly package property, lead me to consider what else could be brought into the Meteor development environment. With the boring stuff abstracted away came the challenge of inventing something new, and it lead to a bunch of package ideas, such as:

  • Impersonate: when working on an app, you often have to sign in and out of different accounts to make sure your application works properly. Rather than require you to sign in and out of different accounts, Impersonate lists your accounts and lets you sign in by clicking on them.
  • Method: when you need to call a method manually, you often have to go into your source code to see how the parameters are lined up. The Method toy displays them to you automatically, and lets you type in their values as you go.
  • AutoPub: Autopublish is very useful in development, but at some point it has to be removed from the application. AutoPub brings the joy back by letting you publish all your documents to the client with a click.
  • Shell: Run any code on the server as if it ran from a Method. Once you run it, it’ll give you back the results in the console, along with the Method code which you can paste into your application.

As the ideas hit, I realized the need for an extendable interface, which lead to the creation of what I call the Orb component. Each one carried its own functionality, designed to save you a minute here and there.

Mongol, JetSetter, and the Orbs.

The Meteor Toys Name

Mongol benefited from two awesome contributors in the quest of perfection; Krawalii and JackAdams. They helped with automatic collection detection, refining the method’s, and BrentAbrahams even glued in his Editable-JSON package to make document editing easier.

When we were actively working on it, one of Krawallii’s pull requests broke Mongol, and JackAdams called him out for it. Krawalii quickly made a new fork called “krawaliibreakstoys” to prepare a fix, and the name had me laughing. Around that time, I’d been thinking of branding the set of tools under one name, and Meteor Toys occurred to me like a good one.

From Side Project to Side Business

After I completed the Meteor Toys bundle, the question of whether they should be monetized sprung up, and if so, how. Since they are tools, like an IDE or color editor, I figured they should carry a price. I showed them to my comrades in the Meteor community, and almost everyone gave the same price suggestion, which confirmed my hunch.

The challenge was in deciding where to draw the line between what is open source and what should cost money. The art is in making both the free side and the paid side compelling. You want people to be content with the free version, so that its worth engaging with, while providing enough incentive for people to upgrade.

I decided to divide them between what people already had capabilities for and what hadn’t been done before. The standard console commands for manipulating Sessions and Collections were automated by Mongol and JetSetter, and that would constitute the free tier.

By taking the paid route, I felt justified with the time investment I had made to developing Meteor Toys. I knew I’d be able to ensure proper support and updates for the people who use them. Plus, I write much better code after having ingested a Chipotle burrito.

Embracing Paid Packages

After the launch, some people spoke through their wallets and others through forum comments. Not everyone welcomed paid packages, and I feel it should be given more understanding.

Having money go through the ecosystem is a win for everyone: the Meteor Development Group makes money off deployments, contributors make money off building/supporting their packages, and developers make money off their applications, while receiving a well-supported solution.

I’ve heard worries about paid packages cannibalizing open source packages, but looking at other platforms (such as WordPress, Photoshop, etc) shows us the opposite. By enabling a commercial tier for packages, I’d bet we would see greater commitments from more developers. That would translate to more packages and options for everyone else.

Wrapping It Up

The Meteor Toys journey has been extremely rewarding, and I look forward to where it will go next. I feel it enhanced Meteor’s development environment and hopefully made developers happier, while helping me pay for the quad-shot cappuccinos. It also reflects one of my favorite things about technology: we have a lot of opportunities to create things that benefit every party involved.

By bringing parts of the “IDE” into the application itself, we can manipulate things in their context, and with debugOnly at our hands, we can create convenient openings in the framework without worrying about security. This is what Meteor Toys are built upon, and with your support, I’ll continue to devote my time to ensuring they continue to improve and adapt to the framework.

Thanks to Max for taking the time to share his story! He’s also been kind enough to set up a special discount for Discover Meteor readers. Just use this URL and you’ll get 15% off Meteor Toys!