If you were to stop using Meteor, what would you use instead?

At https://jssolutionsdev.com/ we started use Express and Reactjs, for mobile app development we use ReactNative. Cordova works really slow.

We also investigate option to work with GraphQL and Apollo as long term opportunity.

But we still use Meteor and React to build new web apps. It depends on circumstances.

1 Like

i totally love mobx. its brilliant. with redux i admit i donā€™t understand the use case or how to use it properly.

the point is, from my experience with redux was very negative. thats all iā€™m saying. its my exp with it, not suggesting that is the grand global truth, or the most complete analysis ever. my exp with it was lousy, hence i think its a piece of turd.

vast amount of boilerplate, for a set of circumstances it is highly unlikely i will ever face. i admit i donā€™t have experience with such large scale projects where redux would add value, and if/when that changes, iā€™ll rethink the opinion.

its just an opinion - no reason to take it any more seriously than that. i respect your opinion on it, just i have a different one given my experiences to date.

I recently investigated the current state of few Meteor alternatives, so I wanted to share few thoughts.

SocketCluster + Mongo or Rethinkdb. This is what Meatier project was based on. More of a low level solution based on uWebSockets in comparison to bigger frameworks, but provides very nice scaling and close to no bloat. Itā€™s got a commercial solution in the beta stage that takes care of the cluster management, but you can do it by yourself too. Pay attention that itā€™s a one man project, while all the others are backed by a company.

I consider using Mongo instead of Rethinkdb because of better server tooling, in this case the reactivity would be achieved by emiting websocket events from the function that tweaks the database state.

Sails + Mongo. Out of the box it has a pub/sub system based on events, too bad it only works with Blueprints (REST generator). Thereā€™s no option to use Rethinkdb. Sails has a new big version in alpha stage, but there are no docs for it.

Feathers + Mongo or Rethinkdb. Like Sails, itā€™s got a new big version in alpha stage. Theyā€™re working on it since april of 2016 though and STILL didnā€™t finish and that tells a lot about the framework in my opinion. At least itā€™s partially documented. Feathers by design donā€™t allow non-REST endpoints at all.

Horizon + Rethinkdb. Like Meteor, it makes you stuck to one database. Unlike Meteor, it doesnā€™t really work well. Thereā€™s not even an option to make a password authentication. Currently, Horizon development is pretty dead. They had a small meeting of people interested in further development few days ago though. Itā€™s now under Linux Foundation like Rethinkdb but no idea what will happen to it.

Deepstream + Mongo or Rethinkdb. Deepstream is based on this weird idea that what we write as a server code in Meteor, should actually be just another client. Maybe it works for some people, butā€¦ man, come on.

Deepstream recently has a commercial platform DeepstreamHub which is a kind of Firebase alternative. You pay for the number of emitted messages, so be sure to divide the number at least 4 times if you want to provide any kind of data validation.

My personal gradation:
Recommended: Meteor and SocketCluster
A valid choice: Sails and Feathers
Not recommended: Horizon and Deepstream

10 Likes

Also useful for complex ui state mgmt like games. See Redux-saga.

Other reasons you might want to use Redux

Persist state to a local storage and then boot up from it, out of the box.

Pre-fill state on the server, send it to the client in HTML, and boot up from it, out of the box.

Serialize user actions and attach them, together with a state snapshot, to automated bug reports, so that the product developers can replay them to reproduce the errors.

Pass action objects over the network to implement collaborative environments without dramatic changes to how the code is written.

Maintain an undo history or implement optimistic mutations without dramatic changes to how the code is written.

Travel between the state history in development, and re-evaluate the current state from the action history when the code changes, a la TDD.

Provide full inspection and control capabilities to the development tooling so that product developers can build custom tools for their apps.

Provide alternative UIs while reusing most of the business logic.

Few more words about Rethinkdb as the alternative for Mongo. Yes, changefeeds are awesome. Yes, joins are awesome. Yes, ReQL is awesome. But it all fades away when there is close to no ecosystem around the database. Whenever you want to do something that is not in the core, youā€™re left alone to write it by yourself and even the only ODM is not maintained anymore. For Mongo, when you need something, you just google it and bang, there it is, available as an npm package.

1 Like

Thanks. It seems very simple and stable combination. Yes, basic ME stack does a lot.

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ā€¦

https://www.youtube.com/watch?v=KeIx-mArUck

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

  1. NestJS (Yes its design principles are from angular. But i personally use it in my other frontend frameworks)
  2. GraphQL with Apollo (Obviosuly)
  3. Nx Workspace for monorepo setup (I am in love with NX)

I actually donā€™t want to stop using Meteor :grinning:
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

@ffxsam, just wondering what issues you had with MongoDB that made you think itā€™s not a good fit?

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