51–60 of 244 posts
I understand the GraphQL has fallen out of favour somewhat, but wasn’t it intended to solve for this?
For serialization GraphQL uses ... JSON. GraphQL could use Progressive JSON to serialize subscriptions.
Seems 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…
It’s become a thing, even beyond RSCs, and has many practical uses if you stare at the client and server long enough.
Earlier quoted context omitted.
To be clear, I wouldn't suggest someone to implement this manually in their app. I'm just describing at the high level how the RSC wire protocol works, but narratively I wrapped it in a "from the first principles" invention because it's more fun to read. I don't necessarily try to sell you on using RSC either but I think it's handy to understand how some tools are designed, and sometimes people take ideas from differ…
I get that. Originally my comment was a response to another but I decided to delete and repost it at the top level — however I failed to realize that not having that context makes the tone rather snarky and/or dismissive of the article as a whole, which I didn't intend.
Earlier quoted context omitted.
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.
This would be good. I got really, really sick of XML, but one thing that XML parsers have always been good at, is realtime decoding of XML streams. It is infuriating, waiting for a big-ass JSON file to completely download, before proceeding. Also JSON parsers can be memory hogs (but not all of them).
Json is just a packing format that does have that limitation. If you control the source and the destination, could you possibly use a format that supports streaming better like Protobuf?
The type and value are encoded the same as DER, but the length is different:
- If it is constructed, the length is omitted, and a single byte with value 0x00 terminates the construction.
- If it is primitive, the value is split into segments of lengths not exceeding 255, and each segment is preceded by a single byte 1 to 255 indicating the length of that segment (in bytes); it is then terminated by a single byte with value 0x00. When it is in canonical form, the length of segments other than the last segment must be 255.
Protobuf seems to not do this unless you use the deprecated "Groups" feature, and this is only as an alternative of submessages, not for strings. In my opinion, Protobuf also seems to have many other limits and other problems, that DER (and DSER) seems to do better anyways.
This feels very similar to JSON API links[0]. This is a great way to implement handling resolving those links on the frontend though. 0: https://jsonapi.org/format/#document-links
Personally I prefer that sort of approach - parsing a line of JSON at a time and incrementally updating state feels easier to reason and work with (at least in my mind)
Earlier quoted context omitted.
If you send the tree in preorder traversal order with known depth, you can send the tree without node ids or parent ids! You can just send the level for each node and recover the tree structure with a stack.
Well the whole point is to use a breadth first order here. I don't think there's a depth vector analogue for breadth first traversals. Is there? But, indeed, depth vectors are nice and compact. I find them harder to work with most of the time, though, especially since insertions and deletions become O(n), compared to parent vector O(1). That said, I do often normalize my parent vectors into dfpo order at API boundari…
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.