Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React Server

react-server.io

Post reply on HN
Print view View original

91–100 of 143 posts

Re: React Server

#91

Post by hughbetcha »

Bartkusa wrote: post #79
hughbetcha wrote: post #75

Earlier quoted context omitted.

Is each page pushed to the browser in a static fashion? Or does ReactServer implement minimal client DOM updates in a similar manner to React?

Each page is split into sections. Each section may wait for async data and API responses. When all the data arrives, the section is rendered as an HTML string. The server streams each section's static HTML to the client as soon as it's ready, and after all prior sections are streamed. The server also streams the async data to the browser. This avoids the latency of the client downloading some HTML, then downloading s…

> Each page is split into sections. Each section may wait for async data and API responses. When all the data arrives, the section is rendered as an HTML string.

Where are these waiting sections? On the browser client or the server?

Is the React code that is to be rendered on the browser served up automatically by ReactServer?

I'm sure it's a wonderful framework, but a diagram is really needed to understand any of this.

Re: React Server

#92

Post by davidalber »

nacs wrote: post #76
davidalber wrote: post #37

Earlier quoted context omitted.

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 badg…

> 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...

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

Thanks for the heads up!

Re: React Server

#93

Post by 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.

Re: React Server

#94

Post by [deleted] »

pault wrote: post #5

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 c…

[deleted]

Re: React Server

#95

Post by shriek »

idbehold wrote: post #63
wwalser wrote: post #48

Earlier quoted context omitted.

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 ) for http requests and…

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?

I'd like to know the answer to this too. What I've thought so far is that I just call the function that makes db calls or other operation on the server side but this is clearly not the way do in client side if the app was to be universal.

Re: React Server

#96

Post by wwalser »

pault wrote: post #86
ucarion wrote: post #85

Earlier quoted context omitted.

If you're gonna use React Router and Redux, you should also check out react-router-redux: https://github.com/reactjs/react-router-redux

This is exactly what I'm talking about though, how many different libraries are there for routing alone? How can anyone make a reasonably informed choice between them? It's madness!

Make a decision and run with it. Be confident enough in yourself or your team that you can pivot off that decision if it ends up being the wrong one. Often before you have enough information to make the decision at a level of precision that makes you completely comfortable.

I'm coming up on a decade in web application development and I feel like this is one of the most critical skills. It also took me an embarrassingly long time to develop. I think engineering, in allowing transparency downward into each level of the "stack", engenders the opposite in it's practitioners.

Re: React Server

#97

Post by tbrock »

hughbetcha wrote: post #78
btown wrote: post #77

Earlier quoted context omitted.

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.

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

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

Re: React Server

#98

Post by wwalser »

idbehold wrote: post #63
wwalser wrote: post #48

Earlier quoted context omitted.

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 ) for http requests and…

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?

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

Re: React Server

#99

Post by wwalser »

acid__ wrote: post #52
encoderer wrote: post #47

An alternative here is Hypernova by Airbnb.

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.

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.

Re: React Server

#100

Post by exogen »

shriek wrote: post #95
idbehold wrote: post #63

Earlier quoted context omitted.

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?

I'd like to know the answer to this too. What I've thought so far is that I just call the function that makes db calls or other operation on the server side but this is clearly not the way do in client side if the app was to be universal.

In my experience [1], you'd probably just use an if statement that does something different when you're on the server. That's totally fine and is still a universal app; universal apps don't have to take every exact same code path on the client and server, they just have to run the same code base.

In React, people typically use the ExecutionEnvironment module [2] for this:

    if (ExecutionEnvironment.canUseDOM) {
      // make client side request
    } else {
      // make direct db request
    }
...but you could also just do some simpler check, like see if `window` exists, or make up your own `IS_SERVER` global, etc.

Next you'll wonder: won't that still ship the server-side code to the browser, even if it's not run, and pull in any server-only modules you're importing, e.g. database access stuff? No: you'd fix this with (for example) webpack's `DefinePlugin` [3], telling it that `ExecutionEnvironment.canUseDOM` should always be `true` wherever it occurs in your client-side JS bundle, and dead code elimination will then rip out those server-only `else` branches before that code gets shipped to the browser.

Or a similar setup, like wwalser hinted at: write 2 versions of your 'request' module: one for the client, and one for the server. Tell webpack it should point to the client-side one when you generate your client JS bundle. People use webpack because it lets you do all kinds of overrides like this.

[1]: I work at Formidable, we do a ton of React for big companies.

[2]: https://github.com/JedWatson/exenv

[3]: https://webpack.github.io/docs/list-of-plugins.html#definepl...

Post reply on HN