5 ms·

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 s

by btown 9y ago

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.

sergiotapia 9y ago
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!
- thsowers 9y ago
  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
  - sergiotapia 9y ago
    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.
    - malloryerik 9y ago
      Do any of you guys use Elixir/Phoenix with React and Absinthe GraphQL? And how about Clojure(Script)? Now that ClojureScript can consume almost all JS libraries, isn't it a serious contender?
- dfischer 9y ago
  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.
- chasedehan 9y ago
  I built one (semi major) project in meteor because it looked cool and easy to spin up - which it was. 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.
  - dvt 9y ago
    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.
- keithnz 9y ago
  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.
ggg9990 9y ago
What have most people shifted to from Meteor?
- e9 9y ago
  I loved Blaze and closest thing to it is Ractive(https://ractive.js.org/ 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.
- cultofmetatron 9y ago
  phoenix framework! 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-websocket-connections 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.
marknadal 9y ago
Disclosure: I am the author of a competing MIT/ZLIB/Apache2 system. > "There's still no better way in 2017", RethinkDB's Horizon ( http://horizon.io/ http://horizon.io/ ) and our tool, GUN ( https://github.com/amark/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 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 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 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.
- bnjmn 9y ago
  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/ 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.
  - marknadal 9y ago
    Fair, fair point. 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!

by btown 9y ago

sergiotapia 9y ago

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!

thsowers 9y ago
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
- sergiotapia 9y ago
  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.
  - malloryerik 9y ago
    Do any of you guys use Elixir/Phoenix with React and Absinthe GraphQL? And how about Clojure(Script)? Now that ClojureScript can consume almost all JS libraries, isn't it a serious contender?
dfischer 9y ago
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.
chasedehan 9y ago
I built one (semi major) project in meteor because it looked cool and easy to spin up - which it was. 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.
- dvt 9y ago
  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.
keithnz 9y ago
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.

ggg9990 9y ago

What have most people shifted to from Meteor?

e9 9y ago
I loved Blaze and closest thing to it is Ractive(https://ractive.js.org/ 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.
cultofmetatron 9y ago
phoenix framework! 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-websocket-connections 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.

marknadal 9y ago

Disclosure: I am the author of a competing MIT/ZLIB/Apache2 system. > "There's still no better way in 2017", RethinkDB's Horizon ( http://horizon.io/ http://horizon.io/ ) and our tool, GUN ( https://github.com/amark/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 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 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 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.

bnjmn 9y ago
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/ 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.
- marknadal 9y ago
  Fair, fair point. 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!