4 ms·

The prospect of doing React server rendering within the JVM, rather than in node, used to be a lot more attractive to me before I switched to containerizing my

The prospect of doing React server rendering within the JVM, rather than in node, used to be a lot more attractive to me before I switched to containerizing my apps, specifically with kubernetes. Now, the benefit of using the best tool for the job, and separating concerns (the API and the React server renderer can be deployed, logged & scaled independently) far outweighs the overhead of managing and connecting several different runtimes, because that's trivial with k8s. The only slight advantage I can think of is loading data on server renders 'in-process' and not having to go via http, though I emphasise slight as this is certainly not a bottleneck and not something I worry about at all frankly. I think this is cool, and I get that Clojure + Clojurescript add another reason to pair these things together and perhaps this is quite a Clojure-specific thing, but just wondering if anyone would pick this over running separate JVM + node services in k8s or similar (assuming that's an option)?

kommen 7y ago
Hi, I'm the author of the post. At Nextjournal, it won't stop with server side rendering. For example we're using ProseMirror as the rich text editor in the browser. For real-time collaboration on notebooks, we want to use ProseMirrors out of the box support for it: http://prosemirror.net/docs/guide/#collab http://prosemirror.net/docs/guide/#collab This means our server has to provide the "central authority". This leaves us again with the choice of: 1) expose this central authority in a nodejs service via http to our Clojure/JVM app (which manages also the websocket connections and database persistence) 2) rewrite the central authority and applying the transformation functions in Clojure/Java and maintain compatibility with the Javascript implementation 3) leverage the polyglot abilities from GraalVM to just call ProseMirror's transformation functions from our Clojure code Here, 3) seems to be the obvious choice, as throughput is much higher than for occasional server side rendering and the http overhead for the nodejs-service approach would be a deal breaker.
- davnicwil 7y ago
  Ah, ok, really interesting thanks. With this type of deep integration & communication needed between the two, I can see why running everything in the same JVM is a better solution.

kommen 7y ago

Hi, I'm the author of the post. At Nextjournal, it won't stop with server side rendering. For example we're using ProseMirror as the rich text editor in the browser. For real-time collaboration on notebooks, we want to use ProseMirrors out of the box support for it: http://prosemirror.net/docs/guide/#collab http://prosemirror.net/docs/guide/#collab This means our server has to provide the "central authority". This leaves us again with the choice of: 1) expose this central authority in a nodejs service via http to our Clojure/JVM app (which manages also the websocket connections and database persistence) 2) rewrite the central authority and applying the transformation functions in Clojure/Java and maintain compatibility with the Javascript implementation 3) leverage the polyglot abilities from GraalVM to just call ProseMirror's transformation functions from our Clojure code Here, 3) seems to be the obvious choice, as throughput is much higher than for occasional server side rendering and the http overhead for the nodejs-service approach would be a deal breaker.

davnicwil 7y ago
Ah, ok, really interesting thanks. With this type of deep integration & communication needed between the two, I can see why running everything in the same JVM is a better solution.