Different dab-config.json for different users/customers

[sergio45012]

Dear,

First of all thanks for this great tool and the efforts.

We are looking for a way on which with the same data-api-builder deploy we can offer RestAPI solutions to different users, use cases:

• Having different db connections strings (for different SQL instances).
• Be able to reflect entities/tables from different SQL instances.
• Allow the different dev teams to modify their own json file and not one that may have details for other teams.

Summing-up, the idea would be that each user/team/customer would have their own json file so they can change/adapt their own setup without affecting/modifying the others.

Thanks.

[aaronpowell]

Presently there is a challenge doing different config files, which we are tracking in #722

But addressing your first scenario, you can use an Environment Variable (see https://github.com/Azure/data-api-builder/blob/main/docs/configuration-file.md#accessing-environment-variables) to set the connection string at a per machine/per deployment level.

Regarding your other scenarios, wouldn't they make more sense to be treated as entirely separate repos that you load in different DAB instances?

[sergio45012]

The environment variables could be an idea yes, could I use also variables to indicate the entities?

Using different DAB instances is an option, we will think about it.

[aaronpowell]

No, environment variables are just for the connection string.

I'd like to understand more on the scenario you have where you can only have a single config file but need to support different database backends.

[Aniruddh25]

@sergio45012, @aaronpowell
Actually, environment variables could be used anywhere a scalar value is needed, an example is connection string but you could also use the @env('MY_ENTITY_NAME') . This PR #500 added that support.
Here's doc:
https://learn.microsoft.com/en-us/azure/data-api-builder/configuration-file#accessing-environment-variables

Let us know if you face any issues with using this.

[sergio45012]

@aaronpowell; the use case would be covered by running different DAB instances, which I think is a better approach than mixing different database backends in a single config file.