@tony.kay No I haven't managed to fix it yet. I'll start working on getting the whole code uploaded to github. It works without it, but it bugs me because I don't understand why it doesn't work.

Hi here: looking at the development branch of Fulcro I get the impression that multiple remotes are supported now?

The last comments I found about this were stating that it was something still left to do, but I managed to find some tests in test/fulcro/client/application_spec.cljs that make me think otherwise

could someone confirm this? I implemented multi-network support in an ‘semi-old’ untangled version, and was planning to port it to fulcro

given that I found some hints indicating support for multi-networks I think I’ll can spend my time a bit better 🙂

@jwkoelewijn This is currently fully supported ^^ it is even added to the new defmutation macro. I don't use it myself though

cool

like the implementation as well btw, using different send-queues

I used 1 queue and split the requests later, think I like this approach better

@mitchelkuijpers thanks for the info

@jwkoelewijn multiple remotes have been supported for a long time.

the defmutation macros work with them, the load functions all accept a :remote parameter.

if you use the multimethod technique of mutation, you use the Om Next style (key by remote keyword)

each remote gets it’s own queue

I guess I’m just confirming what has already been said…should read more before typing 😉

With the help of @azeem it looks like Nashorn SSR is going to work. A little more to do, but we got a successful render from the compiled JS.

When I time it (once it is started) it can render a frame in about 8ms

and that one instance can be re-used with updated props to do general renders. I don’t know yet if the same instance is thread-safe…need to read more (e.g. can multiple SSRs be processed in parallel by one Nashorn instance. I suspect no)

Sounds like you can (and should) share Nashorn instances, but that you can supply a thread-specific binding environment. So, that makes it pretty good.

one-time overhead per thread at startup. So pooling SSR threads is trivial and efficient