Hacker News Reader

Hacker News

Comment by cjbprime | Hacker News Reader

Parent Full thread

cjbprime

There's one on the website:

http://horizon.io/faq/

View on HN

IMO it hand waves Meteor away without acknowledging (perhaps out of ignorance) some of it's other strengths.

I'll watch Horizon but I'm taking it all with a grain of salt. Standard new javascript framework protocol people.

The FAQ repeats some things I've heard about Meteor -- specifically that its architecture doesn't scale.

But Meteor isn't completely prescriptive. There are several pieces that can be swapped out: You can use Angular, React, or Blaze on the client, for instance.

From what I've read, it doesn't look like Horizon is a complete framework, just a database client/server component that can be used with any framework.

We have a short-burst, write-heavy, mostly cpu-bound, work-load, which according to the various financially incentivized critics would completely knee-cap us for our use of Meteor.

Except we:

1) optimized our database operations

2) relegated cpu-bound work to micro-services that could process work from a queue at their own pace

3) Leveraged the ecosystem to writer smarter and more concise code

Know your enemy and know yourself and you need not fear the result of a thousand battles (Sun Tzu). Meteor is an amazingly productive ecosystem for writing real-time applications. No it will not solve every problem you throw at it.

Just to be clear I'm not hating on Horizon. I definitely will try it in the future.

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!!!". :)

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.

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.

"2) relegated cpu-bound work to micro-services that could process work from a queue at their own pace" doesn't this defeat the primary selling point of meteor?

The three key features we derive from Meteor are:

1) real-time view layer

2) diverse and highly integrated ecosystem (libs are written just for meteor)

3) productive development environment (es2015 modules on client/server, no fuss build pipline for sass, jade, angular-templates, angular dependency injection)

There are a ton of secondary benefits, but thats the crux of it. Yes we do sacrifice some of the benefits of Meteor as a monolithic (homogenous?) full-stack solution, but I would argue that they are in fact small, and if you dive into Meteor you'll find it to be pretty modular.

Reply on news.ycombinator.com