I'm building something with React + Relay + Sangria and it's working out well so far. There's a sample sangria project showing how to use it on akka-http, and if you write a pure web app like this, you could serve the javascript client from somewhere dumb like S3. Plus with this stack you can plug in react-native apps as well once your server is written.
We did a bunch of experiments with running React in a web worker. Maybe we should revive them. Because it's React, it ends up being easy and is basically the same setup (serialized events etc) as what React Native does.
Interesting. I'm currently doing some work to enable React SSR in the Micronaut framework, which might be useful for some people working on the JVM. There's also https://elide.dev which is a polyglot server framework that also supports SSR.
I didn't fully understand what WASM is doing here though. Web components whether React or otherwise are written in Javascript or something that compiles to it, so you need a server side JS engine (Elide/my Micronaut work use GraalJS). Is WASM just being used here as an alternative to providing a .so/.dll file?
None require React specifically, of course. I’m only referring to the dichotomy between server-rendered apps and apps with significant client-side interactivity.
Yeah the views are all just react.js. The JS for the webapp is dumb so can be served by S3 (i.e. no server-side rendering). It's basically REST++ - a pure server that just serves data (sangria/graphQL server) and a decoupled client (which in my case happens to be a react web app for now).
The whole thing is a solved problem. You can easily render React apps on the server and send HTML down the wire, then lazy load the rest of the JS. Author could have installed next.js and called it a day.
If you put your app logic in something like Redux it'll work on server-side rendering, client-side rendering, and can be included in react-native down the line.
In the time the author re-wrote his app, I could have gotten the same benefits with SSR and ported it to react native. But yeah, javascript bad REEEE
We've been tinkering with the same ideas recently, thanks for publishing a great article. I'm excited about the idea of creating a Node based "frontend server" that produces optimized view models for React, using our REST endpoints as building blocks. When Relay was announced, the idea of giving the client some control over those model shapes was really interesting to me as well. Excited to see where all this goes over the next several months.
I just have to mention Mithril.js (https://mithril.js.org/) here as an alternative to React. It has built-in routing and XHR, and I think it is fairly easy to learn. Combined with the (optional) streams library, it makes developing web UIs extremely pleasant. Like React, it is also based on virtual DOM diffing.
As a very minor point, I think its surface API looks more JavaScriptesque. For example, the life cycle event componentDidMount in React is called oncreate in Mithril.js. Doesn't matter much, but looks better to me.
We do exactly this with a React app served from S3. Just think of it as a (mostly) dumb webserver. It's not gonna do any compute, or server side rendering/includes.
If you need server side compute, lambda and API GW is the way to go.
reply