AShedOfTools

thanks again!

Well, obviously, the correct choice is to use React Server and let us make all the decisions for you ;)

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

Aw shucks :) Thanks!

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.

Yep, this is the case

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.

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

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

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?