Now I’m using morphine just reading these stacks and combinations.
I took a look at Google’s firebase about a year ago. Back then I would have already started using it but then there was one thing still missing – a NoSQL database. Now, with its Firestore database (and several other product additions since then) I’m going to try it with one new project…
1 Like
If I had to stop using Meteor for some reason I would go for Hoodie and learn about offline-first approach: http://hood.ie/
I think Meteor has already made some steps in offline first, though it would be nice to see more support for it.
1 Like
Thanks for pointing me to Hoodie. Looks quite interesting. And I agree, better offline support would be cool in Meteor, especially for mobile apps (Cordova) and Electron. I can’t count the number of questions on this forum asking about how to upload and store simple stuff like images server-side.
3 Likes
How do you know its Meteor which is the bottleneck ? What exactly in profiling shows up ?
After a lot of research, trial and error, and load testing (https://forums.meteor.com/t/solved-poor-galaxy-meteor-performance-serving-small-bursts-of-users-load-test/38671?u=evolross, https://forums.meteor.com/t/mongo-scaling-issues/27905?u=evolross) it looks like the bottlenecks are mostly Mongo related and most definitely my app needing more optimization for how it works with Mongo and the amount of queries it performs per user action (I had lots of collection hooks firing.) You’ll hit Mongo bottlenecks when you have 25,000 users all trying to insert a document at the exact same time. And that document needs to do about five different validation queries before insertion. And then multiple other “resulting effects” queries after insertion.
But I’ve went through a lot of fire testing pubSub, Meteor Methods, oplog, and redis-oplog. I’ve pretty much went full-circle. redis-oplog is performing better than oplog-tailing and looks very promising but my app had a few bugs when I added it and I’m working with redis-oplogon getting them fixed.
2 Likes
Since you asked about meteor on Server, If my company is going to replace meteor, then it would be
- NestJS (Yes its design principles are from angular. But i personally use it in my other frontend frameworks)
- GraphQL with Apollo (Obviosuly)
- Nx Workspace for monorepo setup (I am in love with NX)
I actually don’t want to stop using Meteor 
If seriously - maybe React + Server side nodejs
3 Likes
Three years later, I thought it’d be a good time to report back on what I’ve been using instead of Meteor!
We’re still running v1 of our app (Meteor + React), but it’s got a limited lifetime. It’s on Meteor 1.6, and I’ve tried more than a few times to bring it fully up to date, but the app completely breaks and won’t even load. I believe it’s due to dependencies on Atmosphere packages that are no longer maintained. In short, it would take me probably several days to fix everything, but since I’m working on v2 of our app, it’s not really worth the time/financial investment.
Retrospective thoughts on Meteor (and keep in mind, I haven’t really used it since 1.6, so much of this may have changed):
- It was awesome for rapid development, and I still believe that. It’s so easy to just start a new app and have authentication built in and everything you need.
- Atmosphere was a road they should’ve never gone down. Meteor should’ve used NPM packages from the start.
- Not opening up Meteor (out of the box) to other databases was a misstep. MongoDB is not automatically the best choice for every application!
- No support for source maps. When an error occurs, Sentry tells me nothing useful at all. It’s very frustrating.
This is our v2 stack in case anyone’s curious:
- Vue.js (yep, I stopped using React a few years ago!)
- AWS Cognito for authentication
- AWS Aurora Serverless (Postgres 10.7)
- Several AWS Lambda functions to handle audio processing, image processing, etc.
- AWS API Gateway in front of a Lambda function for our internal API
- AWS SQS to handle incoming interaction events at high speed, to be processed by Lambda and stored in the DB
It’s pretty much a 99% serverless stack, so while this was definitely more complex to set up compared to building a Meteor app, it’s super cost-effective (scales as our customer base grows), and can scale “infinitely” with no extra effort from us as far as fine-tuning servers, adding containers, etc. It’s super fast and snappy compared to our v1 Meteor app.
All the serverless components are designed/deployed using the Serverless Framework, which I highly recommend!
6 Likes
With I could like this twice
I looked a lot at serverless and I personally find it to be the ultimate lock-in (in this case AWS) in addition to the huge increase in the up front complexity and engineering effort. For some apps it might worth trading the sever for the potential of infinite scale however for many apps getting rid of server is not even an option. Also, personally I find the reasons you mentioned that prompted the rewrite to be weak, unless you experienced some major drawback in Mongo or there are other reasons not mentioned here. With regards to Atmosphere, it is actually superior to NPM and created a unique ecosystem of full-stack packages and package based architectures, and folks in the community stepped up maintain the common meteor packages, with that said you can skip Atmosphere completely and just use NPM.
I’m glad to see the serverless hype is slowing down, I don’t think it should have been promoted as a bullet proof architecture for all kind of apps because this could be very misleading, it is simply unfit for many use cases. I went through this path more than a decade ago with Google App Engine/Java which also was scaling infinitely but I learned the hard way the pain of being locked-in to Google’s infrastructure.
With that said I am glad it worked for your use case.
Sidenote: Jeff Bezos net worth has reached a staggering 200 billion today. His net worth seems to scale infinity just like his AWS servers!
11 Likes
MongoDB is fine for many things. My point is that there’s no one perfect DB for all applications. There are some things I personally don’t like about MongoDB:
- Aggregation syntax is confusing and unintuitive
- Lack of cascading is inconvenient for some use cases
- Schemaless DBs in general can be problematic and cause edge case errors if you’re not super careful
I’m using Postgres because the data I’m working with is highly relational in nature, and data aggregation will be more important this time around. Cascading for easy cleanup (either deleting rows or setting references to NULL) is super nice. Postgres’s built-in full text search is super powerful, too. Again, it just depends on your own needs.
2 Likes
I have very good reasons to rewrite & redesign the architecture. Our Meteor stack is on 1.6 and cannot be upgraded, because it completely breaks (probably due to reliance on Atmosphere packages no longer being maintained). It’s frail, Galaxy is costing an insane $170/mo to host, etc. Mongo 3.x end-of-life is next April (on Mongo Atlas) so Meteor 1.6 won’t work anymore. The stack is definitely far from lean and performant, unlike the Vue + serverless stack.
Yes, there are trade-offs of course: more complexity to design and build up front, but IMO the long-term benefits outweigh this. And lock-in is not a big deal to me. I think that’s true with most solutions. Meteor itself is a highly-opinionated lock-in in and of itself, after all.
1 Like
Our V2 stack consists of
nextjs (react)
apollo-client
graphql-nexus
prisma (with posgtress)
it’s super simple, has great type safety, highly customizable and can be deployed either in a node-container (e.g. kubernetes or just a vm) or as static/lambda mix (thanks to nextjs)
I stichted together a demo project, but its not yet polished https://github.com/panter/manul-stack.
it has i18n, an admin backend, a page editor, username/pw login (with admin roles)
The idea is to have something bottom up, where every part is replaceable, but still fast and easy to develop on.
Meteor is not a wrong choice, but I would advice to not use blaze and/or pub sub outside of prototypes as these technologies lock you in and are not really maintained and improved anymore.
Sidenote on mongodb: we switched to postgres just because prisma (2) does not support mongodb yet. (and also because we can use google cloud’s native postgres db). Even with meteor and mongodb, I modeled most data in a relational way anyway. But i still find mongodb really handy and easy to use. And Studio 3T is such a great tool to work on mongoDB.
4 Likes
And unchained 
2 Likes
Rails probably. Rails + erb is basically Meteor + Blaze, in the golden age, which was results oriented. You could spin products in matter of days and implement week long features using gems/packages.
case in point:
1 Like
Hello @ffxsam, one of our first Meteor apps was written in Meteor 1.0 in early 2015 and has been updated with each new release of Meteor. On a few occasions, we had to fix breaking changes by forking or replacing atmosphere/NPM packages. These were most often due to major updates to Node.js.
It really would be useful for you to share the details of what has prevented you from updating your app from 1.6 to the latest version. This would include:
- The list of atmosphere & NPM packages used in your Meteor webapp
- The console messages produced when running meteor update in your webapp project folder
- Any startup error messages produced when running your updated Meteor webapp.
It is possible that some or all of your issues may have been encountered in the past by other developers in the community who can recommend atmosphere/NPM packages to replace any broken ones.
5 Likes
@vlasky I think one of the packages in question might be edgee:slingshot which is very old. Given enough time, I could probably (with some help) build a list of what needs to be replaced/updated, it’s just that I don’t have the resources right now to focus on that.
Once v2 of our product is launched, I may circle back to our v1 Meteor app and see if I can salvage it and assess how much time/money it’ll take to bring it up to date.
fwiw, edgee:slingshot is still working great for me on 1.11
1 Like