My story: finding an alternative stack to meteor (in particular user accounts)

Planet Earth
1

Hello everybody, I haven’t posted in this community for a while.

I used meteor for a year before I started attempting to replace the framework with a pure node application based on individual libraries (mainly because I wanted to build on a less coupled system). Main challenges were:

  • view layer: moved from blaze to react
  • data layer: moved from ddp to apollo
  • ssr: had no ssr with meteor, am now using next.js
  • user accounts: ???

User accounts are one of the neatest features of meteor, and there is no equivalent in the node.js ecosystem. The only thing that approaches it is passport.js, in the sense that it’s modular and extensible. Passport.js, though, only handles authentication, and leaves the management of users as homework for the user. That’s why I decided to build my own set of libraries that build on top of passport.js strategies. It’s called OOTH: GitHub - nickredmark/ooth: User identity/authentication/accounts management microservice for node.js. Ooth now supports registration/login with username/email/password, with facebook and google, and handles things such as detecting whether the user already logged in with another strategy.

I’m also building a set of accounts UI components and other boilerplate components packed together in an other library, that can be easily copied or taken as an example if you want to build your own accounts UI: GitHub - nickredmark/staart: A starter library for node projects with user accounts.

It all comes together in a boilerplate that is as lightweight as possible, see a live example here: http://staart.nmr.io/

I won’t bother the community further with my outside projects. Just wanted to close this chapter and share my story, since it took me a long time to replace the incredibly innovative stack that is meteor. In the end I left for philosophical reasons, not because I was unhappy with what you produced. On the contrary, you spoiled me so much with your treats that it took me a year to find a half-satisfactory alternative.

8 Likes
2

I don’t mean to be nosey, but may I ask what were the philosophical reasons to replace Meteor?

3 Likes
3

since 1.3 - 1.4, it seems like there is less and less reason to leave meteor. The only real reason is if you need insanely fine grained control over your build process (webpack).

5 Likes
4

With version 1.5.1+, I have decided to stay with Meteor while ignoring everything GraphQL(until realtime subscriptions and authentication becomes as easy as Meteor provisions). Honestly, nothing compares to Meteor, at least for now. I haven’t seen any convincing reason to leave Meteor. I feel like I can build anything with Meteor with the right optimization with no problem. Meteor now scales with redis-oplog…node updated to 8 and with the latest release of MongoDB, those who left will surely return.

13 Likes
5

meteor + apollo is pretty nice. I agree it’d be nice if subscriptions were more straight forward.

3 Likes
6

I’ve been back and forth out and in of Meteor for years. But as I get the tech running correctly, I love it more and more.

It’s interesting to see some one stick another platform together, good luck with your stuff!

But the shortcuts Meteor does provide is invaluable. For me specifically, real time communication + easily building apps.

My other projects that are stuck on PHP + Wordpress… oh man what a nightmare to build apps over there.

5 Likes
7

As to the philosophical reasons, here’s my original motivation article, it was written in November 2016: https://medium.com/the-ideal-system/note-to-self-never-get-stuck-with-a-framework-again-7699bbd887b5

It boils down to decoupling technologies. Ah, and not having to use two package managers. If meteor had managed to transition their packages to npm I would probably still use most of the stack today. But it doesn’t look like it’s ever going to happen: https://github.com/meteor/blaze/issues/13. With apollo they went in the right direction and created npm packages from the start, and I’m happy to still be using technology from that very talented team.

8

Thanks for the article :+1:

Not saying you’re wrong, just my 2 cents:

Using small decoupled building blocks is nice. Favoring micro libraries when possible over big frameworks does make sense. But… in my opinion there isn’t really much difference, if you’re using Meteor or Apollo with Next or Nuxt or _____ or plain JavaScript with whatever stack of tech (though this wasn’t exactly the case few years ago).

