A very common pattern that's been found vulnerable. Glad to see it mentioned here.
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.
I disagree, Meteor project are quick to ramp up but the second something goes wrong it's just a nightmare. Code is not structured at all, strange packages to do things that fall by to the sides, performance issues that are hard to track/debug.
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!
Agree. I've used Meteor for several large projects and this has been my overall feel. MDG didn't take official stances when it was needed (e.g. Router), and the "Meteor way" to do things was constantly changing.
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
If you use contexts (which is a fancy way of saying use a business layer) for your applications logic, you end up with small, isolated functions that are super easy to test.
`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.
Structuring code is easily done by setting standards for a project. I don't understand that issue. Nothing stops a team from having consistency and even building a meteor app MVC rails style folder structure or a per module-mvc type of style.
Meteor works on top of Node, so any host that can host a Node.js app can host a Meteor app. I'm also not sure if I'd use Meteor at scale, but I love writing the initial version of projects in it.
Doing a project in Meteor + React right now, and it's kind of fun.
I also did a reasonable size project in Meteor, was pretty quick to get going, but the nightmare started as the project evolved, packages got abandoned, and Mongo was really very very average.
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.
- 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 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.
It sounds like you've built some interesting technologies!
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?
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.
(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 loved Blaze and closest thing to it is Ractive(https://ractive.js.org/). For backend reactive stuff there are many options like horizon/firebase/rapid.io/gun/etc, but for something more complex easiness of RPC through DDP is hard to replace though.
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.
This disclosure is great to see, got an email and immediately patched my apps annd redeployed with no downtime and minimal exposure. Meteor is an amazing time saver and a superb framework/build process.
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.
You don't need to use methods if you don't want to. It's pretty easy to integrate either rest via an integrated express server or if you prefer GraphQL you can host your GraphQL in Meteor.
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.
Using allow/deny has been an anti-pattern for a while now (using methods is preferred). My projects are not affected, but it is nice to see this so quickly.
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.