
React Server - uptown
https://react-server.io/
======
pault
This is interesting, especially since I just spent the last two weeks setting
up a boilerplate for a universal react/redux SPA on spec for a new client. I
enjoy the flexibility but the need to develop a deep working knowledge of
several independent libraries, transpilers, and build tool configuration files
(each of which has several competing options with their own way of doing
things) just to get to hello world is cost-prohibitive for most people, I'm
sure. At the same time, I'm hesitant to go "all in" on a stack that I haven't
heavily researched myself. If the developers are reading, can you go into some
details about how you handle routing and data stores? Are you using off the
shelf libraries or have you rolled your own?

~~~
ergo14
> I just spent the last two weeks setting up a boilerplate

Two weeks for setting up boilerplate? Is that normal for react?

~~~
pault
No, two weeks to take a deep dive into all the associated dependencies for
doing a universal SPA. Learning the details of webpack (which requires more
googling than reading the documentation), auditioning several flux
implementations (and there's relay if you want to go down the graphql rabbit
hole), routing libraries, and server page rendering configurations. There's no
single way to do this and everybody has their own boilerplate set up on
github. You can just get started with one of those, but if you don't
understand what's going on under the hood, you'll be up the creek when
something breaks and you're on the clock. I'm extremely uncomfortable working
with something professionally until I have a good understanding of the source
at least at the highest level of abstraction. Unfortunately this seems to be
the only way to survive in the NPM ecosystem, pulling down and spending an
hour reading the source of every variation of large dependency you might need.
Hence the two weeks. Not that it's such a bad way to do things, reading the
source. It's just a lot slower than people generally expect web development to
take these days.

------
android521
It doesn't seem like it is for beginners. Docs look at the author assumes
everything is self-obvious. Need better tutorials.

~~~
gigabo
Yes, definitely agree! We need better tutorials!

We need better docs in general. Contributions welcome! :D

~~~
kough
I'm totally on board with the "contributions welcome" response from open
source maintainers, but when it's the only response to questions about
documentation it's pretty off-putting. This is your project, how could you
expect a new contributor to add docs without your input? I get that good
documentation is hard, and takes time, but if you want your project to succeed
I think it's almost mandatory for you to write these docs (at least the
initial version!) yourself.

~~~
bphogan
I have to agree here. There's nobody better to explain how something really
works than the person who wrote it. The rest of us are just fumbling around
guessing.

As a dev and a creative person, I understand the desire to get something out
there. But documentation and tutorials aren't just something that's nice to
have. They are your marketing tool, your adoption driver, and the way to
create educated advocates for your project. They are as valuable to your
project's success as a splashy "getting started" web site is.

~~~
AShedOfTools
That process of you fumbling around and guessing is actually really
extraordinarily helpful. The things a contributor might think to do or to try,
and the things that a newcomer might think to do or to try, are completely
different. No documentation survives its first encounter with a real newcomer.
We can, and will, continue working on the onboarding experience, but we'll
need real users to roll up their sleeves and wade into it, and the first few
of them will have questions we didn't anticipate, and make assumptions we've
never considered, and try use cases we've never thought of. Creating good
documentation is something that newcomers and contributors need to collaborate
on.

~~~
bphogan
That process is the second part of the process, once clear, basic
documentation exists.

------
idbehold
How does it handle fetching data from a path on the same origin? For instance,
I only need to fetch('/api/users.json') on a certain page (/users). This means
that it can either be hydrated in the initial state when performing a full
page load of /users or needs to be fetched (using xhr/fetch) when navigating
to that page from another page on the site (which shouldn't require a full
page load).

So how exactly does the server perform that same fetch when attempting to
hydrate the full page without actually making an HTTP request against itself?

~~~
wwalser
The other responses seem to be answering how this would work once the
hydration is occurring on the client side. I understood the question to be
`Does the http request layer support doing API requests to routes which are on
the same webserver as react-server`.

