You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today aeps have a pattern of using the resource singular as a field name. For example, create is something like:
message CreateRequest {
Book book = 1;
}
When these patterns leak into the more dynamic world of json, it makes it difficult to create simple, dynamic queries.
One example is the one linked above: with resource revisions, we could either call a revision 'snapshot' all the time, or we could use the resource singular:
message Revision {
Book book; // option 1.
Book snapshot // option 2.
}
For a json client, it'd be great to be able to extract all snapshots with a common jq query, something like:
This jq would not have to change if we called the field snapshot everywhere.
Ideally for standard methods and design patterns, we don't use the resource singular, instead reserving it for something like a resource reference instead.
The text was updated successfully, but these errors were encountered:
Yeah this is definitely simpler in some ways, albeit maybe slightly uglier ("snapshot" doesn't bother me but, having to call the field in a create request "resource" does a bit).
We concluded we shouldn't optimize for this and I still agree with that conclusion, but FWIW, this change would make Roblox fully adopting AEPs a bit more challenging, since we're not doing this today.
To be clear, I think we should select the best guidance, and not treat Google or Roblox or anyone else as binding precedent...but I also feel compelled to mention this as an aside given the recent discussions about what it would take for Roblox to adopt AEPs (and in particular the fact that -- so far -- the divergence is minimal to nonexistent).
Just in that wasn't clear enough: I do not think Roblox's precedent should be a factor in this decision.
This is spawned by https://github.com/aep-dev/aep.dev/pull/200/files#r1682253152.
Today aeps have a pattern of using the resource singular as a field name. For example, create is something like:
When these patterns leak into the more dynamic world of json, it makes it difficult to create simple, dynamic queries.
One example is the one linked above: with resource revisions, we could either call a revision 'snapshot' all the time, or we could use the resource singular:
For a json client, it'd be great to be able to extract all snapshots with a common jq query, something like:
This jq would not have to change if we called the field
snapshot
everywhere.Ideally for standard methods and design patterns, we don't use the resource singular, instead reserving it for something like a resource reference instead.
The text was updated successfully, but these errors were encountered: