Live data from Hacker News

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

horizon.io

81–90 of 133 posts

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

#81

Earlier quoted context omitted.

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.

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

#82

> Horizon is distributed as a standalone server for browser-based JavaScript apps. When you're ready to write custom backend code, you can load the Horizon modules directly in Node.js This is key. Firebase seems great for quick prototypes, but I never built against it because it was unclear (to me at least) how to deal with cases where you want to leave the sandbox and add custom backend functionality that they haven…

I've setup background workers that connect to a firebase DB to perform business logic / backendy type stuff. It works rather well and they even have a queue collection specifically for this type of thing. You could even setup a daemon on a VPS / EC2 that would in turn fire up AWS lambda procs (node or w/e) to perform w/ your firebase data.

Regardless, I'm very excited to play around w/ Horizon as well.

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

#83
post #79

Excellent work Slava! Have been planning to migrate to RethinkDB for one of the existing projects, great timing with Horizon :D

Slava @ Rethink here. Just wanted to point out that only a tiny amount of credit for Horizon belongs to me, as most of it has been a product of tireless work of many people (hey Marc, Dalan, Josh, Daniel, Michael, Annie, Christina, Ryan, Mlucy, Chris, Marshall, and all the awesome beta contributors!)

This isn't false humility either -- I've been super busy with some other aspects of RethinkDB over the past few months, so while I did have a hand in designing and shipping Horizon, maybe less than 5% of it was my doing.

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

#84
Looks really promising to me, relatively similar to www.deepstream.io . However, will there be additional clients /are they already in development by the community? So far I only found support for vue.js and React. Polymer elements would be pretty dope... ;)

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

#85
post #22

Slava, Horizon looks cool, and I'm a huge fanboy of RethinkDB. However, in the demo video you write queries client side. How do you protect against users modifying front-end JavaScript and thus the queries? // ex this.props.horizon.order('datetime', 'descending').limit(8).watch()

This is the question I always get stuck on with these "front-end only" frameworks. How do you prevent DoS attacks or scrapers downloading your whole database? What is the information security model?

(Josh from RethinkDB here)

The sibling comment by ubercore has the right link. And your concern is important, since without security, why not just expose your db to the frontend directly?

At a high level, the permission system:

1. Is a whitelist approach (you can't do anything by default)

2. Allows you to specify query shapes that are allowed to be run by the current user. This prevents queries of the wrong shape from ever hitting the database, helping with scalability.

3. Has a fallback to full javascript rules which can depend on the data on disk. A little slower than the query rules, but allows much more flexibility where you need it. And you can combine them with a query rule to do a rough first pass of what is acceptable.

Ultimately, the permissions system is designed to prevent unfettered database access, but it also has an eye towards performance in the case of DOS attacks. Horizon overall attempts to use only indexed queries, low resource usage operations etc, so you don't accidentally invite DOS attacks .

Now, I'm not claiming we're DOS proof or anything, but I just intend to mention we have an eye towards it when we talk about security.

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

#87
post #86

Great thinking from the RethinkDB side. One answer I couldn't find on their website is about the offline and optimistic update. It's really tricky to get right. Having a feed of changes is just a small part of having a robust solution.

Take a look at this comment: https://news.ycombinator.com/item?id=11716145. TL;DR: currently not optimistic but will be soon; it's fairly simple to do because RethinkDB core has built in support for it. Once the feature lands in Horizon we'll talk about the implementation in detail.

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

#88
post #86

Great thinking from the RethinkDB side. One answer I couldn't find on their website is about the offline and optimistic update. It's really tricky to get right. Having a feed of changes is just a small part of having a robust solution.

This is on our list : https://github.com/rethinkdb/horizon/issues/23

The big piece remaining that will help is write timestamps in the database, which we're going to try to land in RethinkDB 2.4. If we were controlling a traditional MVC frontend model and had control over the objects themselves, it would be easier to do optimistic updates. Since we're aiming to be compatible with a lot of frontend frameworks where immutability of the model is important, we have to carefully consider how to do it.

That being said, it's super important, so it's near the top of our priorities

Post reply on HN