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

131–140 of 143 posts

Re: React Server

#131

Post by pault »

AgentME wrote: post #104
pault wrote: post #86

Earlier quoted context omitted.

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!

See if others are using it, read the documentation, read the issues list, and/or read the source code. React-router-redux only has 216 lines of code! (Not counting tests, etc.)

Yes, this is basically my heuristic too. The part that's maddening is the low signal to noise ratio. It might take you six hours of googling to realize the library you need is called cthulhu-suspenders or something. You might have been able to write your own module in that time, then upload it to NPM, thus perpetuating the vicious cycle. :)

Re: React Server

#132

Post by crudbug »

gedy wrote: post #110

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

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 ?

Re: React Server

#133

Post by Bartkusa »

idbehold wrote: post #42

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…

Hey, I'm a dev at Redfin, and I've done something like this (with Gigabo's help). It's possible, but it's not well-supported yet.

My team owns one special-snowflake API in React-Server. We want the API to be reachable from the client via HTTP, but also want to execute the code directly during server-side rendering, with no HTTP call. It's your exact use-case.

In order to do that, we

1. Detect if the API is invoked server-side.

2. Tell Superagent* to tell the client "hey, if you want data for $API_URL, don't make an HTTP request; the response will come inline in the page's HTML response.

3. Invoke the API code directly.

4. When the API response is ready, serialize it, and tell Superagent to pass it to the client.

We don't do this kind of thing frequently, so we haven't built any graceful tooling for it.

* I _think_ this is Superagent: https://visionmedia.github.io/superagent/https://visionmedia.... Somehow, we use it in a way that notifies the client of what HTTP requests the server is performing on its behalf; not sure if that's stock Superagent or if we added some magic to it.

Re: React Server

#134

Post by coltranerequiem »

ergo14 wrote: post #118
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…

> I just spent the last two weeks setting up a boilerplate Two weeks for setting up boilerplate? Is that normal for react?

I'd say it's quite high. However, I'd echo that if one is coming at building a boilerplate while simultaneously wanting to learn and understand all of the concepts in the stack, I could see the boilerplate taking more than an hour or two.

(For example, I've seen some that implement some custom Redux middleware simply so that there's a conceptual reference right in the boilerplate as to how one would be done).

Are you thinking of getting into it? I heavily advise checking React out. I think it's fantastic!

Re: React Server

#135

Post by Bartkusa »

patates wrote: post #111
Bartkusa wrote: post #79

Earlier quoted context omitted.

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…

So the client downloads the data twice? First embedded in HTML and then via an additional request?

Good question. No, the data is downloaded only once.

The server tells the client what requests it's making on the client's behalf.

If the client's JS tries to make a request for a URL that's already in-progress, the client's React-Server code will skip the request and return a promise of the server's streamed response instead.

If the client's JS tries to make a request for something, and the server IS NOT already handling it, then the client will send out an HTTP request, and React-Server will step out of the way.

Re: React Server

#136

Post by kelvin0 »

orhanhenrik wrote: post #127
kelvin0 wrote: post #125

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

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…

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.

Re: React Server

#137

Post by civilian »

crucialfelix wrote: post #117
civilian wrote: post #101

Earlier quoted context omitted.

My heuristic is: 1. Google for a blog comparing them, and eliminate any candidates with major red flags 2. Go with the one that has the most stars on it's github repo.

So if there are no blog posts (1) then we all do 2 and then we suffer from first mover lock in.

IDK, I'm hoping that there are enough people who don't check stars and choose a repo simply because it was the first one they found or because they think it works better with their existing code or for other reasons. And honestly there are many times where I've been that person.

Re: React Server

#138

Post by davidalber »

davidalber wrote: post #61
hyperpape wrote: post #55

Earlier quoted context omitted.

I honestly don't know, what's the actual requests/second for that? I don't have a good feel for what HN traffic is like. From one post ( https://news.ycombinator.com/item?id=8107658 ), it seems like a few thousand hits/hour over a fraction of a day, but (1) there's a lot of variation, (2) it doesn't tell you the peak rate

We were seeing around 450 active users on the site at the peak. We currently have around 220 active users that are generating about two page views per second, peaking to six page views per second. That's about where we were when we scaled up from a single t2.medium instance.

Update on this: looking through metrics at the end of the day yesterday, we realized that the WebSocket-induced errors discussed in https://news.ycombinator.com/item?id=12271043 were having a much bigger operational impact than we initially thought. That's been dealt with and had a clear and immediate impact on the service health.

It would be nice to have another day of similarly high traffic to verify it, but I think most of our scaling up yesterday was to handle the WebSocket issue.

Re: React Server

#139

Post by ben_jones »

crucialfelix wrote: post #116
pault wrote: post #86

Earlier quoted context omitted.

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!

I want a website that rates packages in npm with more possibly useful heuristics: num dependencies (shallow, deep) total size of node_modules installed size (correct use of npmignore etc) code quality (McCabe, jslint, jshint) typescript/flow/ jsdoc string types etc test coverage frequency of releases documentation coverage documentation text analysis: pretentiousness, overly laconic, bro speak has a F-ing README so w…

Time since last commit, as well as average size and type of the last few commits would also be useful ensure meaningful features or bug fixes are probably being made.

Re: React Server

#140

Post by 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!
Post reply on HN