3 ms·
It sounds like the issue is not Json-* formats but Go's type system. And I'm not familiar enough with large go setups, but generally -in any language- anything
by berkes 4y ago
It sounds like the issue is not Json-* formats but Go's type system.
And I'm not familiar enough with large go setups, but generally -in any language- anything that must handle data "down the pipeline" should ideally not be bothered about whether this link (or meta, or paginator, or whatever) is there, is of Type-T and so on: that's for middleware/controllers etc to ensure, and to transform. In other words: your business-logic should ideally never have to bother about a link being either a string or a struct or a null etc: it should be able to assume it's a MyLink.
- mariusor 4y agoI'm not sure I understand correctly what you mean by assuming everything to be a "MyLink" but that's not always possible. It depends first on how deep the rabbit hole you want to go with dereferencing URLs - what logic will you employ to decide what level of dereference to full objects you stop at, and, more importantly on being authorized to access the objects pointed at by said URL. Sometimes ActivityPub activities come with properties that are IRIs that when dereferenced are giving you 404 or 401. What does your middleware do then: Retry, Abort, Fail? Also, I'm not sure I agree with your thesis that business logic needs to worry only about a single type of object, because the ActivityPub specification recognizes all of the types I mentioned in my first reply as being "valid" and if you consider their superset as being the "canonical type" you'll be wasting quite a lot of storage (memory and disk wise) when all you have access to is the plain URL.