Fork me on GitHub

so here’s an idea: how bad would it be to expose a single endpoint that would accept crux datalog directly from your cljs app? The main challenges I see are granular security (it would be an all-or-nothing situation initially) and rate-limiting… But it would flatten the architecture significantly I guess. It’s similar to what biff does, right?


I was also interested in this idea, more so because there are transaction functions where one can perform any arbitrary logic including authentication/authorization. Had asked this same question in off-topic once and the response was something along these lines: if I control the cljs app, it is as much like any other db client that is in my control, but if the API can be queried by anyone, then there could always be problematic and slow queries

oxalorg (Mitesh)17:06:40

I'm not sure if this is exactly what you want, but I think "site" does something similar. Maybe you can check it out

👍 3

I’m not deeply familiar, am sharing my understanding: • use • To me Biff is similar – build a backend to process frontend requests containing and queries, with applied on the backend • Also similar to me: the fundamental data-fetching architecture for is sending EQL queries from the frontend to to handle from the backend ◦ Pathom can resolve data in Crux and elsewhere, and can be part of an authorization system


crux has a http server already 🙂

❤️ 3

I sort of do this in my app, not sure if it will be a bad idea but my architecture is indeed very simple and combining fulcro + eql + crux pull is very powerful, I use fulcro form state and its diffs are easy to turn into transactions. I use firebase to identify the user and have that available in the endpoint handlers (using pathom, but crux+eql does heavy lifting).

🆒 7

> my architecture is indeed very simple and combining fulcro + eql + crux pull is very powerful this sounds great...I know there are many people here who would be curious to learn more, myself included!

☝️ 6
👍 3