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()
You can't protect from the client modifying the JavaScript code, and that's ok. Horizon ships with a full security model (http://horizon.io/docs/permissions/) that lets you specify exactly what data each user can and cannot access, which queries they can run, etc. We're going to continue expanding the security model to include DoS protection, and any other issues that may come up.
So while the user can change JavaScript as they please, that's ok; if they try to do something they're not supposed to do, the server will just reject the query.
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?
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.
I would think you'd do this server-side, I've had similar issues outside of JavaScript: users play a game and create a custom client that connects to my server, they send custom packets thereby I have to make sure that they: don't access too much data at once (a user asking for 100 different things in 3 seconds is not even normal in certain scenarios) or the data they're requesting is formatted wrong (a string where a integer is expected?) the solution I guess is server-sided. This issue isn't unique only to client-side javascript, it is relevant in networking as well. So long as the back-end is designed intelligently it could all work out.
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.
On the Meteor App I'm currently working on, we limit the data the client sees to what they need, so while it makes a scrapers job slightly easier as they can query the DB, they don't get anymore data than any other approach. If data is displayed to the user they can scrape it.
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.
