Hi all, we are implementing offline capability. We need to create the attachment ID ourselves (using crypto object in window). I thought of sending that as meta data per file, because if we are syncing our files (when we come online) we need to send the ID since we have IndexedDB logic and tables relating some entities with their own ID with the attachment ID (that we created offline).
What do you propose would be the ideal situation for this?
P.S. we are using Uppy of course, with Compressor package for images, pretty complex app.
You should be able to send such an identifier inside the meta data, yes. I don’t see a problem with that. However, the server should still create its own upload ID to avoid collisions. The ID in the metadata can then be used to associate the client’s attachment and the upload resource on the server.
I know Uppy uses local storage to handle caching and resumable uploads via Tus. Will this create some issues? I guess I need to tell backend guys if they receive an ID in the meta data to use that instead of the one created via Uppy? How will that influence the resumable part of the library?
I don’t think it’s necessary for the server to use the identifier in the meta data instead of generating its own. It can use the meta data value to identify the corresponding attachment. Likewise, the client can use the meta data to correlate the upload and attachment.
That being said, without more information it’s hard to give more concrete help. I would recommend you to start your implementation and then contact us if you run into specific problems. Tus clients and servers are usually flexible enough to accommodate different system architectures.
It’s necessary because since we are attaching a file to an entity in offline mode (i.e. this comment, has an ID that is usually created by BE, but in offline mode the FE needs to create the ID for the comment and eventually sync with BE, so BE will see we are sending an ID so they will not create one themselves). The same logic is applied to the attachment, we need to “assign” an attachment to a comment that doesn’t already exist, so we are doing IndexedDB magic to join the comment and the attachment via composite ID in a table that stores only the commentId and attachmentId.