I've kept half an eye on Redwood since the early days, but i'll have to give it a proper look.
My original understanding was that it was a static site generator, but this doesn't actually seem to be the case? In which case, i'm curious how the request waterfall problem is mitigated, given that the data loading is cell-oriented rather than interaction-oriented. My background with GraphQL comes from using Relay for 6+ years, so I'm used to there only being one query per interaction (pageview, click etc); whereas from the looks of Redwood, the nature of cells seems to indicate there can be multiple queries, potentially cascading ones involved in building a single screen.
You are correct, if you're not careful with your data fetching you can get into a waterfall situation. This is something we're keen to address in coming versions. Because we can get in the middle of your data fetching flow if you use cells, we should be able to do some optimizations without you having to do anything extra!
My original understanding was that it was a static site generator, but this doesn't actually seem to be the case? In which case, i'm curious how the request waterfall problem is mitigated, given that the data loading is cell-oriented rather than interaction-oriented. My background with GraphQL comes from using Relay for 6+ years, so I'm used to there only being one query per interaction (pageview, click etc); whereas from the looks of Redwood, the nature of cells seems to indicate there can be multiple queries, potentially cascading ones involved in building a single screen.