Clojure: React Server Side Rendering with GraalVM

5 years ago

source link: https://www.tuicool.com/articles/mMFfau
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

file to bring in some minimal dependencies to build a small ClojureScript app which can be used for server side rendering."],"8408b1e4-8585-433b-abf1-85fe5ef7052c",["^ ","^19","(def result (execute-fn context \"my.app.html\" \"Polyglot Graal \uD83C\uDF08\"))\n(.asString result)","^1K",["^P",[]],"^S",["^ "],"^[","clojure","^10","8408b1e4-8585-433b-abf1-85fe5ef7052c","^11","~uaf1a2cf3-0b1a-4cfb-b949-6f687f700ec2","^1L",["^1L","0f79e753-ff02-4520-abcc-ba908e93881d"],"^12","code","^1M",["^ ","~_",["^ ","^1N",["^ ","^R","{\"~#'\":\"

Hello Polyglot Graal \\uD83C\\uDF08!

\"}"]]],"^13",null,"^1O",943],"ff4f3e6e-9df4-4dbe-b03b-07d87c577ac7",["^ ","^10","ff4f3e6e-9df4-4dbe-b03b-07d87c577ac7","^12","paragraph","^19","However, we want to use this html function from within the JVM which runs our Clojure app. For this we can leverageGraalVM's polyglot abilities to load the JavaScript artifact from the ClojureScript app into the Clojure JVM and directly call the function with almost no overhead."],"79482a88-cb00-4190-b8cf-2c95d58474db",["^ ","^19","java -version","^1K",["^P",[]],"^S",["^ ","^T",3],"^[","bash","^10","79482a88-cb00-4190-b8cf-2c95d58474db","^11","~ud5f5291f-8863-45b4-aa71-5cb3abeb64c5","^1L",["^1L","0f79e753-ff02-4520-abcc-ba908e93881d"],"^12","code","^1M",["^ "],"^13",null,"^1O",931],"83bf04a0-79bd-45aa-a25f-01488d66e85b",["^ ","^10","83bf04a0-79bd-45aa-a25f-01488d66e85b","^12","paragraph","^19","The execute-fn helper makes it convenient to call our Javascript functions and provide them params directly from Clojure."],"738d9c33-a84d-4857-9e98-19ba08b8ec53",["^ ","^10","738d9c33-a84d-4857-9e98-19ba08b8ec53","^12","paragraph","^19","However, recently we switched our production JVM to GraalVM

, which opened a new possibility since it comes with GraalJS, a JavaScript engine which aims to compete with today's faster JavaScript engines like V8 and JavaScriptCore on performance. It lets us embed the ClojureScript app into our Clojure app so it can perform the rendering in-process in the JVM. "],"28310f37-73fd-491d-8efb-ce554af10e57",["^ ","^10","28310f37-73fd-491d-8efb-ce554af10e57","^12","paragraph","^19","While we already happy with our current setup, there a few things are still on our todo list:"]],"~:transclusions",["~#cmap",[["^ ","^15","~u5b45eb52-bad4-413d-9d7f-b2b573a25322","^17","0ae15688-6f6a-40e2-a4fa-52d81371f733","^16","~u5d1c83b8-6eff-4edf-b75f-3ddd3471f3a4"],["^ ","^O",["^P",[["^ ","^Q","GRAAL_VERSION","^R","19.1.0"],["^ ","^Q","PATH","^R","/usr/local/graalvm/bin:/usr/local/nvidia/bin:/usr/local/cuda/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"],["^ ","^Q","GRAAL_DIR","^R","/usr/local/graalvm"],["^ ","^Q","NVIDIA_VISIBLE_DEVICES","^R","void"],["^ ","^Q","NVIDIA_DRIVER_CAPABILITIES","^R","all"],["^ ","^Q","NEXTJOURNAL_MOUNT_CUDA","^R","9.2-cudnn7-devel-ubuntu18.04"],["^ ","^Q","BASH_ENV","^R","/.bash_profile"],["^ ","^Q","LC_ALL","^R","en_US.UTF-8"],["^ ","^Q","LANGUAGE","^R","en_US.en"],["^ ","^Q","LANG","^R","en_US.UTF-8"]]],"^;","~m1562149816073","~:transclusion",["^ ","^15","~u5b45eb52-bad4-413d-9d7f-b2b573a25322","^16","~u5d1c83b8-6eff-4edf-b75f-3ddd3471f3a4","^17","0ae15688-6f6a-40e2-a4fa-52d81371f733"],"^1K",["^P",[]],"^Q","Clojure","~:docker/environment-image","docker.nextjournal.com/environment@sha256:8171ea23e969817f4f299ade8174729db72e57f3c5cfff6d436a2907dcb592fd","^S",["^ ","^T",1],"^U","^V","~:environment?",true,"^[","bash","^10","0ae15688-6f6a-40e2-a4fa-52d81371f733","^11","~uf7c3e6e0-9d7b-11e9-9a45-a4401e29db29","^12","runtime","~:changed?",false,"^13",null,"^14",["^14",["^ ","^15","~u02977b4a-ce26-4025-9a73-cbbae2521a70","^16","~u5d1c6441-5c77-4143-82c0-3ee3a92ac311","^17","4641de4c-67e7-4689-90f8-f22f1092707a"]],"~:runtime/environment-variables",[["^ ","^Q","CLOJURE_VERSION","^R","1.10.1.447"]],"~:diff",""]]]],"^10",17592189791941,"^9","~u02b25a80-2123-4f34-9c7b-ce8083b7c1ed"],"~:show?",true,"~:change-id","CW4Fq7zwdDkYD4c63d4nz4","^1A","published","~:article-collection",["^P",[]],"~:html","

React Server Side Rendering with GraalVM for Clojure

Usecase at Nextjournal

At Nextjournal, we perform server side rendering of notebooks to provide better user experience, especially for published notebooks. A visitor instantly sees the content of a notebook while the client side app loads. However, we do use a few Javascript-only dependencies like CodeMirror and ProseMirror, which prevents us from doing this server side rendering directly in Clojure on the JVM. Until now, we used a separate nodejs version of our browser app to perform this task. This necessitated a whole lot of code to expose ClojureScript app via an HTTP interface to the Clojure app as they were running in different VMs.

However, recently we switched our production JVM toGraalVM, which opened a new possibility since it comes with GraalJS, a JavaScript engine which aims to compete with today's faster JavaScript engines like V8 and JavaScriptCore on performance. It lets us embed the ClojureScript app into our Clojure app so it can perform the rendering in-process in the JVM.

Let me walk you through how this works.

We start with Nextjournal's default Clojure environment, which already uses GraalVM.

java
 -version

0.9s

Bash in Clojure

Clojure

\n\n\n

We use this deps.edn file to bring in some minimal dependencies to build a small ClojureScript app which can be used for server side rendering.

{:deps\n
 {org.clojure/clojure {:mvn/version "1.10.0"}\n
  reagent {:mvn/version "0.8.1"}\n
  org.clojure/clojurescript {:git/url "https://github.com/nextjournal/clojurescript"\n
                             :sha "da9166015f6a28b2c18fa7706e457901d02a5d81"}}\n
  }

deps.edn

Clojure

The sha key points to a ClojureScript version with some small adaptations to make work better with GraalJS.

Let's create a simple ClojureScript app using reagent . This will be used for server side rendering.

(ns my.app\n
  (:require\n
    [reagent.core :as reagent]\n
    [reagent.dom.server :as dom-server]))\n
\n(defn hello-component [name]\n
  [:div (str "Hello " name "!")])\n
\n(defn html [name]\n
  (dom-server/render-to-string [hello-component name]))

app.cljs

ClojureScript

Compile it using ClojureScript's command line interface.

clj
 -m 
cljs
.main
 -t 
graaljs
 -c 
my
.app

51.6s

Bash in Clojure

Clojure

As a first test to see if our ClojureScript app actually works in GraalJS, we can use Graal's standalone js command line operation to load our app and produce a call to our html function.

js
 --jvm -f 
out
/main
.js
 -e "console.log(my.app.html('GraalJS \uD83D\uDC4B'))"

13.6s

Bash in Clojure

Clojure

However, we want to use this html function from within the JVM which runs our Clojure app. For this we can leverageGraalVM's polyglot abilities to load the JavaScript artifact from the ClojureScript app into the Clojure JVM and directly call the function with almost no overhead.

(import '(org.graalvm.polyglot Context Source))\n
\n(def context-builder\n
  (doto (Context/newBuilder (into-array String ["js"]))\n
     (.option "js.timer-resolution" "1")\n
     (.option "js.java-package-globals" "false")\n
     (.out System/out)\n
     (.err System/err)\n
     (.allowAllAccess true)\n
     (.allowNativeAccess true)))\n
\n(def context (.build context-builder))

0.8s

Clojure

user/context

We use the Context/newBuilder polyglot API to create a Graal execution context and specifically only allow JavaScript execution. The js.java-package-globals is needed to prevent namespace collisions between Java packages and some ClojureScript namespaces in our codebase.

(defn execute-fn [context fn & args]\n
  (let [fn-ref (.eval context "js" fn)\n
        args (into-array Object args)]\n
    (assert (.canExecute fn-ref) (str "cannot execute " fn))\n
    (.execute fn-ref args)))

0.1s

Clojure

user/execute-fn

The execute-fn helper makes it convenient to call our Javascript functions and provide them params directly from Clojure.

Before we can actually call our Javascript functions, we first need to load our little demo app into the context we created before.

(def app-js (clojure.java.io/file "out/main.js"))\n(def app-source (.build (Source/newBuilder "js" app-js)))\n(.eval context app-source)

10.6s

Clojure

Vector (4) [ org.graalvm.polyglot.Value , "0x25b2672a" , "null" , Map ]

We utilize Graal's Source class to load the JavaScript artifact and evaluate it in the execution context to make the our html function available.

Now everything is coming together and we can perform server side rendering with our React ClojureScript app directly from Clojure.

(def result (execute-fn context "my.app.html" "Polyglot Graal \uD83C\uDF08"))\n(.asString result)

0.9s

Clojure

"<div data-reactroot="">Hello Polyglot Graal \uD83C\uDF08!</div>"

In Nextjournal's case, we need to pass data of a notebook to the ClojureScript app. Rather than passing a string like \"Polyglot Graal \uD83C\uDF08\" to the html function for rendering, we actually pass a transit -encoded notebook. This is the same data we pass to the browser for client side rendering.

Performance

GraalJS is currently optimized for long running processes, and for some workloads it is still slower than V8 or JavaScriptCore. Our use case should fit well as we reuse the Context over and over and execution times get quite a bit faster after the first few requests. We also have less overhead for server side rendering now, because we can invoke Javascript functions directly without needing a complete http stack. In many cases this is faster than our old nodejs rendering process.

These are 5 measurements of server-side rendering calls in milliseconds after a warm-up phase of 1000 render calls.

0 items

You can see that for small notebooks GraalVM actually performs better because we don't have to go through a whole http stack. For large notebooks, it's in the same ballpark (~30% slower) and we're hopeful this will further improve in the future.

Where to go from here

While we already happy with our current setup, there a few things are still on our todo list:

Makefigwheel live code reloading work with the GraalJS so ClojureScript code changes are immediately reflected in the server side rendering in our development environment.
Finish up our ClojureScript patches to improve support for GraalJS and get them applied upstream.
Use code sharing for GraalJS so that the multiple render threads can share the AST to reduce the warmup time for optimal performance.

Upstream Issues

We ran into a number of issues and limitations, which we reported and were either resolved or worked around. We'll continue to work with the GraalVM and ClojureScript teams to get those issues resolved.

GraalJS regex engine bug affecting lookarounds: GraalJS issue #162 (the fix shipped already in Graal 19.1.0)
GraalJS namespace collisions of Java package globals with ClojureScript namespaces: GraalJS issue #164 and ClojureScript CLJS-3087
Optimized :graaljs builds from ClojureScript are missing the bootstrap code: ClojureScript CLJS-3113
Make main files produced by ClojureScript for :graaljs targets work without java package globals: ClojureScript CLJS-3089

"]]

Recommend

About Joyk

Aggregate valuable and interesting links.
Joyk means Joy of geeK

Clojure: React Server Side Rendering with GraalVM

Recommend

从成长角度看，前端工程师应该去大公司还是小公司？

企业安全体系架构分析：开发安全架构之可用性架构

不要引用「没有免费的午餐定理」了

从0开始学大数据-Hive基础篇

作为一名JS开发人员，是什么使我夜不能寐[每日前端夜话0x91]

万字长文 | 漫谈libco协程设计及实现

Intro Guide to Dockerfile Best Practices

用 skynet 实现 unity 的 cache server

引介 | Layer 2 方案概览：从状态通道到 Roll Up

C# 8: Static Local Functions and Using Declarations

About Joyk