I need to store some data in my app, where I need to be able to query it based on property values. The data can best be stored in a relational DB, whereas the current storage API only provides a key-value store.
One way is to store it outside the app, in my own hosted relational DB with a thin API wrapper on top. But then, how do I authenticate app users for outside API access?
What is the recommended way to store such data?
1 Like
Out of curiosity: is it really necessary to use a relational database? We have several cloud & server apps and we’ve found that we hardly need any of the features from a relational database. The number of actual relationships is usually 1-2, which is easily retrieved simultaneously using a Promise.all, thus not causing to much performance overhead.
If your not dealing with legacy code, you might want to consider rethinking the architecture and go for a key/value store implementation.
4 Likes
Yeah, I think so. Because the app will heavily rely upon search, and filtering features, which are available out of the box in relational DBs. Implementing all of this with a key/value data store will be time consuming.
Right, makes sense. We use separate services for searching (ElasticSearch) and caching (Redis), which allows us to continue to use Key/Value store, but I understand you’d like to use RDBMS for this.
So, how do you identify app installation and current user? Is this information available somewhere in app context? If yes, then is it ok to store it in our own databases?
At this point, we are not using Forge yet. Our apps run on the Connect framework and are bound to our own data storage solutions anyway. As such, I don’t have a direct answer to questions about user / app context. However, wouldn’t that problem also apply if you were to opt for your own RDBMS? I would say that this is a different issue compared to the question of using RDBMS versus Key/Value store in combination with ElasicSearch & Redis
1 Like
Obviously, the premise of Forge is that you would/should not need to run your own infrastructure. This is partially also why we are not adopting Forge yet as we are waiting for these type of issues (the availability of decent search / caching services within the Forge framework) to be resolved.
1 Like
So, how do you identify app installation and current user? Is this information available somewhere in app context? If yes, then is it ok to store it in our own databases?
A unique identifier for the installation (installContext) and the accountId of the current user are both available in the context of a Forge app.
One way is to store it outside the app, in my own hosted relational DB with a thin API wrapper on top. But then, how do I authenticate app users for outside API access?
If a self-hosted relational DB is the best approach for your app, then you can do this through APIs as you have suggested. You can set API keys/secrets in the Forge app environment variables in order to be able to authenticate access to the APIs from the Forge lambda. Please let me know if I’ve misunderstood your question.