Lesson 1 of writing code that doesn't die with 200 users: don't use mongo.

Glad you got meteor fixed up by sad you stuck with Mongo. H

I don't think my app died with 200 users purely owing to the technologies I used. Those may have not been the best tools for the job, but with some precautions, I could have made them work fine.

If I see performance issues with Mongo, I will switch. But I don't want to switch just because I can.

I think that is a good idea when looking at new technology in general. However in this case

1) switching databases is a lot of hassle especially without an ORM. Why choose wrong from the start?

2) Mongo not scaling well and being a poor choice is documented across thousands of articles all over the net. At some point it may be worth accepting "hey maybe the entire world isn't stupid and this tech really does suck."

I could see your point if somehow Mongo provided massive time savings, but I am very doubtful.

Thanks for the tips. I think (1) is a good reason to switch but I am not familiar with the topic of (2) yet. I will do some more research & talk to people.

I recently built an app called RemoteBase using MeteorJS, a full stack JavaScript framework. I had some scalability issues, and rewrote the app.

Here is why and how I rewrote the app with Express + React + Redux without MeteorJS. Hope this post mortem helps JavaScript developers and future me.

Nice to hear about your experience with meteor

Take a look at Loopback, it is built on top of express, allows for rapid development and in my experience scales really good. For example it has load balancing out of the box.

It is definitely my tool when building nodejs Rest APIs

and HN is the new best Load Testing tool.

You echo the issues I've encountered with Meteor and the reasons why we got rid of it. MongoDB is the worst when having to do, well, anything with it. We've moved to FeathersJS with a SQL Backend and could not be happier.

Great, and I just spent a full month learning Meteor.