Forge storage api plans

Forge
1

Hello,
I have a rather general question regarding the atlassian plans of improving storage api.
Currently storage api works as a pretty basic key-value storage.
That sadly really limits the use of the api in real life situation. Basically only to storing configuration of project.
Consider I would like to migrate one of our plugins to Forge platform, the project uses rather non-trivial ERD.
For example let’s have main entity QCItem that has 2 1:N relationships and 2 M:N relationships that store data for the project.
That’s borderline impossible to turn into key-value storage (regardless of limitations of such storage) and even if I made some clever mechanics with key names it’s still a question of performance.
It looks like nightmare to convert considering in spring boot you can build these M-V-C rather quickly these days.

So what are the plans in this area? Can we hope for complex Entity relationships modelled in forge apps?
Or the direction is more of an forge+atlassian connect blend in, where forge will server the UI and data storage is handled by current spring boot (for example) implementations with vendor hosted data?

To me one of the main draws to moving from atlassian connect to forge is to let atlassian handle hosted data of addons so they can guarantee data residency for example, I don’t see this possible with current storage api.

Thanks MV

1 Like
2

I thought the value in the key-value could be any JSON object. Does that allow you to represent entities and their relationships?

3

I would argue that no… it almost feels like you want to handle such entities as “jsonb” column in postgresql database which is highly ineffective in handling anything which tries to quickly manipulate content of the data (there is actually study about this where someone took 6 months of json twitter data and put them in postgresql as jsonb or constructed relationship database with tables foreign keys, primary keys etc and measured performance).
No indexes, no selects of columns, bad updates (you actually have to delete old value and write new one) etc…
You can do a lot of stuff but to me converting MVC to key-value pairing is not practical in any way.
MV

4

and of course there is the 32kB limitation… we actually allow users to store some images in base64 encodings… so you would need to split the entities into multiple entries and emulate tables with keys in key-value storage… I don’t see this practical in any way.