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.
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
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.
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ā¦
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.
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.
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.
Since you asked about meteor on Server, If my company is going to replace meteor, then it would be
I actually donāt want to stop using Meteor 
If seriously - maybe React + Server side nodejs
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):
This is our v2 stack in case anyoneās curious:
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!
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!
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:
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.