Using API Connector 'Data'-type as Data Source with different environments

[artur.bielobrov]

Hi everyone,

A bit of a context: I am building an app right now and using Bubble as ‘frontend-only’. That also means I am using an external database that is only reachable through the Backend API (let’s call it ‘BAPI’).

To make a call to BAPI, I need to specify client_id and client_secret headers. I also want to have 2 different environments (one for dev/test - TEST and one for live - PROD). As I haven’t found any way to dynamically and securely pass client_id/client_secret and change host URL depending on the environment, I am using two different API Connection setups: TEST - BAPI and PROD - BAPI. I duplicate every TEST endpoint to the PROD endpoint changing the host URL.

Now the question: I have a GET /users/me endpoint on BAPI that will return profile information that is NOT stored in Bubble’s native DB (user’s name, timezone, etc.). In order to display that information in the group or fields I need to attach it to the data type somehow. The first thing to do is to use the TEST - BAPI GET /users/me endpoint as ‘Data’ and use it as the data type and data source for the group. But now how to deal with PROD - BAPI GET /users/me? It is a different data type from Bubble’s standpoint and I can not use source data from the TEST endpoint to feed the group with type of PROD endpoint and vice versa.

I could see at least two possible solution on that problem:

1. Duplicate ‘Account Group’ that shows profile’s feed and have ‘Account Group - TEST’ and ‘Account Group - PROD’ with conditions to display or not display the specific group based on ‘isn’t live version’ condition. But that would be horrific in case of any changes: I will need to duplicate all elements and rewire all expressions for each group independently.

2. Introduce a new data type ‘Account Info’ with all needed fields, and ‘owner: CurrentUser’. In that case, my endpoints will be of type ‘Action’ and not ‘Data’. Doing so I can dynamically choose in the workflow whether I need to call TEST or PROD endpoint, then just create a new ‘thing’ in DB and use ‘Display Data into Group’ which references a unified ‘Account Info’ as its datatype. Although that solution is flexible from the ‘environments’ standpoint, I am nervous about how much extra WUs such an approach could waste just for displaying data from an environment.

There could also be a third solution where I need to introduce another backend API, something like ‘Bubble Proxy API’ that will take all endpoint parameters from GET /users/me and also include ‘the env’ parameter so that the API itself will decide where to connect to PROD or TEST BAPI using that flag. That would allow me to use a single call for ‘Data’ but I am not sure if would it be a good architecture solution.

Has anyone faced similar problems? What do you think of my approaches? Please let me know!

[ThibautC]

Hello Artur

According to my understanding of your problem, here is a suggestion that I hope will help you:

• Data types are indeed linked to your API call. If you separate the API calls into two, you will then have double the work to hide or display them based on the type of call you make or the environment you are working in. Another risk I see is doubling your API calls if your groups are not displayed correctly, leading to an overload of calls and potential extra costs.

• A better solution would be to make a single API call to have only one data type, regardless of the environment you or your user is in. To do this, you can use a parameter in your API call that would be an environment parameter to call the correct BAPI on your side. For example: www.yourbapiaddress.com would become www.yourbapiaddress.[env].com. With this solution, you can then set a dynamic parameter (make sure to uncheck the private option to modify this solution).

I think you should explore this approach to find a solution that will allow you to avoid doubling your efforts on Bubble (and your potential costs).

Hoping this helps!

[artur.bielobrov]

Hi Thibaut

Indeed an approach using a single API configuration and passing host as argument would be optimal. But I have a few issues here:

1. What if host URLs are significantly different for every environment? I assume I could just pass the ‘host’ instead of ‘environment’ as a parameter. But here is a second question: will it be okay to create an option set ‘Environments’ which will have ‘Display: test’, ‘Host: www.host.com’? That would allow me to dynamically change the host of all endpoints attached to a specific env by just updating the option set’s value. But at the same time I will expose the host URLs to the users as option sets are stored at client and not encrypted.

2. There is also another problem with that approach. As I described the context, I have mentioned that the authentication to the API uses two header values: ‘client_id’ and ‘client_secret’ (see the screenshot attached).

I can not pass those values dynamically and securely in any way without creating two separate API configurations (client_id and client_secret are different for every environment). The best solution for me would be to have the option to set ‘dev’ and ‘prod’ value for that headers just like in ‘Authentication: private key in header’ option:

Unfortunately, bubble do not allow us to add more than one such ‘private key in header’.

I believe the ideal way is to let BAPI team change the authentication from client_id and client_secret (two separate headers) into one ‘client_credentials’ header that could be set for dev or prod env in bubble separately.