sure, but how much actual bottleneck is it for just opening those websocket connections for user auth? I didnt pick meteor for realtime, i picked it for easy and fast development. (i also decoupled front and backend so i can always just switch out meteor for something better suited)
for an auth request, the only difference is the game of pingpong that happens after the connection-- hardly a big deal. What you need to keep in mind is that your server has to keep track of all those connected sockets and the CPU that started the connection is the one that has to respond to the request. Meteor takes care of all of this for you, so if youāre happy, donāt ruin a good thing!
But, if your app gets real popular, or you want to reduce the initial load time, or you want to use fun things like css-modules, or you need to do something computationally expensive & need a newer version of node, or you want to develop code on the server without the builder recreating the client every. single. time. then you might want to explore your options.
2 Likes
Very cool project. Iām curious if anyone today is using this rethink / redux / react stack in production. This is probably the best alternative to the Meteor tech stack Iāve seen.
1 Like
Iām curious if anyone today is using this rethink / redux / react stack in production.
Iām using this is in two apps (one React Native and the other a web admin app). Itās working great. I only have one part thatās ārealtimeā using the changefeed but that part was easier than expected.
Technically one is using Alt flux instead of Redux but itās on the backlog to migrate it at some point (Redux is much more defined as to what goes where so iāll need to do some re-wiring).
Compared to Meteor, what are your thoughts? Tradeoffs, weaknesses, strengths?
I think its REAME answers your questions already: It trades a little simplicity for a lot of flexibility.
@mattkrick: have you considered couchdb/pouchdb ? Having mobile/offline first could be a nice addition IMO. Very nice project !
Compared to Meteor, what are your thoughts? Tradeoffs, weaknesses, strengths?
The pros are mainly that it ājust worksā and you donāt have to worry about reactivity edge cases. Itās much more flexible.
The cons are (assuming you donāt know either setup) that you have to learn several things to get going instead of one framework. For example you need to learn Express and socket.io to push down results in realtime.
If I get some free time iām going to migrate this to Elixir because itās so small and having the entire backend as one framework will be nice. If I need two nodes it would be easier too.
IMHO if Meteorās restrictions are a deal breaker than it would make sense to roll your own.
I was looking for more insights rather than broad strokes. Maybe somebody using the stack learned something beyond that point, after building something of greater complexity.
@SkinnyGeek1010 I donāt know how you do it all! Between meteor+webpack and now this, thanks!
1 Like
Youāve missed one of the underlying architectural concepts behind minimongoā¦ it acts as a client-side replica-set.
Everything else you describe is fineā¦ itās just looking at things from the webdev viewpoint, and not the database admin viewpoint.
But by missing the idea of client-side replica-set, youāre missing what made Meteor so successful in the first place. Itās not that minimongo is acting as a state storeā¦ it is. But the real power is that it manages cache invalidation and provides a 1-to-1 mapping of the state store to persistent storage. And does it by getting rid of the ORM layer to boot. Win-win-win.
6 Likes
Iāve looked into that EXTENSIVELY & itāll be the next thing I want to implement. Itās really cool tech, especially when combined with webworkers. Pouch, Relay, Lokka, Minimongo, ReqlLite (IIRC), etc all get you almost there but nothing does exactly what I want. Ideally, I want something that dedupes fetches on each component, treats every fetch as a subscription with a defined frequency, and uses graphql (or falcor) to send a query to the server. That would enable you to scale your ārealtimeabilityā. RethinkDB is coming out with some magical client-side thing & after that drops I may start building out an API for graphQL with sockets & offline ability, but hopefully someone else does it before it becomes a necessity for meā¦
if you are so frustrated with meteor that you are willing to roll your own, use this. otherwise, stick with meteor.
Easier than changing 1 character? https://github.com/mattkrick/meatier/blob/master/src/server/server.js#L12 
give it a try, you may not even need elixir (but if you do convert it, I know the socketCluster repo owner would be super excited to see it stress tested next to elixir!).
Totally true! I consider it a feature 
Hereās why: if you want a client-side replica of your DB, just make sure every local mutation also calls the server. BUT, thereāve been some times I donāt want this. drag & drop is a perfect example (and the reason I demonstrated with a kanban). If I drag item #1 to position #10, I donāt want to send 10 calls to the DB telling it to update the position to 2,3,4ā¦10. Iād rather wait for the drop trigger & make 1 call. This isnāt easy to circumvent with minimongo. You have to create a second state (either in redux, on the component, or bespoke) and slip it in between minimongo & your view. A little less magic, but a lot more flexible!
This is a little off topic but for what itās worth a more efficient way to do this is to split the difference between the siblings indexes. For example if you have a card in position 1 and you want to put it in between 9 and 10 you make that card have an index of 9.5. This puts it in as the tenth card, makes it sort properly, and is scalable for writes.
Easier than changing 1 character? meatier/server.js at master Ā· mattkrick/meatier Ā· GitHub
give it a try, you may not even need elixir (but if you do convert it, I know the socketCluster repo owner would be super excited to see it stress tested next to elixir!).
Oh snap I didnāt realize you made Meatier 
It looks really nice! I was just talking about vanilla express but that makes it pretty simple Does that use Redis or something to sync nodes?
The main thing that interests me with Elixir is the Erlang VMs error handling and the built in support for microservices, distributed computing, etcā¦ The scaling is just icing on the cake 
Whew, glad someone else does it that way, too! Thatās how I currently do it, but in the back of my head I was thinking it was too hacky to use with only 15 point precision, but if you approve Iāll leave it be
Vertically itās all socketCluster āmagicā. Each node server is a worker, you have 1 or many brokers for those workers & the brokers communicate efficiently across CPUs. Really cool stuff.
Horizontally, Redis is probably the easiest. http://socketcluster.io/#!/docs/scaling-horizontally
Honestly, when to scale horizontally is a question I have for the general realtime community (and the meteor community is pretty much synonymous with the realtime community right now). Yeah, putting a server on another continent could give faster responses, but running a redis is an extra $25/month and only hosting 1 redis seems a little fragile, so Iāll probably stay vertical until I fill up all 32 CPUs on AWS or have to worry about internationalizationā¦
1 Like
This is a really cool exploration. Have you done any more with this? Any general sentiments since last year? @mattkrick
/cc @SkinnyGeek1010 what are your thoughts on this with relation to elixir/phoenix?
I personally have been moving towards a redux + phoenix mental model of ideal setup but rethinkdb support and all in one codebase in JavaScript is still pretty valuable.
Interesting architecture here. I wonder how Meteorās reactive graphql will play out in a comparison.
I think Phoenix is a great technology for building an API, especially if you need a realtime API that needs a ton of scale. Also the fact that you donāt have to write JavaScript on the backend can be a plus. I also really like the more simple realtime model that Phoenix provides.
However, I think Meteor still brings a lot to the table for startups. Building fast is usually more important than building something scalable (unless youāre building out Uber where it can only work at scale).
I just built a new greenfield Meteor app with MongoDB and Blaze because it was simple and fast to get to market (it was a really simple app).
For most average apps I still think Meteor plus GraphQL and Redux are the best way to go. When Reactive GraphQL comes out a lot of the Redux part can be taken away and replaced with MDGs āversion of Relayā.
Also RethinkDBs upcoming platform looks like it can fill the gap with a Phoenix like subscribe modelā¦ canāt wait for that to come out 
2 Likes
Thereās no ideal setup. You need to collab on a document? Use swarm.js. You need the build whatsapp? Use elixir. You need to make a social network? Use Neo4j. You need to build an MVP in a day? Use Meteor. I needed frequent updates where data lives in a single location, has a landing page that paints above the fold in < 10Kb, is easy as pie to debug, and scales. So I made meatier.
Iād be stoked if Meteor took a few patterns from it & used that to carve out their next offering, but I donāt expect it. Sounds like theyāre gonna put a meteor flavor on graphQL, same as what they were talking about doing with webpack. Personally, I like vanilla
1 Like
Iāve just stumbled across this and see that the repo hasnāt been updated for about 10 or more months and we are almost 18 months since the last post.
Is it still being used? I like Meteor + React and am just about ready to upgrade to 1.5 but, something in me still likes the idea of this.
It all looks interesting (although I donāt have much time to play with it).