There doesn't appear to be special handling for this use case. However, they
use SuperAgent
([https://github.com/visionmedia/superagent](https://github.com/visionmedia/superagent))
for http requests and I expect implementing the behavior that you're
describing is relatively easy with their plugin system. Specifically I'd bet
that plugins previously designed for testing could be used to accomplish your
goal (superagent-mock or superagent-mocker).

~~~
idbehold
What I'd like to be able to do is not incur an additional HTTP request against
my own server. Does SuperAgent have a way to avoid opening a new socket when
making a request against yourself?

~~~
wwalser
Yeah, I understood what you wanted. I may not have been clear in my line of
thinking. My understanding is that react-server does not support this.
However, I do not believe that it would be difficult to add support using the
testing plugins built for SuperAgent.

Imagine writing tests with mocked requests. Now apply that same logic to all
calls to fetch() on the server. Does that make sense?

So to the front end when fetch() is called, it actually makes the request. On
the server, when fetch() is called it hits a mock plugin which fetches
"mocked" data which is just fetching data from whatever local store you
normally would on your backend be it a JSON blob on the file system, a
database or an in memory cache.

editing to say that @exogen gave what may be a better explanation below:
[https://news.ycombinator.com/item?id=12273029](https://news.ycombinator.com/item?id=12273029)

~~~
chadscira
Another universal http option is : [https://github.com/matthew-
andrews/isomorphic-fetch](https://github.com/matthew-andrews/isomorphic-fetch)

~~~
wwalser
That's the opposite of what the question is asking for. They want to call
fetch('/api/foo/bar') but on the client it does an HTTP call while on the
server it recognizes that /api* is on the local system and therefore invoke
that _local_ route instead of doing an unnecessary http call.

That's what I'm apparently failing to describe how to accomplish :).

~~~
chadscira
Oh i see, I actually accomplished that a while back by monkey patching
superagent to use Hapi.js, and inject.

------
ken47
If this works as advertised, this may prove to be a very useful project, that
can replace numerous homegrown, half-complete implementations strewn about the
internet.

------
mattbroekhuis
I've been banging my head in this boilerplate for the last few weeks and it's
been very interesting.

[https://github.com/erikras/react-redux-universal-hot-
example](https://github.com/erikras/react-redux-universal-hot-example)

How does this compare to that?

~~~
bdefore
This boilerplate served as a base for a project I worked on, which I then
extracted out into an npm module for easier maintenance. You might find it
helpful: [https://github.com/bdefore/universal-
redux](https://github.com/bdefore/universal-redux)

That said, react-server attempts to solve the problem in more of a framework
fashion. I hope to look further into it.

------
fdim
I see a bunch of failed attempts in console to connect to slack websocket. Is
everything looking ok for you?

After blocking 2 iframes with adblocker I could finally inspect what was going
on :)

Anyway, I can definitely feel that is fast and seamless and worth to give a
deeper look! In the meantime, prefetching all the content in docs or source
views upon load generates quite a few requests and might explain your scaling
issues. Would you mind sharing statistics for number of users and hardware
behind ?

~~~
davidalber
That's a result of the Slack badge at the bottom of the page trying to use a
WebSocket to update its counts. We discovered getting WebSockets working
through ELB was not trivial and have decided instead to disable the real-time
updates to the badge. The changes have been made for that, but sadly, not
deployed in time for your visit.

Anyway, the errors in the console aren't impacting the behavior of the site
(the badge is falling back to polling to get updates, for instance). They are
ugly, though, and will be gone in a future deployment.

~~~
nacs
> getting WebSockets working through ELB was not trivial

Amazon announced the Application Load Balancer today which supports
Websockets:

[https://aws.amazon.com/blogs/aws/new-aws-application-load-
ba...](https://aws.amazon.com/blogs/aws/new-aws-application-load-balancer/)

~~~
davidalber
Oh, that's timely! I will check that out.

Thanks for the heads up!

------
underwater
Based on the documentation and the design principles this seems like a really
promising framework.

The data hydration, incremental HTML delivery and incremental code loading are
really, really important for creating web apps that aren't load time hogs.
Great to see that they were unopinionated about data fetching, too. That's one
of the things that has made it difficult to drop Relay into existing
applications.

Is this used in production? Are there any performance numbers that you can
share.

~~~
Bartkusa
Redfin uses it in production. [https://www.redfin.com/blog/2016/05/announcing-
react-server....](https://www.redfin.com/blog/2016/05/announcing-react-
server.html)

"We’ve been using it here at Redfin in production for over a year and it
serves the three highest traffic pages on the site. We’re serving 1 billion
requests a month from our React Server instance; hundreds of requests per
second during peak hours."

------
hughbetcha
Would be useful if this project explained the difference between React and
ReactServer. It seems they are as similar as Java and Javascript.

Instead of the render() method in React to output JSX, it appears that
ReactServer uses getElements() for a similar purpose. So the entire model and
object lifecycle is probably different as well?

~~~
btown
React Server uses React; the page that has getElements is sort of a meta-
React-component that has other specified behavior, as well as returning a
React component to be mounted. So it renders the first page you visit on the
server (for fast loading), then all subsequent pages are rendered on the
client.

~~~
hughbetcha
Thanks. That should be the very first line in the documentation.

~~~
tbrock
Also should probably mention it's not worth the trouble.

------
gedy
Humorously this looks a bit like Apache Wicket, a Java-based client/server UI
framework which has been around for about 10 years:
[https://wicket.apache.org](https://wicket.apache.org)

~~~
crudbug
I was thinking about the same thing + JSF.

This might be the evolution of it, where the page routing is residing on
client with server side state ?

------
sergeym
there is a wealth of information in their documentation about making
performant rendering on the server and client [https://react-
server.io/docs/intro/why-react-server](https://react-server.io/docs/intro/why-
react-server) I found it super interesting.

------
kelvin0
I just recently made the switch into the Web Dev world (coming from
C++/Python, desktop world). Since I knew of Django, I've started using it as
the 'Backend/Server' part of my Web app dev stack. Basically using Django to
render minimal React/HTML/JS/CSS to bootstrap my single page Web app.
Wondering, what advantage would I have would I get from using react-server
instead of Django (aside from using JS across the board)?

Would appreciate feedback!

~~~
orhanhenrik
I have not looked at how this framework does it, but I have built a nodejs
server that does similar things myself. Some advantages:

\- The server can render the full page in html for the client, which means the
website is viewable even without js (or before js has loaded, for example on
slow network)

\- The server can preload all data the client needs. The webapp might need to
fetch data from 3 API endpoints. Having a server do this and pass the results
to the client on load is much more efficient. If the client (browser) loads
it, the following happens: html loaded -> js loaded -> start calling APIs. If
the server does it, the client instantly has access to this data.

Rendering all the html can be a bit heavy on a weak server though, but you get
the advantage that you quickly notice bottlenecks in your rendering. You can
also implement some caching on your server to make it faster.

~~~
kelvin0
I appreciate your answer, which seems to apply to the general concept of
server rendering. But Django can also do all what you mention. My question
was: what can React-Server do that Django could not? I hope this clarifies my
original interrogation.

~~~
orhanhenrik
The difference is that a "react server" can actually render the dynamic react
content. I don't know of a way to do this in django, unless you are able to
run javascript code somehow. If you do this, you are kind of making your
django app a "react server" though, since it renders all of your react
components.

What usually happens in a react app is that the server delivers static content
(html, js, css). When everything is loaded, react starts working on the
browser and renders / fetches data.

If the server that delivers the html doesn't just deliver a static page, but
actually fetches data and renders it first, the browser can instantly display
the data and react is smart enough to know that it doesn't even need to do a
new render, because the components are already rendered to html.

------
mxuribe
Mad props to a crew from the real estate industry who just pumped out cool
tech for universal utility! Kudos to the folks from Redfin!

------
silasb
The company that I was consulting for tried to get Spring and React to play
nice via Nashorn, but ended up scraping the idea 6 weeks in because of
performance issues and not enough developers knowing the stack. Nashorn was
missing a lot of essentials to make this easy out of the box. So looking at
this is a breath of fresh air.

------
mbreedlove
_One of the great things about React is its support for server-side rendering_

Cool, I never knew that.

------
crudbug
A simple model/flow of rendering pipeline would be helpful here based upon
routing logic.

As I understand, Pages are composed of Components, Components provide HTML
sections. HTML sections are loaded incrementally.

------
encoderer
An alternative here is Hypernova by Airbnb.

~~~
acid__
Correct me if I'm mistaken, but Hypernova has the javascript rendering siloed
as a separate service. Which can be really useful in some cases (especially if
you want to render React components from a Rails app).

But if you want it all in one place (reduced complexity and overhead), React
Server looks pretty promising.

~~~
wwalser
React-server seems to roll in additional opinions (sane default) about how to
go about creating a high performance server-side rendered universal
application.

My evaluation is that react-server looks promising for prototyping and first
versions of an application where being monolith is a reasonable approach.
Hypernova seems like a good fit for organizations that are already building
microservices and want to eek some additional performance out of the initial
render of their SPAs.

------
zinssmeister
React Server looks fantastic!

For some reason this week I stumbled over many great React.js articles, so I
started a collection here [http://deepreact.com](http://deepreact.com) mostly
to save&share things with friends, since a lot of us are getting deeper into
React now.

------
bsimpson
I'd really love to see a demo of what they mean by "seamless transitions."

~~~
gigabo
The website itself is meant to serve as a demo. :)

When you land on the site the first page is rendered by the server. Then the
client controller wakes up and subsequent page views ask the server for data,
but render in the browser. That's what we mean by "seamless transitions".

~~~
nostrademons
"seamless transitions" in the web design world is often taken to mean
"transitions" in the sense of CSS animations, i.e. instead of hard page
refreshes elements smoothly morph into their positions in the next page state.
See eg. Google's Material Design or Apple's iPhone UI. This is a big, largely-
unsolved problem in HTML5, at least in making them pervasive, performant on
mobile, and easy for developers. Advertising this may lead to some unwarranted
excitement and subsequent disappointment, since the website doesn't really
have transitions at all of this sort.

~~~
gigabo
Oh, hadn't considered that interpretation. Our full project description on
GitHub is "React framework with server render for blazing fast page load and
seamless transitions between pages in the browser". The tag line on the
website is shortened from that. I think the full version is a little less
ambiguous, but it's a little too wordy in the context of the site.

Will have to think about a better tag line... Thanks!

~~~
bsimpson
I share nostrademons's interpretation. I'd expect the first page rendered on
the server and the rest rendered on the client in any isomorphic framework.
When I hear "transitions", I expect elements morphing between assets, ala
neon-animated-pages:

[https://elements.polymer-project.org/elements/neon-
animation...](https://elements.polymer-project.org/elements/neon-
animation?view=demo:demo/index.html&active=neon-animated-pages)

I think your value proposition is something like: "Renders on the server or
the client - whichever's fastest for that request"

------
Swennemans
Are there any numbers comparing pre-rendered React versus React communicating
with a JSON Api? It seems to put a lot more stress on the server which can
neglect the (theoritical) speed improvements

~~~
skrebbel
Not sure, but the time cost is the latency of loading an almost-empty
index.html, loading and parsing your app, _then_ it starts running and
hopefully fast doing some API requests and then it's off and good to go.
Subsequent JSON-API-requests-and-then-rerenders should be pretty fast indeed,
but those aren't the point :)

You want to server-side render React apps so that while all that happens, the
app already works.

------
tboyd47
Looks fascinating, I will definitely be watching this project in the coming
year.

Just curious, if it's been successfully running in production for over a year,
why is it only being used to serve three pages?

~~~
Bartkusa
That statistic is out of date; Redfin has built dozens of pages on React-
Server by this point.

(Also, just to be clear, we treat _all_ home details pages as a single logical
page.)

------
Amplifix
Looks very interesting, will give this a spin. I've been skimming the docs,
but I assume you'll still have to install redux to handle state etc.

------
deegles
Could react-server build in support for AMP?
[https://www.ampproject.org/](https://www.ampproject.org/)

------
antar
You have a misspelling in your homepage: née not neé.

~~~
nattofriends
Merged at [https://github.com/redfin/react-
server/pull/527](https://github.com/redfin/react-server/pull/527)

~~~
AShedOfTools
thanks again!

------
oelmekki
It even includes a Dockerfile and a docker-compose.yml file to get quickly
started, that's cool :)

------
krebby
This looks cool. Any way to make it easily work with Relay?

~~~
AShedOfTools
This is something that we're thinking about ([https://github.com/redfin/react-
server/issues/190](https://github.com/redfin/react-server/issues/190)), but
that we just don't have an answer for right now. React Server was built with
running two servers in mind, one for your api and React Server as your front-
end. I haven't used Relay much, but I think you could run your Relay server as
the api server, then make the request from React Server with ReactServerAgent
and it should work?

------
pseudointellect
> "Blazing fast page load and seamless transitions."

Click on Get Started and no seamless transition, but rather a very abrupt page
load.

------
kra34
every time somebody makes a new react / angular derivative a unicorn loses
it's horn.

------
rando832
wtf is neé?

~~~
AShedOfTools
Its the French word for "born." Its often used for maiden names. In this case,
we mean "we called it Triton before we called it React Server," which was more
important to understand before [https://github.com/redfin/react-
server/pull/40](https://github.com/redfin/react-server/pull/40) merged

------
charford
Getting random 504 timeout errors on this site. Is this hosted using react-
server?

~~~
sheeshkebab
It's a curious project but maybe not "Blazing fast page load and seamless
transitions."

~~~
nilliams
Well page loads are fast, and clicking links within the docs section does feel
super fast, but I agree use of the word 'transitions' is confusing (which the
author has now addressed elsewhere).

------
rajangdavis
Getting some weird issues, can only get to the docs by clicking on the link to
the docs and then refreshing the page a couple of times...

~~~
AShedOfTools
We had some scaling issues, and have added a couple more hosts to the pool.
The errors should be resolved now

