i’m sorry - i probably don’t understand how to use redux, or the use case, or something, but for my money it is a piece of shit.
Maybe massive benefits when it comes to scaling or something, but i don’t have that problem to the extent non-stupid design could not fix it…
Wow. 
You might find no personal use for Redux, but if it were truly a “piece of shit,” I doubt it would have as many people and companies using it. Granted, I have my own opinions about Redux (I think it’s maybe a little overly complex), but I can still see its value. Now, as far as using it in the Meteor ecosystem… you’re right, it probably has very little use since we can use ReactiveVar and Session to handle global state. In fact I’ve ripped out Redux from two Meteor projects that I thought I needed it in. But for those who are using pure React as their front-end, Redux or Mobx is—in many cases—totally necessary.
It seems to me that if you’ve a really large and complex client with a lot of things changing, many dependencies and multiple people collaborating on the code base, then I think it’s useful to be very explicit, transparent and develop a centralized and global source of truth on how each action changes the entire state of the client app.
For medium and smaller size apps, where one or two developers working on the front-end code and state changes are not that complex to grasp and maintain in the developers memory, then something like Redux might be an overkill. Furthermore Meteor does have mini-mongo and reactive data sources but it leaves it up to the developer to decide where and how this data will change. If the app grows in size and the developer continues modifying global reactive session variables all over the code, then you might end up with unexpected states, bugs that are hard to trace, and unmaintainable code.
But yeah I don’t like it when people blindly follow the latest trend and adopt the next shiny toy out there without careful evaluation of what does it really provide and whether it’s the right tool for the job in hand.
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!