Meteor allow/deny vulnerability disclosure
forums.meteor.com
forums.meteor.com
To the larger point: It's great to see that people are still taking Meteor seriously (there are dozens of us! dozens!). If you're willing to use Mongo - which is VERY flexible if you use it as a materialized view that's fed by other processes, rather than the canonical source of CRUD data - then there's still no better way in 2017 than Meteor/React to prototype a real-time interface whose infrastructure you control. Almost all the code is regular old React, and there's minimal impedance mismatch moving from Meteor HOCs that grab a nested Mongo object, to HOCs that grab a nested object from GraphQL/Apollo allowing you to use other databases.
Testing is still a third-class citizen in Meteor for some reason. The official guide mentions testing, but in the four times I've tried to follow it over the course of a year, I could never get it to work properly.
On the flipside, using Elixir and Phoenix you know exactly what's going on and why, you have real control over your DB queries. You can benchmark properly. Your tests are 100% real and accurate, and run properly. It's much better. You sleep better at night that's for sure.
I say this as someone who has used Meteor for multiple projects and used to love it!
Now there is only one developer left working on Meteor, where the rest of their resources have been dumped into Apollo, and Galaxy their self hosted service. I can't speak to Apollo, but my experience with Galaxy has been frustrating and I eventually moved away from it.
For new projects I'm looking into Elixir + Phoenix, Vue, and others. Could you speak to your testing experience in a large app with Phoenix + Elixir? You mentioned that testing has always been a third class citizen in Meteor and I have to agree.
Meteor was great to get started with, and like sergiotapia I used to love it. After working with it for a while, I think Meteor's limitations (particularly mongo) really start to show, and it lacks the driving development behind it that new frameworks like Phoenix and Rocket have
`mix test` just nukes your tests and runs them really fast. About 200 tests run in about 5 seconds. Since tests run so fast you end up writing more tests, you end up writing smaller functions, you end up with cleaner code. Everything just falls in the right places almost by itself.
And how about Clojure(Script)? Now that ClojureScript can consume almost all JS libraries, isn't it a serious contender?
The problem as stated here was that when there was a chrome update, iron-router broke and spent quite a bit of time trying to figure it out.
Not to mention that shortly after I got it fixed one of the only hosting solutions that I had it hosted on (modulus.io) went under and so did my app.
It was brutally frustrating. Saying that, I would probably use it again in some sort of hackathon or startup weekend, but not anything of scale.
Doing a project in Meteor + React right now, and it's kind of fun.
The real value proposition of Meteor wasn't really it's data reactivity (still nice to have), it was having a prebaked authentication / data backend from the get go.
sure you may not get the oplog tailing but you do get a realtime websocket system that scales. Also, I'm fron teh school of thought that mongodb should never be your primary database for a whole host of reasons (no multi-record trabsactions, eventual instead of immediate consistency, limited query language to name a few). http://phoenixframework.org/blog/the-road-to-2-million-webso...
you don't get reactive stores (yet) but with absinthe's new subscriptions system, you can add in reactivity where it doesn't bottleneck your development.
> "There's still no better way in 2017", RethinkDB's Horizon ( http://horizon.io/ ) and our tool, GUN ( https://github.com/amark/gun ), seriously contest that fact.
For instance,
- You get realtime data sync out of the box with an infrastructure you control and do not have to manage. See our demoes that survive Split Brain failures correctly, compare this with the delicacy needed of configuring MongoDB clusters properly, or the overhead of using Galaxy.
- You also get realtime GraphQL subscriptions for free, via https://github.com/brysgo/graphql-gun .
- You get graph data structures that support circular references in plain old JavaScript objects, or use tables or key/value pairs, or full documents! See https://github.com/amark/gun/wiki/graphs .
- You can go entirely P2P and decentralized, the community just launched end-to-end encrypted user accounts that I demo in this video: https://youtu.be/ik_dqXBMBHw .
Instead with Meteor, you get locked into a monolithic framework that chose bad architecture with its technology, that will make it prohibitively complex to scale. There are definitely better options in 2017, and that includes ones other than mine as well. Do yourself a favor and don't shoot yourself in the foot with Meteor.
Some food for thought:
* RethinkDB was a startup that both collaborated and competed with Meteor, until it [went defunct](https://rethinkdb.com/blog/rethinkdb-shutdown/) last year, leaving its open-source technologies to be maintained by the community.
* Your gun project depends heavily on graphql-anywhere, which is a project maintained by none other than... Meteor Development Group.
Given the ways in which you've benefited from the community in general, and MDG in particular, I'm surprised you took this zero-sum, winner-take-whatever, nakedly self-promotional attitude. Let's be better than that?
Disclosure: I work on Meteor.
I did not realize (I'm not the author of gun-graphql, it is from an open source community contributor) graphql-anywhere was a Meteor project.
I think that Meteor can be the winner-takes-all in open source centralized realtime services, and they/you have been so far. However, as I've actively debated here and elsewhere, that Master-Slave architecture is not scalable. While I love RethinkDB and think that they were the best, I also criticized that their shutdown was evidence of a systemic downsizing in use cases for centralized infrastructure - and therefore could not gain a large enough market capitalization for Open Source to make sense from a financial model.
The RethinkDB guys are some of the nicest and most brilliant engineers I have ever met (also evidence to that fact is their success with the Jepsen Tests compared to other vendors), but the architecture choice is unfortunately a mistake.
So please take my comments as an engineering analysis, I myself should admit (and thank you for calling me out!) that: If you are building some app that needs Strong Consistency (like a banking application), then Meteor will be a much much better choice than gun, since we are an eventually consistent manner.
Thanks for calling me out!
Horizon is abandonware (no commits for months), and Gun doesn't even handle unsubscribe-on-unmount in either its official React examples https://github.com/amark/gun/blob/master/examples/react/src/... or in graphql-gun https://github.com/brysgo/graphql-gun/blob/master/react/inde... ... which would lead to memory leaks since the callback still holds a reference to the component instance. In fact, the API documentation doesn't even mention a way to cancel a subscription.
(It's true that Gun's offline-first approach is unique, but with mobile connectivity these days it's not often a requirement for B2B applications.)
Regardless, for both technologies, these are indications that neither has the professional backing that Meteor has enjoyed, and continues to enjoy, throughout its history. A real-time contender to watch with that type of backing is deepstreamhub.com which is significantly closer to having a professional-quality realtime product... but it's only recently released, with a nascent open-source plugin/tutorial ecosystem.
Again, all of this is in the context of the following advice: Build a best-in-class React (or Angular) app, with routing/organization/testing taken from best non-realtime practices in those ecosystems, and have only a small number of containers depend on, and declaratively subscribe to, any specific data layer. As the real-time data ecosystem changes, migration between platforms can be restricted to minor code changes in those containers... in which case it makes sense to choose a framework that provides a stable platform well supported by documentation and amassed questions from years of usage.
I hope to see Gun become a legitimate choice in the near future! But I need to bet on the horse that's miles ahead in the race.
I used to be strongly in favor of Meteor as a time-saver but as I got more exposure, I realized how weak and annoying it is to work with.
You are largely stuck into Meteor's ecosystem and at their whim, meaning you have to do things "the meteor way". Things like methods and promises ("Futures") are annoying to me because they abstract away so much.
Maybe it is just a matter of "growing up", but I think I am going towards more non-framework frameworks like Choo.js in the future. I used to think Meteor was a quick prototyper, but Choo is infinitely quicker.
As for Futures, that's not necessary as you can now use ES7 await in Meteor seamlessly on both the client and server out of the box.
I just submitted a PR to the main Meteor docs pointing there: https://github.com/meteor/docs/pull/164