4 ms·

Cool! Two noob qs: 1. Would love to learn a bit more about how the rule engine works. From what I understand crux in essence only gives you key->blob semantic

Cool! Two noob qs: 1. Would love to learn a bit more about how the rule engine works. From what I understand crux in essence only gives you key->blob semantics. How do you know that one `doc` is a `user`, and another doc is an `game`, etc 2. re: datalog subscriptions -- do you know if this is something inherently very difficult, or is it that crux hasn't implemented this yet?

jacobobryant 6y ago
1. You have to register specs for each kind of document. For example, from the frontend you can subscribe to a user document of a given ID with `{:table :users :id #uuid "some-uuid"}`. The backend will: (1) look up the document with the given ID, (2) verify that you've registered a spec for the `:users` "table" and verify that the document meets that spec, (3) run the authorization rule to make sure the client has access to that user document. 2. It is inherently difficult. The closest thing like this that exists for datalog is I believe clj-3df[1]. Hence I was very excited when Materialize was launched publicly a few months ago. A version for datalog would be cool too, but SQL is good enough I think. [1] https://github.com/sixthnormal/clj-3df https://github.com/sixthnormal/clj-3df
- stopachka 6y ago
  I see, thanks for going deeper Jacob : )
refset 6y ago
Hi, I work on Crux :) 1) Crux is schemaless at its core, but you can build your own ~class hierarchy model using regular attributes and Datalog rules to differentiate between types of entities. 2) Subscribing to arbitrary Datalog without any form of polling requires a fundamentally different form of query algorithm (i.e. incremental view maintenance, as seen in Materialize), however there's a whole spectrum of possibilities available if you are willing to accept polling at some level. Hasura has quite an inspiring take on subscriptions that we may yet try to recreate on top of Crux: https://hasura.io/blog/1-million-active-graphql-subscriptions/ https://hasura.io/blog/1-million-active-graphql-subscription...
- stopachka 6y ago
  Very cool, thanks for the context refset! : )

jacobobryant 6y ago

1. You have to register specs for each kind of document. For example, from the frontend you can subscribe to a user document of a given ID with `{:table :users :id #uuid "some-uuid"}`. The backend will: (1) look up the document with the given ID, (2) verify that you've registered a spec for the `:users` "table" and verify that the document meets that spec, (3) run the authorization rule to make sure the client has access to that user document. 2. It is inherently difficult. The closest thing like this that exists for datalog is I believe clj-3df[1]. Hence I was very excited when Materialize was launched publicly a few months ago. A version for datalog would be cool too, but SQL is good enough I think. [1] https://github.com/sixthnormal/clj-3df https://github.com/sixthnormal/clj-3df

stopachka 6y ago
I see, thanks for going deeper Jacob : )

refset 6y ago

Hi, I work on Crux :) 1) Crux is schemaless at its core, but you can build your own ~class hierarchy model using regular attributes and Datalog rules to differentiate between types of entities. 2) Subscribing to arbitrary Datalog without any form of polling requires a fundamentally different form of query algorithm (i.e. incremental view maintenance, as seen in Materialize), however there's a whole spectrum of possibilities available if you are willing to accept polling at some level. Hasura has quite an inspiring take on subscriptions that we may yet try to recreate on top of Crux: https://hasura.io/blog/1-million-active-graphql-subscriptions/ https://hasura.io/blog/1-million-active-graphql-subscription...

stopachka 6y ago
Very cool, thanks for the context refset! : )