How I Migrated My App from Meteor

Hi everyone,

In the wake of server issue I experienced recently, I had an opportunity to rewrite my Meteor application using Express + React + Redux. I would like to share the experience with the community. I wrote and article focusing particularly on why and how I rewrote the app.

Here is the article:


For what it’s worth: Apollo is going to bring all the advantages you mention in the article to Meteor, and it lets you keep most of the things that are great about Meteor. Might be worth giving it a try!


What is the status of reactivity with Apollo by the way? Afaik that part is opt in, but when will we be able to get it? My team is planning to move over to GraphQL in the next few weeks. We’re looking for the right time to build a Polymer implementation of GraphQL.

1 Like

Apollo Will have auth built in?

I completely understood the reason for your shift and it’s completely legit.
Hope Mantra helped you to do the switch and minimize the UI re-write.


Personally, I believe we will start seeing more of this. Meteor is great to launch quickly, and if built right (@sungwoncho mentioned a few mistakes he fixed) it can (probably) scale well.

But as the advantages of using a fullstack are getting eroded (express.js and its many frameworks are really solid now + Angular still around = very easy to build AJAX apps, many UI frameworks including React and Handlebars), and as NPM packages start to replace Meteor-only, the only reasons left to use Meteor are (1) reactivity, (2) speed of deployment, (3) mobile

Big companies don’t care about #2 (speed) as they can throw resources in – smaller companies liked Blaze for that purpose but that’s being dropped. Reactivity (#1) is being replaced by unidirectional binding in many frameworks (React, Ember) even though it’s really cool (probably relates to #2). Mobile (#3) is now super easy with Cordova / React Native.

Nothing left.

I also don’t see how Apollo is going to save the day. If you are using MySQL (or any other DB type), you will find a way to push data down from your DB (GraphQL isn’t that cool if you have a single data source). Startups anecdotally like MongoDB which is already supported.

Not sure what the path forward holds. Then comes monetization, can you really make money on hosting?

PS: As I checkin to this forum every once in a while, I notice that there aren’t as many posts as before. Am I the only one noticing this? Or maybe I should say, there aren’t as many INTERESTING posts as before.


Nah, I’ll just stay with Meteor! Thanks for sharing though!


@fcaldas I should mention I am not leaving Meteor; I will use it for my other projects.

There is no ‘leaving’ or ‘staying’ when it comes to technologies because they are just tools. We simply use them as we see fit.


I’m curious though, given your problems with remotebase, would you build something similar with meteor again, now trying to not make those mistakes or would you rather only use meteor for very specific apps?

For your pubs still being reactive, could you not have just changed it to a to get the data instead? A Meteor method is pretty similar to a REST API isn’t it? As in, you only get data when you ask for it. I just wanted to understand your reasoning more. Thanks for the insightful write up!

1 Like

Agreed, I’m also curious. We’ve written our MVP with Meteor but we are considering to use something else for the backend/database. I am also afraid we might run into performance issues, especially because we don’t have a really good backend person on our team so I’m sure our backend will have flaws :smiley: .

All the issues that you had with Meteor could have easily been solved in a day.

For example, if you know Meteor you know you need Oplog tailing, Mup(x) has tons and tons of issues (ever heard of Galaxy??), and Meteor needs CPU power, not ram and it can’t make use of multiple cores without squeezing yourself in (impossible) angles. It’s also very easy to query mongo without reactive overhead.

Don’t take it personal, but it sounds like you made beginners mistakes that you blame on the framework, and then you decided to ditch the framework (and even blame Meteor’s performance for not setting up database indexes!!) and do a rewrite. Instead you should have spend a day on learning Meteor and optimising your app.

So I don’t think the ‘why’ argument in your post is very valid. But it’s positive to see that you are at least aware of your own mistakes.

Meteor scales fine. But scaling is always an art. And it definitely helps if you understand the framework better.


Those are very significant reasons. Indeed the reason why A16Z sunk millions into Meteor was because they were impressed with how quickly Geoff used it to create the travel app he was pitching (A16Z didn’t want to fund the travel app, but they were interested in the framework, which became Meteor).

I think you discount the importance of these things too much. The idea that you can just “throw resources” at projects to make them go faster was debunked in the 1970s.


Wow, sounds cool!
I can’t wait to see it working…

1 Like


Thanks for your comment. I am not discounting these reasons, they are the same reasons we jumped on board. However, they are not as differentiating anymore as when Meteor started.

