feat: context free infra #30
Conversation
|
Am I correct in thinking that this proposes essentially wrapping dynamo/s3/etc in UCAN invocation APIs? I'm curious if we could accomplish what you want by just creating normal TypeScript interfaces rather than UCAN Invocations and taking a little more care to hide the dependencies of the TypeScript interfaces from calling code... I can see advantages to having a nice set of UCAN invocation interfaces, but not entirely sure it's worth the complexity of trying to get UCAN Invocations in the middle of APIs that tend to do a lot of streaming (something that I haven't seen UCAN Invocations do well)... I like the high level idea and I think the core problem is something we should work on, just a little nervous about UCAN Invocations as the right way to define this abstraction! |
There was a problem hiding this comment.
I highly agree with Travis. Maybe a more concrete example would be easier to understand, but so far I would actually feel more complexity and design work for a fairly simple thing.
Also worth noting that this is not a w3infra thing, but the upload-api server context, you can see exactly same context needing to be created on the tests there.
Also as @travis pointed out, I would see an opportunity to simplify things at the Typescript definitions level, or perhaps rethink how we construct the context. But having a UCAN protocol just to communicate with these resources seems a lot of overhead for me, both in terms of more code to maintain and more IO operations to do
| 3. Queues (SQS, Kenisis) | ||
| 4. Email | ||
|
|
||
| We could greatly simplify our infrastructure if we simply exposed APIs given access to the listed primitives in terms of privileged ucan capabilities, that is capabilities that only server authorized entity can invoke. It is worth calling out that all of these primitives provide scoping mechanims object stores have buckets, indexes have tables, queues have groups or named streams. |
There was a problem hiding this comment.
In practise permissions are defined at the AWS IAM level, so while we can have a second layer of auth it does not solve auth all together.
Outlining idea of reducing complexity caused by vast context currently used by a service.