When I first came to Meteor, I was immediately amazed by full-stack reactivity. After the novelty of being able to instantly see changes in my database on the client wore off, I started building applications.

Soon, I realized that Meteor had something special.

Meteor’s Special Sauce

A big component of Meteor’s “special sauce” is the Accounts system. The powerful functionality and ease of use provided by the Accounts packages is a perfect example of what makes Meteor amazing.

Does your application need to authenticate users? No problem, just add accounts-password, and include a pre-built template in your application:

{{> loginButtons}}

While the default user interface might not win any design awards, the utility of the Accounts package goes above and beyond anything I’ve ever used in any other platform or framework.

Two simple steps take you from zero to sixty in terms of authentication. Once you’re cruising, you can add a variety of other packages to customize the user experience or to incorporate things like authorization, presence tracking, user management, etc…

Being Opinionated

All of this is possible because Meteor takes an incredibly opinionated view of users and accounts. The Accounts package dictates with complete authority everything from how and where user documents will be stored, all the way through to the how the client will pass credentials up to the server.

All of this is decided and implemented in advance, and for the most part, set in stone. The Accounts package offers a few inroads for customization, but for the most part everything is fixed.

In nearly every scenario I’ve faced in the Real World™ this has been fine. I’ve rarely needed to go above and beyond the functionality provided by the Accounts package.

In the few instances where I did need more than the Accounts package provided, I simply forked the package and customized it to suite my needs.

Phoenix In Comparison

Compare the process of setting up authentication in a Meteor application to the process of setting up authentication in our Phoenix Todos application.

In the literate commits series where we’re converting the Meteor Todos application over the to an Elixir/Phoenix stack, it took four articles to fully set up our authentication system:

Phoenix Todos - The User Model
Phoenix Todos - Back-end Authentication
Phoenix Todos - Transition to Redux
Phoenix Todos - Finishing Authentication

During those four weeks, we manually set up every aspect of our authentication system from designing our user model, setting up our JWT signing procedure, writing back-end routes to handle authentication actions, through to wiring up the front-end to handle calling these routes and persisting the authenticated user client-side.

This is a huge amount of work!

That’s not to say that implementing these things yourself doesn’t come without its benefits. Complete control gives you complete freedom. However, exercising these freedoms can be exhausting.

Final Thoughts

It’s important to remember that this kind of up-front work isn’t exclusive to using Phoenix. This has been my experience with every framework and platform I’ve used to date until I found Meteor.

Some frameworks try to ease some of the burden off of the developer, but none have managed to make my life as pleasant as Meteor.

Once I found Meteor, I immediately became accustomed to authentication being handled for me. Going back to manually implementing things that I want to “just work” feels like going back in time.

I’ve noticed that others feel the same way. When this developer talked about his experiences migrating away from Meteor he noted how he particularly missed Meteor’s robust accounts system.

Based on recent rumblings in the community, Meteor has fallen on hard times. In times like these, it’s important to remember everything the framework does well and balance those with its weaknesses.