I’m wondering if anyone has loaded data into a Repeating Group from an API call (without actually saving the data to the database first). If so, how’d you set it up? Any surprises or lessons learned?
Also, would it be appropriate to assume the data typically displays to the user almost immediately (not the typical delay that repeating groups have when grabbing data from the Bubble database)?
Yes. In your API initialization, make sure that the “list data” is recognized as a LIST by Bubble.
Then in the repeating group, choose External API’s LIST (as your data source).
Delay: It is definitely faster then first saving the list in bubble DB. Almost instant - no 
But faster.
@sridharan.s let me know if you run into trouble
Yeah, you can do this. I just played around with it (as I’m sure you’ve already done). I have a fairly complex API that shoots back a list of complex things. Usually, this API is used to populate info into my database.
Just did a test where instead I simply list out some of the fields as text directly into an RG without saving… and ALSO with not saving-to-database, but setting the value of a local variable (“custom state”). I find the following:
Displaying the API return values directly in the RG happens in about 3 seconds after static page elements are displayed. (It’s fairly variable.)
If, instead of making the RG’s source “Results of my API CALL”, we first set a custom state with the values returned by the API. (Setting the RG to take that custom state as its source.): This sometimes seems just as fast as the “direct” display. But sometimes it seems to add perhaps 1 to 1.5 seconds to display time.
The reason I’m talking about “direct” and “custom state” approaches is that, practically speaking in a real use case, you may want to manipulate the API’s returned values in some way and shoving them onto a custom state provides a convenient “handle” for accessing them.
You could also do that by taking the “RG’s: value list” and it’s unclear to me if referencing that might be slower or faster than a separate custom state.
Anyway: (1) yes you can do this (2) it seems to be as performant as possible. But I guess the tradeoff is the increase in times (and costs, perhaps?) you might be incurring by directly pinging the API. (Only your specific use case can answer whether it makes sense to display values in this way instead of first saving them in the database or if it’s ultimately going to generate MORE overhead, right?)
Super interesting question though!
