Fork me on GitHub
#datomic
<
2015-07-07
>
mitchelkuijpers11:07:22

I have a question, I am currently in the process of creating a single page application with datomic on the server. What we would like to do is make one endpoint where you can just post queries and get the results back (we don't need to create a rest server because it is only for use in the single page application). The application is multitenant and I would like to restrict the query to only the data that tenant can see. I have used filter on the complete database but this does not seem like a scalable solution at all. Now I think I should transform the queries on the server so restrict them to one tenant. Have you guys tried something like this?

mitchelkuijpers11:07:55

Or might it be a good idea to create a database per tenant?

mitchelkuijpers11:07:14

I am reluctant to do that because I would lose a lot of opportunities to query the database for overall stats or learning from my customers..

val_waeselynck11:07:28

@mitchelkuijpers: Given that you can run code in queries (including code that have side-effects I believe, since all of clojure.core is included) I think you cannot contend security issues with this approach. Right ?

mitchelkuijpers11:07:18

@val_waeselynck: Yeah that is basically my problem

mitchelkuijpers11:07:18

@val_waeselynck: And using (datomic/filter) has pretty horrible performance unless I could use this on a result of a query

val_waeselynck11:07:22

@mitchelkuijpers: even if you can restrict the set of datoms your client is able to perceive (using e.g filters) that does not change the problem that the client would have access to your whole runtime. That's where the big problem is IMO. Maybe you'll need to add a parsing step before the query to forbid function invocations.

mitchelkuijpers11:07:16

Yeah but that would be pretty easy I guess

mitchelkuijpers11:07:06

Maybe I should just not do it, but I hate creating new rest endpoints for simple queries

Lambda/Sierra11:07:18

@mitchelkuijpers: Even ignoring the arbitrary-code-execution part, a client could easily construct a pathological query which consumes all the resources on the Peer.

mitchelkuijpers12:07:21

@stuartsierra: and @val_waeselynck All valid points let's not do this

Ben Kamphaus14:07:04

We’ve added a Best Practices section to the docs today, see: http://blog.datomic.com/2015/07/datomic-best-practices.html

arohner16:07:10

@mitchelkuijpers: I decided against doing that as well, but I still want something similar.

arohner16:07:27

Writing server endpoints that are just validation around datomic queries is tedious

mitchelkuijpers16:07:12

@arohner maybe om next will give some good ideas how to achieve this

jwm16:07:37

nice to have a best practices document always

val_waeselynck17:07:00

honestly, I think the solution is some kind of RPC that makes it very fast to write server endpoints.

val_waeselynck17:07:16

You don't always have to be RESTful, do you?

jwm18:07:12

websockets works

jwm18:07:56

but for large data rest / json compressed is a lot faster since its compressed / decompressed by the client and server

mitchelkuijpers19:07:34

@bkamphaus: awesome addition to the docs!