Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
51–60 of 133 posts
Re: Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
#52> 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?
https://aphyr.com/posts/330-jepsen-rethinkdb-2-2-3-reconfigu...
Re: Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
#53> 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?
We have a performance benchmark report we did a couple months ago basically locked and loaded to publish with accompanying scripts and data for transparent review of our methodology. We just have been so busy with Horizon, we had put this on the back burner. Expect to see something within the next couple weeks when we can put some serious attention to it to ensure we do everything just right.
In the meantime, you should check out the whitepaper by BigchainDB which uses RethinkDB for the purposes of consistency and automatic change notifications [1].
Re: Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
#54You may want to make your homepage clearer, before navigating to the FAQ I did not have a clue of what Horizon really does.
Re: Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
#55Hey 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.
Make sure you don't regret about your answers later :) Answering questions on HN after being 24 hours awake is generally not a good idea :)
Re: Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
#56Re: Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
#57Hey 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.
1. Do you have something analogous to https://www.firebase.com/docs/web/api/ondisconnect? Real-time apps often have some manner of presence indicator. Firebase allows you to say "when this client disconnects, set the value of this key to $BLAH". I noticed that Horizon has http://horizon.io/api/horizon/#ondisconnected, but this is just a client-side indication of when you've disconnected.
2. What are Horizon's transaction properties? How about ordering of appends to a collection?
Re: Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
#58Anyone got the chat example working?
We pushed a hotfix a few minutes after launch that resolved this issue [1] which you may be experiencing. You should try doing `npm update -g` if you're still on `horizon 1.0.0`. You can check with `hz version`.
If this doesn't fix it for you, please open up an issue [2] and I will help you out.
Re: Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
#59Re: Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
#60Earlier quoted context omitted.
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?
Out of the box Meteor does publish the to the browser. But I believe if you remove the insecure package you then control what is published to the browser e.g. usually only a subset of the db.
Security is the same as the clients DB writes are rejected if they are modifying fields in ways that are not permitted (eg: changing a trouble ticket from "submitted" to "approved"). This can make some of the security easier to audit as most of the business logic security is in one place rather than scattered about in dozens of API calls.
While the exact technical details for these real-time DB based front ends are different, the basic thinking is the same of never trust the client and its costly to transmit info to the client.
The nice thing about having the DB directly on the client is that it makes CRUD apps much easier to make as you have to build less bespoke framework to get data to/from the client and verifying things conform to business logic. If you are not building a CRUD app you will want to evaluate other methods for a better fit.