Building and working with an intermediary database with synced data appears to be a common solution in Forge when you want to bypass native constraints of the Jira api or extend objects.
E.g. It isn’t natively possibly to efficiently obtain batches of worklogs and metadata from a jql search request. But I can build a mirrored database of all the worklogs in my jira instance, where I can define whatever additional metadata I want, and I construct an api over it that will enable this batch operation. The api can be used for custom views and will also be responsible for syncing up worklogs whenever one changes in either database.
Do people have experience, yet, building this sort of integration service with the Assets api and database?
I find this choice appealing because it ticks a lot of boxes – built in api, in-house security and integrations with forge, nice built in ui management of databases, etc.
However, I’m concerned that this is not really an ‘intended’ use of Assets in applications. It seems (though I’m happy to be wrong) that Assets is intended to add some selectable relational data to Jira and confluence, and the Assets api is more intended for small automations to aid this feature, and for enabling reporting directly on Assets objects using a couple get requests, say. What I have in mind is a more traditional backend integration service that’s would handle a scaling number of bisync requests per day, say in the thousands as the number of users grows.
Is it performant, are the usage & rate limits per license compatible with this application, or would it be a prohibitively expensive solution, is it scalable, etc.