Cross Referencing Lists of Data Helo

[dave15]

Hello!

I’m hung on on trying to create a graph.

Here’s the use case:

1. A user has a Bubble Unique User ID (I’ll call this the BUU-ID) in the Bubble DB under the Data Type “User”. Great.
   

   

2. We’re sending that BUU-ID out via API and getting the BUU-ID + a new ID back. This is being stored as a new data type User-API, with a filed for the BUU-ID and one for the New-ID.
   

   

3. We have a third data type for data coming in from the API. API-Data. It has the user’s data, and the New-ID, but not the BUU-ID.
   

   

Here’s the challenge I’m having. The Bubble User will only ever have one BUU-ID, but might have multiple New-IDs across time (say the first authorization expired, it’ll then generate another New-ID when the user re-authorizes), each with a portion of their data (see the 2nd and 3rd images above).

When setting up a graph I need to be able to Search for the API-Data things that have ANY of the New-IDs that belong to the individual Bubble user.
Since there’s essentially a list of New-IDs that map to the BUU-ID I’m having trouble getting the logic expression to work.
Here’s one that I tried…

Here’s a link to a test version of the scenario:

Bubble Editor - Api-test-blue

Any help would be appreciated!

[josh24]

So I had a quick look at your app and I couldn’t see the API connector calls and how that’s set up. But I guess my first question is why you need to store the ID from the API at all? How is that relevant? I feel like you’re diligently over-engineering the solution

If you make a call to the API and then it returns a result that you then store in the database to draw your chart and you never need to pull that same specific record down again from the API - why do you need to store the ID of that transaction? I mean you can, but what are you going to use it for? You have the result stored locally in Bubble.

Wouldn’t you just store the result you get back from the API in Bubble and move on? Honestly, this massively reduces the complexity of then drawing your charts as you’re just looking up the chart table and pulling back the charts for that user and applying whatever other criteria you need to apply to filter the 10 charts down to 1 or whatever you’re trying to show on the page at that point.

---

Josh @ Support Dept
Helping no-code founders get unstuck fast save hours, & ship faster with an expert on-demand

[dave15]

Hi @josh24,
Thanks for taking a look at this issue!
The ID coming from the API (what I’m calling the New-ID) is generated by their system to identify the specific user, rather than the transaction.

We’ll only be receiving the Bubble ID + New-ID from the API one time when it’s first authorized.

After that we’ll be getting multiple downloads of data via the API that’ll include the same New-ID many times. The authorization will need to be periodically renewed and when it does there will be a new New-ID.

Ie:

1. Authorization returns: BUU-ID, New-ID-1, Success
2. Data delivery 1 returns: New-ID-1, Data point 1
3. Data delivery 2 returns: New-ID-1, Data point 2
4. Authorization expires, new authorization returns: BUU-ID, New-ID-2 , Reauth Success
5. Data delivery 3 returns: New-ID-2, Data point 3
6. Data delivery 4 returns: New-ID-2, Data point 4

Here’s an updated version of what the data might look like:

So, we need the API’s- generated user IDs to tie the data back to the correct Bubble user.

Then I need to be able to graph data points 1-4 on the same graph. This is where I’m stuck.

Thoughts?

Thanks again!

[josh24]

Ok, this makes sense. So without knowing the full story about that third-party service and exactly how it works, I think there’s a couple of options:

1. You could just authorize the user each time prior to the data delivery and not actually store that ID in the bubble database - remember this is useful for them but not for you. You should be always identifying your users based on your own user record and ID. This saves you having to have logic to manage the re-authorization process after expiration as you do it every time anyway. So you workflow would be:

• Authorize user
• Data delivery (using the new ID)
• Create an entry in the database

2. You save the ID in the Bubble user table and whenever it’s expired you just update it to whatever the current ID is. I’m guessing that after it expires it’s useless at that point? Therefore there isn’t value in keeping all previous IDs for a user in your database.

Then when you save the data that gets returned, those entries in the database are already linked to the user - i.e. Bubble has a field showing which user created it. So when you’re looking up your data you’re referring to your user table and not the APIs identifier

---

Josh @ Support Dept
Helping no-code founders get unstuck fast save hours, & ship faster with an expert on-demand

[dave15]

Hi @josh24 ,
I appreciate the input on how the API is working, but, unfortunately, adjusting how the data is coming in isn’t doable as this point.

What I really need is just advice on how to setup the expression for the data source in the chart element that’ll allow me to search for and return the Bubble ID, any API IDs associated with it, and any data points associated with those API IDs.

It seems like this should be doable, but I just can’t quite wrap my head around it.

Thanks again

[josh24]

So what I’m trying to tell you is to shift your thinking on the data in your database as you’re adding a lot of unrequired complexity. Using a third-party API’s dynamic identifier for your own users to identify users in your system is really just not good practice. Use your own identfier.

Your current process

1. A user signs up and is created in your app and saved to the user table (call it Table 1)
2. Authorize the user with the third-party API
3. Store the APIs ID for the user in Table 2
4. Store the data returned from the API in Table 3

some time later

5. Reauthorize the user and add another record to Table 2 with the new ID
6. Store the data returned from the API in Table 3

Then when you are trying to show the data to the user within your app you have a very complex web as you’re joining all this together.

You need to find all possible IDs for that user from table 2 and then find matching records for them in Table 3. But actually, every record in Table 3 is already tagged to the current user in the ‘created by’ field and with the user authenticated you can actually just look up Table 3 directly without needing to think about Table 1 & 2. i.e. Do a search for Table 3 with a constraint of the current user.

What I’m suggesting

1. A user signs up and is created in your app and saved to the user table (call it Table 1)
2. Authorize the user with the third-party API
3. Store the data returned from the API in Table 2

some time later

4. Authorize the user with the third-party API
5. Store the data returned from the API in Table 2

Then when you are trying to show the data to the user within your app all you need to do is look up the records in table 2 that have been created by the current user (each record is automatically tagged with the user that created it).

---

Josh @ Support Dept
Helping no-code founders get unstuck fast save hours, & ship faster with an expert on-demand