Got it !
And then, on the repetiting group, when you tell Bubble to actually look for the data stored in the DB, why do you use the first function ?
And then, I assume that when you need to filter data from an API using another APIâs value, the formula applied for a text would be quite complicated.
For example:
- player list: http://data.nba.net/prod/v1/2020/players.json
- team list: http://data.nba.net/prod/v2/2020/teams.json
How to take the teamID
value from the player call, look for the matching teamID
in the team call and then return the fullName
value from the team call to be displayed ?
That is the kind of stuff this API requires to do, since almost every call is connection to another call, itâs going to be a common use case.
About performances:
You said that adding each entry of each API call within a dedicated DB would dramatically damage the app performances. I would have thought that having data stored in the app would be more efficient than calling for an API all the time since the data is already 'in-house".
I also donât get why having a huge database of player with one entry per player is less efficient than having a huge one entry database with all the player in it. I would imagine that searching between 1 entry is quicker than 1000. But still, 1 huge 1000 element entry isnât the same a 1000 tiny 1 element entry ?
Because when you do a search for, this return a list. Donât forget that NBA players is a DB. In this DB thereâs only 1 item. And this is the item that contain the JSON of the api call. What I want, is this json, not really the NBA Players DB. This is why the type of content of RG is not set on a Bubble thing (NBA Player) but on API Thing (Get Players league standards).
NBA Players field in NBA players contain Get PLayers League standars data.
In my demo, Iâm listing the Player Team for each period using an API Call to Teams.json.
This is why I need to use filtered by (with the TeamAPI from PLayer call)
For you question about performance, this depend how often you need to refresh data.
For example : teams: I would not hesitate to create a WF that will create an item for each teams in my DB and using team instead of storing API Data. Because this is not the kind of data that will be updated often. But game live score? It can be updated every seconds. So if you process each game and create a game item in your DB for each of them, and you want to refresh it every minutes, it will take a lot of app capacity. Itâs better to A) Directly access data to API (but this mean each user will create call to API, so if you have 1000 user on your app at the same time, this is 1000 API Call every minutes (if you refresh it every minutes). or B) Store data in DB using âcachingâ like I did for the players list. This mean only 1 API Call each minutes and doesnât matter if you have 1 or 1 000 users.
And I will say that searching that return 1000 elements is not the same thing as searching 1 item that contain 1000 elements in 1 field. But again, this is something to analyze for each case to know what is better.
Well, my intention was not to store each game otherwise, Bubble would explode
That said, it spend the last couple hours playing around and I managed to call different endpoints and even mix data between them. My goal was to understand whatâs possible since this data is the foundation of my projected app. I need now to go deeper in every aspect of it but it looks totally feasible. That said, I think I understood I should definitely leave the data were it is and only store what makes the added value of the app (all that is user related).
The only key factor is now about the potential limitations Bubble applies to API connector calls within the app. For instance, if 1000 users are on a page that uses a API call to fetch the displayed data, will Bubble allow that ? What if itâs not 1000 but 10k users, and so onâŠ
Itâs doesnât change anything for Bubble I think, but maybe the API you are calling will not accept that. Each API have is own limitations and in some case you need to talk to their support to increase the number of requests you can make to their API
The API I would likely use is actually not a real API but endpoints on a website. So there is no limitations (I guess).
hey guys sorry to interfere here but I would have a question for @Jici.
in the example that you posted (btw thanks, itâs a most efficient solution), we retrieve the data API as a list. but what if I want to manipulate the data of the NBA players list? E.g. I want the Players league standard â heightMeters, to be:
- 0 if heightMeters <=2
- 1 if heightMeters > 2
i.e. if I now have a text element with the dynamic expression âCurrent cellâs Get players league Standardâs heightMetersâ it gives me either 0 or 1.
hope I was clear enough. thanks again