Open windbeneathyourwings opened 2 years ago
Tagging might be a good option to limit writes to existing panel pages.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-tagging.html#tagging-and-policies
At the moment the owner of the object can be used in a policy to restrict writes to only the owner. However, there is not currently a way to restrict operations to an object based on a group of users. This could be done by using tagging since tags on s3 objects can be used in policy conditions.
I'm thinking that creating a crud module that manages and wraps the lower level apis might be the way forward. This makes sense since an entity could use one or several different storages. I could also call it storage but I kind of like crud. The search mechanism will be separate since search interfaces can vastly differ. Perhaps is makes sense to convert json rules engine objects into searrches. We could have search engines plugins that provide the search functionality or convert supported "inputs" into searches for the specified engines.
CrudPlugin
Pass object with identity.
options: { identity: (object) => identity }
aws3 providess s3 crud plugins
Might want to support variant operation implementations per plugin ie. write using upload, write using multi part upload for s3. Things like that.
Permissions also comes into play here I think. Although the perms will need to be managed inside policies they also need to be enforced on the front-end.
Nice to builders that can easily create entity data services mixing and matching CrudPlugins.
Identity factory for data entity
PanelPages used as forms will have configurable storages for submitted data entries. Display types will need options to make this a reality. The "form" display type would provide a a list of operations and crud plugins that can be used for each operation.
The crud module has been created. The s3 module provides a basic, limited panel page persistence to s3 implementation. Still need to work on factoring out some of the hard coded configuration like bucket name and cognito params. Should consider making cognito identity builder more reusable and placing inside awcog or authenticating using effect in background perhaps. Also files are being stored as json not as gzipped files because I wasn't able to hunt down a good library to do gzip compression on the client. So for now I guess that works. Also need to determine how to best allow data services to be configured using any crud adaptor plugin for any native data service operation.
It is no longer necessary to use the go api to upload information.
The aws sdk can be used to upload these assets directly.
https://aws.amazon.com/blogs/developer/modular-packages-in-aws-sdk-for-javascript/
I would like to to create a ngrx data service that is capable of doing this.
Than use that data service to upload assets serverless.
No loner needing the go api.