How to use the Storage correctly

[sangdth]

Hi, I fall in love with nhost from the very first look! Thanks for awesome works! I have a couple of questions which I'd like to ask for suggestions.

I'm making a gallery SaaS-like, just for a small circle of me and my friends, each user can have their own gallery site, a gallery can have multiple collections, each collection can contain lot of images. When user deletes their gallery, all images belonged to that gallery must be deleted too. nhost has everything but I don't know how to put things together.

Here are my questions:

• With above requirements, what is the best approach to store images information? I created tables: sites, collections, but then what can I do with images? Should I create aimages table in public schema and storage image's data like path etc? Does this way work well with Storage v2 idea? If not, is it easy to migrate/fix when it releases?
• I see a storage schema in Hasura database, but after I uploaded one test file, I see nothing had changed there. What is the purpose of it?

Thank you.

[elitan]

Hi @sangdth and thanks for reaching out.

• With the current storage solution, I think what you describe above makes sense. Storage v2 will work fundamentally different than the current Storage so migrating between the two versions will require manual work (or custom scripts).

• The storage schema is there to prepare for the upcoming Storage v2.

We don't have an exact ETA for Storage v2 at this time but I expect us to have something to show in the coming months. We're working hard on it! :D

If you're serious about storage and your SaaS I would recommend waiting until Storage v2 is released.

[sangdth]

Thank you @elitan , I will go with the current solution and focus on building UI at this phase, and hope that we will have v2 soon :D.

[elitan]

Sounds like a good plan! 👍

[paulbalomiri]

Hi @elitan ,
I'm working on implementing a filestorage for syncthing, to use with hasura.
ATM there seem to be 2 possible integration routes with hbp:

1. use the same file table(s) in the storage schema
2. implement a storage provider for hbp

Syncthing has it's own share concept which applies on a directory containing files to be shared with a common, which would have to be deduced from the individual files (basically all files belong to a share which have a common group of users sharing the file)

I only provide this as an example of how i'll need some concepts which extend the storage concept. I don't think that all possible share scenarios should be offered by hbp. So The next best thing is to have

1. the most basic of a file metadata definition in it's own table
2. hbp-storage specifics linked via tables
3. a possibility to access the normalized file of other storage providers, if a custom hbp-storage is implemented.

This would enable integration at the db level (more fine-grained) along with an integration at the storage level.
For This project the goal is to map files from different syncthing shares into a single root tree.

A big Help would be if the file table structure would be finalized soonish. This might even help with separation of concerns onto distinct tables while you implement storage.