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 merged
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.
I completely agree. If you take a look at the closed prs with the label documentation (https://github.com/redfin/react-server/pulls?utf8=%E2%9C%93&...) I hope you get the sense that this is something that I'm thinking about a lot, and that if you look at the issues open with the same label (https://github.com/redfin/react-server/issues?q=is%3Aissue+i...), that it's something I'm working on actively. There are lots of ways to document a healthy project, from tests to tutorials to docs sites to good examples, and we've been working hard on markdown docs, tests and examples because they allow us to scale to having more contributors faster. Striking a balance between kinds of documentation is hard, and its even harder to strike a balance between the rest of the project's needs and documentation. This is a technology that we run in production, and so we have to make sure that it is fast and stable and reliable, and sometimes that means giving short-shrift to other priorities. I'm not trying to absolve us of any short-comings in our documentation -- we have a lot to do in the coming years to improve this project, and we need to spend time writing tutorials and user testing the on-boarding experience for new devs that want to start up their first React Server project -- but I do want you to understand where we're coming from when we say "contributions welcome." Its just pragmatic; we're working on it as hard and as fast as we can, its a priority I continue to focus on, and if you want it faster, the best way is to chip in.
OK, you definitely get it :) Love what you wrote below:
"No documentation survives its first encounter with a real newcomer."
I hope it didn't seem like I was accusing you of negligence – the docs you have are an awesome start, and I fully appreciate the difficulty of the problem. Best of luck with things going forward, looks like a really neat project.
All pages are rendered server-side by default. React Server sends each server-side rendered element as soon as it, and every element before it, are ready, up to a timeout, at which point it sends the late arrivals as they trail in. On the client side, React Server picks up where the server left off, to render client side code as the user interacts with the page.
Good opening for a question: what kind of servers were you using and how much traffic did it take to give them problems? (In other words, what's the performance of react like on the server?)
gigabo's account has been rate limited, but he wants to say:
"Well... we made it through the first hour or so of HN traffic on a single t2.medium instance in ec2 before we started seeing errors. We're now on three m4.larges with good head room. Not too bad, I think?
We meant to get cloud front set up before we got this sort of traffic, but glad to be surprised with an early bump. :)"
This is me saying this: I think we are thoroughly over-provisioned now for the load we are seeing, but we wanted to avoid any more hiccups while you all are trying to check it out.
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.
This is something that we're thinking about (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?
