This looks cool. Congrats on the launch! Is it a project or a business? Do you intend to make money from hosting? Or something else?
Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
91–100 of 133 posts
Re: Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
#92> Horizon is built on RethinkDB, a massively scalable, open-source database capable of millions of realtime updates per second. Have there been any performance benchmarks or reviews of RethinkDB yet? Especially at this scale?
Checkout the Jepson reports by Aphyr. They go into incredible detail. https://aphyr.com/posts/330-jepsen-rethinkdb-2-2-3-reconfigu...
That's a good report and I've read it before - but still looking for something about the actual performance (latency, throughput, concurrency) that it can handle.
Re: Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
#93Hey guys, Slava @ Rethink here. The team is really excited to launch Horizon -- it's based on a lot of feedback from users of very different backgrounds, and we think it will make web development dramatically easier. I've been up for about twenty-four hours, but I'll be around to answer any questions for the rest of the day.
Once you guys made it big, you should rename yourselves to RethoughtDB :)
Re: Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
#94This looks cool. Congrats on the launch! Is it a project or a business? Do you intend to make money from hosting? Or something else?
Horizon is an open-source project. Horizon Cloud (currently in development) is a business -- http://horizon.io/cloud/
Re: Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
#95This looks really great! Does Horizon support pluggable transport? I would like to use Ajax paired with EventSource/SSE over HTTP/2 for bidirectional communication instead of Web Sockets.
There is currently no EventSource/SSE support, but this came up a couple of times. It should be pretty easy to add, and is currently on the roadmap (though for now still unscheduled).
Re: Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
#96Earlier quoted context omitted.
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 kno…
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!!!". :)
Re: Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
#97Congrats on the launch! As a long-time user of Meteor I'm always excited to see other approaches to similar issues.
One thing that I always found a bit lacking with Meteor was pagination. The problem in a nutshell is that the client doesn't know how much data is potentially available on the server unless it requests it, making things like showing "page 1 of 12" type result counts tricky (I talk more about it here: https://www.discovermeteor.com/blog/pagination-problems-mete... )
I'd be curious to know how Horizon deals with that problem?
Re: Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
#98Hey guys, Slava @ Rethink here. The team is really excited to launch Horizon -- it's based on a lot of feedback from users of very different backgrounds, and we think it will make web development dramatically easier. I've been up for about twenty-four hours, but I'll be around to answer any questions for the rest of the day.
Does it handle conflict resolution, ike when two people modified the same field at almost the same time?
Re: Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
#99Earlier quoted context omitted.
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 kno…
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 transla…
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.
Re: Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
#100Congrats on the launch! As a long-time user of Meteor I'm always excited to see other approaches to similar issues. One thing that I always found a bit lacking with Meteor was pagination. The problem in a nutshell is that the client doesn't know how much data is potentially available on the server unless it requests it, making things like showing "page 1 of 12" type result counts tricky (I talk more about it here: ht…
https://github.com/aldeed/meteor-tabular handles this with custom subscriptions, and it stays up to date by continuously polling the collection without a limit. If you want to get more real-time or more scalable, the problem is that if the total-count subscriptions can't fit in Meteor's memory, every subscription would need to re-request its count from Mongo on every incoming oplog entry, no matter whether it ends up mattering.
Sadly, Horizon doesn't seem to support aggregate queries yet, reactive or not, without loading the records with findAll. Theoretically, Rethink could be even more scalable at this than Mongo, since it could use its index to only "wake up" relevant count subscribers. But this is still on the roadmap:
https://github.com/rethinkdb/rethinkdb/issues/3735 https://github.com/rethinkdb/rethinkdb/issues/1118
Generally, it seems Horizon is very limited compared to Meteor, but it's a great fresh start, with a much more well-thought-out and scalable architecture, and I'm looking forward to seeing where it goes.