I understand the GraphQL has fallen out of favour somewhat, but wasn’t it intended to solve for this?
It can't fall out of favor if it was never really in favor to begin with. GraphQL was a quite brief hype then a big technical debt.
Progressive JSON
31–40 of 244 posts
Re: Progressive JSON
#32I understand the GraphQL has fallen out of favour somewhat, but wasn’t it intended to solve for this?
From what I recall, GraphQL has a feature that's similar (@defer) but I'm not familiar enough to compare them. RSC was definitely inspired by GraphQL among other things.
Re: Progressive JSON
#33If it has to be mangled to such an extent to do this, then it seems reasonable to assume JSON is the wrong format for the task. Better to rethink it from scratch instead of trying to put a square peg in a round hog.
I'm being a bit coy about it but the article aims to describe key ideas in the RSC wire protocol, which is an implementation detail of React and isn't actually beholden to JSON itself. JSON is just a nice starting point to motivate it. However, I think reusing JSON for object notation kind of makes sense (and allows native JSON.parse calls for large objects).
Re: Progressive JSON
#34> We can try to improve this by implementing a streaming JSON parser.
In .NET land, Utf8JsonReader is essentially this idea. You can parse up until you have everything you need and then bail on the stream.
https://learn.microsoft.com/en-us/dotnet/standard/serializat...
Re: Progressive JSON
#35I've never really thought about how all the common ways we serialise trees in text (JSON, s-expressions, even things like tables of content, etc), serialise them depth-first.
I suppose it's because doing it breadth-first means you need to come up with a way to reference items that will arrive many lines later, whereas you don't have that need with depth-first serialisation.
Re: Progressive JSON
#36Seems like some people here are taking this post literally, as in the author (Dan Abramov) is proposing a format called Progressive JSON — it is not. This is more of a post on explaining the idea of React Server Components where they represent component trees as javascript objects, and then stream them on the wire with a format similar to the blog post (with similar features, though AFAIK it’s bundler/framework speci…
Yup! To be fair, I also don't mind if people take the described ideas and do something else with them. I wanted to describe RSC's take on data serialization without it seeming too React-specific because the ideas are actually more general. I'd love if more ideas I saw in RSC made it to other technologies.
Re: Progressive JSON
#37I'll try to explain why this is a solution looking for a problem. Yes, breadth-first is always an option, but JSON is a heterogenous structured data source, so assuming that breadth-first will help the app start rendering faster is often a poor assumption. The app will need a subset of the JSON, but it's not simply the depth-first or breadth-first first chunk of the data set. So for this reason what we do is include…
>The app will need a subset of the JSON, but it's not simply the depth-first or breadth-first first chunk of the data set. Right. Closer to the end of the article I slightly pivot to talk about RSC. In RSC, the data is the UI, so the outermost data literally corresponds to the outermost UI. That's what makes it work. It's encoded like progressive JSON but conceptually it's more like HTML. Except you can also have you…
> Closer to the end of the article I slightly pivot to talk about RSC.
Not again, please.
Re: Progressive JSON
#3899.9999%* of apps don't need anything nearly as 'fancy' as this, if resolving breadth-first is critical they can just make multiple calls (which can have very little overhead depending on how you do it). * I made it up - and by extension, the status quo is 'correct'.
We technically didn't need more than 640K either. Having progressive or partial reads would dramatically speed up applications, especially as we move into an era of WASM on the frontend. A proper binary encoded format like protobuf with support for partial reads and well defined streaming behavior for sub message payloads would be incredible. It puts more work on the engineer, but the improvement to UX could be massi…
Sure, if you’re the 0.00001% that need that. It’s going to be over engineering for most cases. There are so many simpler and easier to support things that can be done before trying this sort of thing.
Following the example, why is all the data in one giant request? Is the DB query efficient? Is the DB sized correctly? How about some caching? All boring, but if rather support and train someone on boring stuff.
Re: Progressive JSON
#39I feel like in an ideal world, this would start in the DB: your query referencing objects and in what order to return them (so not just a bunch of wide rows, nor multiple separate queries) and as the data arrives, the back end could then pass it on to the client.
That’s not going to make the front page of HN though.
Re: Progressive JSON
#40Progressive JPEG make sense, because it's a media file and by nature is large. Text/HTML on the other hand, not so much. Seems like a self-inflicted solution where JS bundles are giant and now we're creating more complexity by streaming it.