You chose React with Next.js? I don’t see how switching from React to Vue or any other view layer is going to be easy for you. How would you accomplish this with Next.js in a way that’s easier than with Meteor? Also, you’re still using Node, which might have to be replaced any time soon, maybe with Go? What about JavaScript on the client: WebAssembly is already in the next hipster stack… things are always evolving and other stuff is going to become obsolete. The stuff that people on the web actually use are still mostly powered by PHP…

What is Meteor

I can see how Meteor’s “magic” can be troubling, when someone wants to fully understand the ins and outs of their project. Still, at the end of the day, to me Meteor is just a build tool and a bunch of packages that work well together. It makes a developer’s life a bit easier. (Also, gives you reactivity and other goodies out-of-the-box).

Not having to implement reactivity and accounts is like a zero-interest loan from the bank that you don’t have to pay back, unless you want to. If I switch from Meteor to something else and I cannot use it’s accounts system anymore, I have to pay back the loan and actually write that stuff myself. I never lost anything by using Meteor’s offerings.

Disclaimer: I did write my own templates, validations and some custom logic for sign up, login, password reset and other pages but that stuff is easily re-used elsewhere

When you think of it, a typical web app is a bunch of server side logic that communicates with client side components, formed by HTML, JavaScript and CSS.

With my styles written using nathantreid:css-modules, I could reuse them in any project. There is no Meteor specific magic in those definitions, since CSS Modules is “just an idea”. Same goes for plain CSS of course.

My templates are written in Blaze sugared with ViewModel, which could very easily be converted to React using ViewModel for React. Some people are converting their components to use Vue, since they can easily co-exist with Blaze templates. Even rewriting Blaze components with Vue seems very doable.

Routing is so simple that any library will do and there is many to choose from.

I’m using Astronomy to define my models and replacing that would be harder, because I think it’s using Meteor in such a nice way to make validating and updating documents a breeze. I’d have to write a custom abstraction layer and it wouldn’t be as flexbile. There is Sequelize that I know of, but it isn’t nearly as nice. Astronomy is on it’s way to NPM though, from what I read somewhere…

If I wanted to get rid of Meteor, the hardest part would be to replace reactivity and the Accounts-system, but then again, I never spent any time on those with Meteor.

This made me think why I chose Meteor few years back… :thinking:

At the end of the day I choose the tools that fit best for the job in my naïve and subjective opinion. The two most important things for me is

1) I get stuff done that needs to be done
2) I’m happy getting stuff done.

:point_right: I chose Meteor, because I didn’t want to invest the time to make all the choices, work my javascript-fatiqued-ass off and glue my stack of billion NPM packages together.

:point_right: I chose Meteor because I wanted to concentrate on my actual problem as much as possible. I had zero interest in developing the perfect accounts-package or re-invent reactivity

:point_right: I chose Meteor because I definitely needed reactivity and I got it for free. Also, reactivity is hard!

:point_right: I chose anything that made my life easier, getting features done faster or made me write less boilerplate or jump through hoops. On the road this included packages like ViewModel, Astronomy and CSS-Modules, which all made a big difference. Two of those were, at the time, Meteor-only.

What’s the point of this

The hardest part of this field for me has always been the core ideas of how I’m going to solve the problem and how to make it nice and intuitive for the end user. It doesn’t really matter what framework or boilerplate generator I’m running under the hood when I’m actually building something. That’s just the crap you have to take care of before you can get stuff done.

I’ve seen a lot of polarized “I’m with Meteor” / “I’m breaking up with Meteor” posts here. I don’t have such strong feelings. I try to choose my tools wisely, then work with them and avoid changing them unless the benefits are real.

When my current project evolves to the next logical step and I need to build a separate complimentary web app, I already had a plan for the tech stack and it didn’t include Meteor. Today, I’m not so sure anymore. Meteor is turning out to be pretty awesome and very capable outside of it’s previous applications.

25 Likes
9

@arggh You nailed it! :blush:

10

Great post arggh and nmaro.

