This make me wonder if we can now really use the type available when you set API call in API Connector. Before this was possible to select, but was not working. Maybe it is now? I don’t have a use case for testing this
Yeah, that was kind of the only missing piece of puzzle we weren’t able to do on our own. Hopefully return data from backend workflows supports them and custom workflows in backend…i haven’t checked anything out
Should work with nested. API objects allow for deep nesting. Just getting deep nested objects mapped is great as you can initialize multiple object types at once, very useful for lots of data structures with inherent relationships
True for saving database storage work units, but a major problem for server processing work units if you process large lists simultaneously… which most will want to?
Hey Seneca, in this case again it would save a lot of server work - for large lists, this would be more efficient (in the Bubble world) - do you have a specific example?
Exactly - you’d be passing this same data (1000 objects) broken down into individual objects for Bubble to process, and you wouldn’t even need an action within the worklow to parse the data.
Bubble can schedule lists of up to 100,000.
In strictly server processing terms, this would be more efficient than passing the same massive string for every recursive worfklow to parse and consider (excluding the memory associated with each pass).
Ok, I might be confused because I’m thinking what happens to the monthly bill when those 1,000 items have tons of hidden data inside them, and Bubble tries to load all that heavy data 1,000 times at the exact same millisecond?
Wouldn’t that massive traffic jam instantly explode Workload Units?
