In order for you to be able to find the best layout for your particular use case, I’ll explain how RS sync works in general.
Every document and folder carries an ETAG, which will change when the document, or a document in the folder is created, updated, or deleted (as a shorthand we just call all of these “modified”).
With remoteStorage.js, when you tell it to cache a certain path, i.e. a root folder/directory, it will regularly check only the root folder for a changed ETAG. When it sees an update, it will check the ETAGs in that folder’s listing to find out what has changed. If one or more subfolders carry new ETAGs, it will do the same for all updated subfolders, until it has found all documents that have actually been modified.
So the considerations I see are:
- The more items you have, the larger your folder listings will be. Downloading larger folder listing anew is more expensive than downloading a smaller one.
- The more items are being modified regularly, the more often clients have to download the folder listing for them.
In my personal opinion, a rule of thumb from these considerations is that, the more items you expect, the more folders you want to create (usually). And that it is the job of the data module to deal with the complexities of handling more folders.
In fact, for my own bookmarking app, I’m already considering adding more folders for various types of bookmarks, so that I can sync them more efficiently. For example, when “read later” bookmarks go in their own folder (until they’re archived), clients only have to sync that much smaller folder to update the reading list in their app. Also, apps can then decide to not even care about “read later” bookmarks or archive bookmarks, which means they don’t have to sync and cache those types at all in the first place.