* I made it up - and by extension, the status quo is 'correct'.
I think the issue with the example json is that it's sent in OOP+ORM style (ie nested objects), whereas you could just send it as rows of objects, something like this;
{
header: "Welcome to my blog",
post_content: "This is my article",
post_comments: [21,29,88], # the numbers are the comment ID's
footer: "Hope you like it",
comments: {21: "first", 29: "second", 88: "third" }
}
syntax = "proto3";
service DirectiveAffectsService {
rpc Get(GetPageWithPostParams) returns (PageWithPost);
}
message GetPageWithPostParams {
string post_id = 1;
}
message PageWithPost {
string page_header = 1;
string page_footer = 2;
string post_content = 3;
repeated string post_comments = 4;
repeated CommentInPost comments_for_post = 5;
}
message CommentInPost {
string comment_id = 1;
string comment_text = 2;
}
There is something wrong with adding a "fancy" feature to an off-the-shelf option, if said "fancy" feature is realistically "a complicated engineering question, for which we can offer a leaky abstraction that will ultimately trip up anybody who doesn't have the actual mechanics in mind when using it".
Your comment focuses on desired outcomes (i.e., "nice" things), but fails to acknowledge the reality of tradeoffs. Over engineering a solution always creates problems. Systems become harder to reason with, harder to maintain, harder to troubleshoot. For example, in JSON arrays are ordered lists. If you onboard an overengineered tool that arbitrarily reorders elements in a JSON array, things can break in non-trivial ways. And they often do.
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 massive.
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.
That old chestnut again - this was true for MSDOS PCs in 1981 when the quote was said. It was still true 10 years later for whatever version of DOS was current then. People keep bringing it up as though Bill Gates said 'no one will need > 640k for all time to come'.