For instance, Sails does a superb job too and we don’t have to worry about Meteor-specific issues (like UI issues, profitability of MDG, shift of focus to Apollo etc.). Sails is an open source platform supported by a services company, so the flow of investment is less risky then trying to build a hosting business sponsored by VCs.

Another advantage of using Sails (just an example) is that they already solved the DB problem that Apollo is trying to solve AND they use mature packages (express, – so if they go bust, you are dependent on mature packages that are deep in the NodeJS ecosystem.

Also, I agree that you can’t throw resources to make a project go (a lot) faster. If you are using the React ecosystem, it’s partly because you need to work in teams (i.e. resources). With Meteor (using Blaze as was originally designed) you need a much smaller team. This was touted as an advantage, but is not so when you have budget dollars.

I feel like the ability to move quickly was eroded around 1.3…

Blaze + meteor 1.2 imo is the greatest mix ever… now it feels like meteor is so much like the vanilla JS ecosystem that I may as well just use the vanilla ecosystem… reactivity isn’t needed most of the time (there can only be so many live chat apps, and if you need live chat, you may as leverage a slack API).

I tried to start a react+meteor app, and found it was easier to just use vanilla react+alt+webpack. You don’t have to make bets on using an atmosphere package vs npm package, and you don’t have to spend time trying to figure out the meteor way to use react, or how to integrate react router or how to do redux/flux the meteor way.

Webpack really wasn’t as hard to grasp as I thought it would be (from all the negative press on it)… and once you know it, you essentially just take other people’s boilerplates (or use your own) and the “2 hours of setup” is actually 10 minutes.

The only thing I miss is the account system and being able to do stuff like Meteor.userId() etc.

If Apollo can do (a) reactivity (b) accounts and © connect to any database in a way that is simple to understand like meteor1.2/accounts/mongo/simpleschema/mini-mongo was-- then I would use apollo + webpack + react ALL DAY.

My other gripe is that unless you’re self employed and can use any tech you want, then you really need to learn vanilla node/js/react to get employment. There are just so few meteor jobs around that competition is beyond stiff.


I think you said it well, once Blaze was out of the picture, the real value of Meteor as a cool and quick platform to develop in got eroded. We don’t need Meteor for React, seems more like a bolt on. React and Angular are pretty complete ecosystems in themselves.

Have you checked out Sails? It has (I believe) what you are looking for when it comes to data (played with it a bit and looked at the intros). In fact, the intros are focused on real-time data.

1 Like

I’m reminded of what happened with Visual Basic years ago. It was a really easy way for a lot of people to get started in programming. But once VB became VB.NET and fully an OOP language, it became a lot more sophisticated and professional but also a lot harder for amateurs and hobbyists.

It may seem like a loss, but it’s also a gain. Meteor is evolving for compelling reasons. There will always be easy alternatives for amateurs. Not every movie needs to be suitable for children.

We don’t need Meteor for React, seems more like a bolt on. React and Angular are pretty complete ecosystems in themselves.

Angular developers were attracted to Meteor because of it’s data flow (Pub/Sub, Tracker, ReactiveDict, etc.) Ask anyone doing Meteor dev with Angular why they don’t just use Angular without Meteor.

As someone who has produced several Meteor apps with Blaze, we’ve moved to Meteor + React and are finding we can move more productively with better code quality than ever before.


You’re talking about Meteor not being able to monetize. AHAHAHAHAHA!!!

Here’s what Meteor gets, that you don’t:


  • Build environments suck. Solution: use the Meteor build tool.
  • Data loading sucks. Solution: use Apollo.
  • Reactive frontend is fragmented (which developers hate) but, paradoxically, developers want options. Solution: Meteor supports React, Angular, Blaze, etc. use Meteor.
  • NPM sucked. Solution: use Atmosphere.

And all of these are, again, just marketing stunts for their real cash cows:

Cash Cows

  • Deploying and scaling an app sucks, even on AWS. Solution: deploy to Galaxy.
  • Nobody can consult and teach Meteor better than those who created it. Solution: consult with Meteor.

And I’m not even talking about their community efforts, MeetUps, forums, StackOverflow, and Github presence as marketing efforts.

They’re absolutely fucking genius.

So is monetization possible? You bet your ass it is.

Just a heads up: MongoDB is on the same business model; I’m pretty sure it works.