get_store should have an optional store_id parameter

[misterflop]

In the current implementation, get_store return the OpenFGA store specified in the client_api configuration.
Except by listing all the stores with list_stores, I don't see any other way to get a specific store different of the one defined in the configuration.
A way to arrange that would be to add an optional store_id parameter to get_store.

Part of openfga/sdk-generator#118

---

We should do something similar to what @jimmyjames mentions here:
openfga/java-sdk#150 (comment)

• for requests that use the storeId in the path, update the request options object to include a storeId
• In OpenFgaClient, if the options are not null and storeId is non-null and non-empty, use that to build the path. Otherwise, use the storeId configured on the client
• Update the tests to verify that the storeId can be overridden per request, and that the value on the client is used if not overridden.

In general, it should be pretty similar to how the authorizationModelId is allowed to be overridden per request.

[misterflop]

Same issue with delete_store. In the current implemantation, we have to create a specific client_api for every store that we would like to delete.

[rhamzeh]

Hi @misterflop

Currently, our SDKs now expect you to generate a new client per store. In the future (as part of openfga/sdk-generator#118) we are exploring offering two different interfaces which would allow us to have one that allows calling one with dynamic storeIds, but I don't expect that to be soon

Can you elaborate on your use-case where you would need to call multiple stores with the same client?

[misterflop]

Hello,

Thank you for your answer.

I see two use cases on my side:

• I'm currently implementing a multi tenancy application and I would like to have a store per tenant.
• For maintenance, if you need to upgrade schema of several stores with the same script.

The openFGA API allows to request per store ID. The SDK should ideally have the same contract.

[JRudransh]

In my organization, we are also facing the similar kind of Issue. To solve that we have built another wrapper microservice around the openfga sdk. You can also try the same. It will be more flexible for you

[gagandeepp]

interested @rhamzeh Please assign

[gagandeepp]

@evansims can you please assign this to me?

[ewanharris]

👋🏻 Thanks for the offer @gagandeepp. Sorry about this, we feel this issue isn't well defined for hacktoberfest as it requires working on some pieces of the SDK generation that are quite awkward to update.

We've specifically labelled issues that we're looking for help with with the hacktoberfest or good first issue labels if you'd like to take a look through.

[rhamzeh]

@evansims - can you push a small example commit for this work similar to what @jimmyjames did for the Java SDK here?