Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB

Re:Horizon 1.0: a realtime, open-source JavaScript back end ... by SomeCallMeTim on Tuesday May 17, 2016 @08:03PM (#11718659)

OK, glad to hear that it does work for you. Sounds like you have a robust architecture.

I don't actually know what is supposed to "not scale" about Meteor. I've just read it multiple times. But because of the nature of Meteor (Really easy for anyone to set up! Anyone can create a real time app in ten minutes or less!), it probably attracts a lot of junior developers. It therefore should have occurred to me to translate "It doesn't scale!" to "I don't know how to scale it and my app is slow!!!". :)

[ Parent | on HN ]

Re:Horizon 1.0: a realtime, open-source JavaScript back end ... by gchpaco on Tuesday May 17, 2016 @08:36PM (#11718828)

There are two major issues that crop up in my experience.

* Node as a runtime is deeply mediocre, in my experience. You can usually solve this by throwing more (usually virtualized) hardware at the problem.

* Meteor's architecture is (at present) tied into MongoDB's oplog tailing. You can scale it up through sharding, through alternate libraries, and DDP itself is not tied to MongoDB at all. IIRC fixing this was a goal for Meteor 2.0.

Both of these can be worked around. If nothing else, the Meteor web side will talk to anything doing DDP, and DDP is not that hard to deal with.

[ Parent | on HN ]

Re:Horizon 1.0: a realtime, open-source JavaScript back end ... by ben_jones on Tuesday May 17, 2016 @10:16PM (#11719263)

It comes up because Meteor gets slow faster then most other solutions will get slow. It kind of reminds me in Django how a common mis-step for beginners is using an O(n^2) algorithm on the Django ORM. Meteor is the same way if you aren't using proper indices, or are trying do something that SEEMS doable to the uninitiated (like say pushing ~n thousand JSON objects into a MongoDB set), it's going to give you a bad time.

[ Parent | on HN ]