I ended up heavily modifying subgraph to fit my needs. Up to the point when there's no original code left. :)

Haha, thanks for sharing!

https://github.com/threatgrid/asami and the talk about it - https://www.youtube.com/watch?v=tbVwmFBnfo4

"And about 18 months later I found out about Datascript, which was very frustrating 'cause I would've just used that if I'd known about it" :D

But as I have mentioned plenty of times before - if you care about the performance, check it before going full-in with Datascript or anything like that. Prior to doing that, also think if you really need a graph database. In my projects, so far only the regular relational DBs were needed. And a couple of years ago when I tested Datascript performance vs Subgraph, Datascript was about 10x slower.

@U2FRKM4TW Do you use any tools for a relation DB via CLJ maps?

As I said above - a heavily modified version of subgraph.

That's open source? 🙂

Nope. And I doubt that it would be terribly useful since it's tailored for a particular project.

Alright, just curious

Perhaps there’s a way to convert the Datascript “db” to a map before passing it to re-frame devtools (this is just a speculation, I haven’t used re-frame and/or devtools)

Yeah, don't know off the top of my head

does reagent currently support any other rendering engines besides react?

there was talk of supporting Preact i am not sure if it works yet

I’m generally interested in adding alternative rendering engine support to some of the popular clojure UI libs. was hoping to find some examples. so far, it seems like most of the libs are strongly coupled with react and even more so with the DOM

one that i know of which isn't coupled with React is Moria, a wrapper for Mithril: https://github.com/owengalenjones/moria

does that mean it’s coupled to mithril?

yes

Shoot! Might have to do some manual digging to find out where the issues are.

If you don't want to or can't switch the project to shadow-cljs, you can maybe just build your project once with it. It will still require some work, but it may very well be worth it given that in my experience it's not a complicated procedure and manual digging is unpredictable.

Ok, cool. I will try this. Thank you!

Also, any tips / blog posts you recommend for switch from figwheel to shadow-cljs? Our setup for figwheel is quite standard and if shadow is better then we’d rather make the switch now.

if you can share your build config I can tell you how the shadow-cljs config would look

only hurdle when switching typically involves figuring out what to do about cljsjs packages if you use any. if its just the standard re-frame setup with react then thats no issue but if you use custom packages it involves a bit of switching

i use them in aws. much better than than jvm due to faster start time.

sup Krzysztof 😉 I ran some experiments and wrote about them: https://www.blog.nodrama.io/clojurescript-serverless-graphql/ Serverless + shadow-cljs with named exports for the lambda functions. Since then we have a Lambda running a Pathom API over websocket in production (clients connect to an AWS gateway, make requests and reply is done via a POST to the gateway endpoint).

Only custom component we had to add was a Redis instance to keep a mapping between the connected clients and authenticated users. If you go the vanilla route, and keep http request/response there's no need, and works pretty much as described in that simple example

thanks

How are you doing @U44NW9H34? 🙂

@U0E98NQG2 do you know how much faster?

Cold start time is tens of milliseconds for Node.js and several seconds for JVM.

GraalVM can be used to address the latter at the cost of reduced performance after warm up

From my tests, compiled Graal is still faster then Node

I don’t doubt that