I think the root problem here is the blow up of javascript frameworks, plugins and updates. It seems everyday there are updates and new tech coming out. How can you keep up with all this if your stack is very tightly coupled. This is why i encourage friends of mine who ask me, decouple decouple decouple. Why decouple? Take for instance you use angular as your front end framework with meteor. If angular decides to go a new route (AoT, treeshaking), MDG will have to implement these changes and thus you are waiting for something you can’t control. I have waited for these changes for a couple of months which never came and decided one day, I am decoupling my front end completely with angular and back-end still meteor. What did i accomplish? I get periodically updates with angular, i am able to perform AoT, treeshaking and lowered my site load time from 4 seconds, to 0.5s. BTW i still use meteor user account because its very easy to use. Hopefully you can get an understanding why decoupling certain technologies have benefits

11

It’s been a few years since I’ve touched Meteor so it was nice reading this post. Where are we when it comes to supporting SQL databases, preferably using Meteor’s yummy reactivity? Thanks.

12

Apollo works great with Meteor, lets you access SQL, and supports reactivity. :slight_smile:

13

Fair enough. I’d challenge the “zero-cost investment” there. Migrating away from meteor has taken me months (I actually never stopped using meteor with my original application, eliveness.com, simply now I have a new set-up I use for new projects, like sorters.club) - compare to create-react-app which just takes one command (eject). I guess it’s a question of gradation. But you are right that with my current setup I’m pretty much stuck with react (or some relative) because of next.js, so there is some coupling there. As to javascript/node going away or being replaced by something new, well, can’t argue with that. I often wonder what web engineering will look like in 10 years? Probably you’ll say “Ok, Google, make me a website”. Exciting times :slight_smile:

1 Like
14

Tried to log into eliveness for curiosity, but it shows an nginx error.

15

Whoa there, thanks man!

1 Like
16

I recognise a fiverr hand-drawing video on your front page :slight_smile:

17

What if you don’t want to be dependent on Meteor? Have you tried typescript with meteor? Compared to the majority of node packages you need to start a package the meteor community is a bit sluggish. A lot of projects haven’t had a commit in at least 6-moths, usually at least a year since a major update.
I’ve been doing react development for apps that are really used by millions of people. Java backend. Teams of 5-20 simultaneously contributing.

Have you read all the articles about moving from less/scss to postcss? that was a couple years ago… the React community has been tehre for a while and we’re all happy with WebPack2.

Why? Well a great thing about webpack over IsoBuild is module aliasing. A real simple thing I would think but meteor makes difficult. How do you do it? maybe a babel plugin? But I’m using typescript…

Another thing webpack can do that Isobuild can’t is run PostCSS.

Finally, I really like the idea of using the npm package rm-local-module for npm package development but meteor’s solution is to put it in the node_modules folder. This isn’t like developing in a real node application. this is more Meteor framework.

So, there’s my checklist for Meteor.
Solid typescript support, PostCSS support, or opting out of Isobuild for webpack. I’m not “in the framework” anymore though am I?

Should people see Meteor as an end-all-be-all? It’s like saying learning rails or django and never learning ruby or python. But node is inherently more relevant to us than either of those languages.

Meteor is an awesome launching point for any developer coming to NodeJS, but React and Npm have matured since a couple years ago. So, use Meteor to figure out all the awesome things you can do with Node, and then… I guess… join in on the struggle at finding a reactive stack. I recently posted about TRAM, there’s been many efforts like this and I reed them all.

Or if you’re a newb reading this: maybe you can hurdle us - as we put off learning graphql - and go straight to Vulcan JS (by the discover meteor guy)

1 Like
18

I’m using nathantreid:css-modules which allows me to run PostCSS. Shouldn’t be too hard to fork a build plugin that does whatever PostCSS stuff you want done?

19

back online, thanks for pointing it out (hadn’t checked it in a while, I kind of moved on from that project, even though we do have some users)

20

Kind of. My business partner used a standard software, it’s quite cool :slight_smile: