Recently I’ve been working with other frameworks and platforms, and I was reminded why I was initially drawn to Meteor and why I’ve stayed with it for so long.
I agree, Accounts is one thing that makes Meteor development really great. You just don’t need to re-invent the wheel. It’s especially important because user authentication and password storage is something that developers notoriously get wrong, which results in unsecure password hashes (or, God forbid, storing passwords in plaintext), security holes in the authentication and forgot password steps and other problems. Instead you can just add the accounts package and call it a day, while being confident and feeling secure.
For me another thing is Tracker - really simple but powerful concept, which tied with Minimongo and Pub-Sub can do wonders especially when prototyping an app.
I know people complain that it’s slow, but every time I see a mention of Grunt, Gulp, SystemJS, or even Webpack, in some blog post bemoaning Javascript fatigue, I smile a little more.
With Meteor, I’ve never had to think for a second about transpilation, minification, uglification, concatenation, config files, or anything, except what cool feature to code up next. I hope I never have to.
I somewhat agree, though I wish there was a server-side onEmailVerified handler. There is only a client-side one, which I use to do a Meteor.call to run the server-side tasks, but it’s not ideal.
Will there be an official Accounts package for integration with Apollo?
I would like to know how to take what we have with Meteor and integrate it with other systems.
Is there an easy way to get the Meteor accounts system working with Phoenix?
I haven’t read the 4 articles yet, but Pete rolls his own authentication system, right? And it won’t easily connect to an existing MongoDB Meteor with accounts?
The one thing I dislike about accounts-base is MDG’s choice to force case-insensitivity onto the developer. Generalizing a check for case insensitivity makes creating users really slow. It’s also a feature that people need either selectively or not at all. As a fix, I developed this package, which basically just skips all of that stuff, so that the limiting factor in user creation is the bcrypt hashing on the password. Using Accounts.createUserFast also means you have to take care of case yourself, though. It’s not that hard, if you’re only using one email per user (or don’t care about case in emails).
meteor add streemo:create-user-fast
I’m not sure why people can’t just store a “cAsESensiTive” username in a separate field, and store a normalized version in the actual username field which the accounts package uses. This makes it way faster. Unfortunately, this “feature” was forced onto us. I suggest not using functions like Accounts.findUserByEmail, and writing those manually, combined with a storage of normalized values so the index takes care of dupes. The login flow and token management is pretty great, though.
I used an Elixir library called Guardian to help with authentication, but I still had to do a good amount of work to get everything wired up.
I’m planning on write an article or two about how you could integrate with the Meteor auth system with Elixir/Phoenix. It’s good to hear people would be interested in that kind of thing!
Yes, very interested. This has always been the biggest thing holding me
back from moving parts of my app to other platforms. Accounts system is
always the issue. Same for React Native but now that’s a solved problem.
And that only has to deal with the client side.
It would’ve been good if there was a built-in “change email address” function (with verification), just as there is a built-in “change password” function.
I wonder if MDG is investing time in a new accounts system once Apollo is integrated fluently. The possibility of building new apps with the accounts packages having oauth login, reset password, enrollment and verification out-of-the-box is outstanding and one of the core reasons why I use Meteor.
But there is a major issue with the “npm package way”. Developing isomorphic npm packages comes together with all the grunt, webpack, 100x config files / 1 source file things. And as an npm package developer you should be unopinionated about the technologies used for client-server communication. That’s why “accounts” can’t be provided as a package asily. On the other hand, big atmosphere packages which were making our lifes easier for years are now dead, discontinued, obsolete… Why?
