Data Jedi provides a single plugin element—referred to as an instance—that exposes key states and events for managing any list‑based data workflow:
Fields let you customize the instance:
Data Jedi Element Name
Assign a unique name so multiple instances can coexist without conflict.
Value Data Type / Value Type Source / Value Data Type JSON
Define the schema and initial payload for your list of objects.
Extra Value Data Type / Extra Value
Send or receive a supplemental value alongside your main list.
Create Unique Identifier
Automatically generate unique IDs for items that lack one.
Exposed States surface your processed data to Bubble workflows:
Value List
The array of objects ready for repeating groups, form data or conditionals.
Extra Value, Bubble API Ready JSON
Your supplemental value plus a stripped‑down JSON string optimized for API calls.
Modification Error Return / Modification Error Message
Boolean and text flags that let you detect and report client‑side errors.
Workflow Event Triggers signal lifecycle changes:
Convert Complete, Modification Complete, Removal Complete, All Values Cleared, and more
Use these triggers to chain subsequent workflows precisely when data operations finish or fail.
Client‑Side Workflow Actions operate instantly in‑browser at zero server cost:
Data Jedi Convert
Converts new JSON into the instance’s data types list of objects.
Data Jedi Clear All Value, Data Jedi Clear Value List, Data Jedi Clear Extra Value
Reset list, extra value, or both, optionally firing the corresponding workflow event trigger.
Data Jedi Remove Items
Delete specific records by ID, with custom key support and removal confirmation via Removal Complete.
Data Jedi Modify Items, Data Jedi Modify Extra Value
Patch existing records or update only the extra value, each with error‑handling options and post‑action triggers.
Data Jedi Clear Errors
Reset all error flags and messages, then fire Errors Cleared to restore the empty state.
SS Data Jedi Convert
Extracts every JSON object, generates IDs, and returns a rich payload of valid items, error details, and flags—all in one call.
SS Data Jedi Compare Lists
Compares two JSON arrays by ID, merges, detects creations/modifications/unchanged items, then returns converted lists plus error reports for missing identifiers.
Each server‑side action returns a structured JSON object you can reference in subsequent workflow steps. Keys like Value List, Created List, Modified List, Returned an Error, and Error Items JSON give you full visibility into successes, failures, and final data. By consolidating complex data‑shaping logic into a handful of workflow actions, Data Jedi empowers both beginner and advanced developers to build robust, efficient data flows without sacrificing performance or incurring high workload‑unit costs.
Here is a view rambling videos introducing data jedi with one use case of how to save upwards of 99% on data Create operations and upwards of 95% on data Read operations.
Interesting, I think. This looks a lot like why people migrate data to Supabase or Xano as they can be an efficient way to reduce data load times/WU consumption. The cost is ok, if it pays back in WU but the investment is development, your plugin would need some serious wiring in for most apps. Therefore I think I’d want a bit more clarity on it. These are my immediate Qs:
Q1: Does this work with autobinding? And is that also saving WU?
Q2: Does this still allow realtime updates for all users sharing a view/edit on a Thing via their own browser?
Q3: Where does my data ‘go’, are there any third party processors being introduced?
Yes, when WU pricing was announced that is when people started to talk about Supabase or Xano as a backend for reducing WUs. The problems there are you still do have costs for API calls and added complexity for user data types, passwords etc. and are adding in another service layer (Xano or Supabase). This does not require any 3rd party systems nor does it add any complexity to working with User data types in Bubble as everything this plugin does is in Bubble and uses the existing Bubble database.
The value proposition of the plugin is not just it’s ability to reduce WUs for creating or fetching data. Saving Workload Units is what led me to finding my way to building it, but there are so many benefits that go way beyond just saving WUs. It opens the door for functionality that is not as readily available to most non-technical developers. I’ll be adding lots of content around how the plugin expands current functionalities.
If you are starting from an existing application and want to utilize it to reduce WUs on searches, depending on how complex that data type is woven into your app, is how much wiring in needs to be done. For example, I have a data type that is used just for searching, for SEO purposes, that eats 200,000 WUs a month. The data is never changed, so I have one reusable element as a ‘card’ and a page that displays the search results. All I needed to do was create my objects in api connector, extract from DB my 2,000 items as JSON, then pasted into a data jedi element, and ran a save operation to my database to save those objects. Then just remapped the data field values for the ‘card’ and the search.
If starting out with a new app, it can save you some time as you can do things like have a global data center.
It does not work with inputs that are set to autobind because autobinding automatically changes the values in the DB…but you can create an ‘autobinding’ type of functionality.
I would not recommend this for every single data type to be transformed into an api connector object. There are use case examples that Data Jedi with the api connector object approach are not suitable and some where it is great. Best examples generally are data types that are controlled by one individual user, changed infrequently, do not need multi-user editing real time updates.
Despite my recommendation, the plugin can still take a database data type and format it as json (put into data jedi element field) and be created as a api connector object, which those can be manipulated and saved back to the database, so likely does work with real time updates with multiple users…I just caution it at this point as it is all very new and I have not personally used it that way yet.
Data doesn’t go anywhere. No 3rd party processors introduced.
Does this work best for data that rarely or never changes, or would it work as well for user data that changes frequently.
For example, I have a task manager app. Every time a user logs in, their active tasks, projects, etc. need to be loaded. I try to load everything up front so that app is quick and responsive.
From one login to the next there are certainly changes, but of the hundreds of items that need to be retrieved, only a handful will be different each time.
I still need to pour through the videos and documentation, but if I understand this correctly, this will retrieve the data type including all of the fields all in one request? That would be amazing.
I try to keep the user’s data available as much as I can, but I am probably blowing up my WUs. Once I have a list of Things, I still need to frequently reference the fields just for filtering and searching on the frontend. Could this plugin alleviate this frequent polling of the fields by storing that data in the front end? Did I understand this correctly?
Thanks! I look forward to learning more about this plugin.
I went through the videos. I understand following:
You suggest to create a new data type which is of API source kind and have only the fields we are interested in. Let’s say we call it D1
For creating the data, plugin makes use of bulk create API, and hence saves on WUs. Though that one can do even otherwise without plugin?
For fetching data, you suggest that we create a new data type in the system that has list of the data type we want to work on. Let’s say we call it DBD1L.
And then use the Jedi element to create a new entry in DB for the new data type DBD1L which would have list of all the data types of the D1 type.
Now when we need to fetch data, we should fetch using Jedi element in which data source should be of DBD1L. Now since DBD1L has only one data entry, it would be much faster and save on WUs because having one entry only will remove many redundant text that comes with many entries in the JSON payload.
Jedi element will then keep this all in memory on frontend and further usage of the data may not cost any WUs.
Not sure if I understood fine. So you can confirm that and correct if I have got it wrong.
Few questions that come to the mind here:
You have compared cost of creating 100 elements. Can you also compare cost creating just one element as that is the most often use-case and the cost saving in that case probably may not be as dramatic.
A new data type has the list of static values from the DB. If data gets updated, this new data type may not get updated?
Is your tool useful in specific scenarios and not as useful in specific ones? e.g. More useful when large data is being created/fetched with not much changes in data but not as useful in frequent data updates use-case?
If one is in position to utilise bulk data creation api, they can create it directly without the plugin. Then why use it?
Can you also put down some textual documentation detailing such things as to
How to use tool for different use-cases like someone having a table of data being displayed in a page, Or while having data aggregate being done, Or while having search results shown for use-cases like property search/hotel search etc.
In what cases does it help to utilise this tool e.g. Like when you have lot of elements vs few elements. Or like when your data changes frequently vs sparingly etc.
How can an existing app move to using this tool
In one video you alluded to using this plugin for creating temporary option set on one page. I think that is an excellent use of it as it saves from Option set becoming bloated which loads on each page, and also makes it easy to edit. It would be nice to have this and other such potential use-cases you have envisioned, documented.
Various such questions are coming to the mind due to incomplete clarity in my mind on your plugin.
Hope you can clarify on these points. In general having a textual documentation would be helpful as one can easily read/re-read, quote etc.
I also just watched all the videos. This looks amazing. I look forward to including local storage in this system!
My data types use a lot of related data types which are often used for filtering. How do fields in related data types work in this plugin? Or are related data types not really supported here?
Here is a quick video demonstration to answer a question surrounding the ability to have the updated data displayed in real time. The answer is yes, it does if the data is from the DB. So once you create your objects and save them to the DB, and later fetch them from the DB to display them, and another user updates the DB object, the updated data is displayed on the other users device.
At its heart, the plugin is a convenience layer on top of Bubble’s API and database:
Novel data-structure pattern – lets you store “objects” as variants of the same thing (e.g., Product-Full with 100 fields and Product-Lite with 5) and integrate these into bubble database structuring in a hybrid approach with custom data type of 100 fields and ‘object’ as 5 fields.
Pre-built actions – bulk create / modify / delete / backend-workflow trigger, already formatted exactly the way Bubble’s API expects as well as client side CRUD operations for ‘objects’
Global front-end cache – once you pull JSON into the element, every part of the app can read or update it WU-free through exposed states, optional local-storage sync, and conditional events.
Robust events & error handling – fire success/failure events only when you choose, catch JSON error bundles, clear/retry with one click.
It helps both, but the implementation is best when records aren’t being edited every few seconds. A task list that changes a few items per session still benefits because you fetch the whole bundle once, cache it, and then mutate locally before writing back into Bubble DB.
“Can it preload hundreds of items when a user logs in?”
Yes. Use an Object list (id, title, status and other fields of choosing) wrapped in one parent record. You pay for one single-item search instead of hundreds of per-item charges, then filter/search on the front end for free.
“Does it cut down repeated field polling?”
Exactly. After the initial load, any filtering, searches, or UI updates run against the in-memory JSON—no extra WUs. You decide when to push changes back. But if you use a Do a Search to fetch from DB the object list, the objects client side update in real time as changes to the DB take place.
Correct. Create ‘object’ copies so you never pull more than you need.
Bulk create via API saves WUs—could be done without plugin
True, but the plugin (a) removes the JSON hand-crafting for Bubble bulk create JSON formatting, (b) batches automatically, and (c) gives conditional success/error events. That’s time saved on every workflow that needs to interact with the API.
DBD1L (wrapper with a list of D1) → fetch once
Spot on. One lightweight search returns that list of ‘bojects’ wrapper; Bubble charges as if it were one thing.
Front-end cache stays in memory
Yes. You can refresh it on demand, on interval, or after an update action.
Your Specific Questions
Cost for a single record – Bulk vs. standard create is roughly a 25-35 % saving for one record. Not dramatic, but you still get the developer-experience wins (global cache, events, error utilities). The value proposition of the plugin is not simply it saves Workload Units, it is much much more than that, and so determining the plugin utility for just trying to save WUs for creating a single entry in the DB is not really how to think of the plugin value to an application.
Keeping data fresh – Include a “last_modified” field in the ‘object’; let a scheduled backend workflow update the cached list when something changes, or call the plugin’s refresh action after writing. You can add all sorts of ‘meta’ data fields of your choosing.
Where it shines / where it doesn’t
Great for: reference tables (countries, currencies), catalogs/products, user dashboards, option-set–like lookups, large form builders, notification feeds, single user controlled data (chat messages related to a conversation, social media posts), blog posts, heavily searched and rarely modified data types.
Less impact: real-time collaborative edits on the same record by many users ( shared whiteboards) where Bubble’s built-in live updates are already optimized. The reason for the less impact here is if focusing on impact in form of WU savings on creation or modification of data. However, the plugin and the approach for data structuring work just fine for this type of data as well.
Why not just call the API yourself? – You absolutely can. The plugin simply packages best-practice JSON, batching logic, conditional events, and error parsing so every Bubble dev (even non-coders) can use the pattern safely as part of a larger set of actions and elements that provide more power and utility. Additionally the plugin actions for working with the Bubble API will be expanded upon to make bulk modification cheaper and more targeted per list item.
Example Use-Cases (Hybrid Approach)
Scenario
Legacy Approach
Data Jedi Hybrid
Product catalog (5 k items)
5 k items returned & updates
One wrapper per category + ‘objects’ → 95 % fewer WUs; instant front-end filters.
User-specific task manager
Multiple searches (tasks, projects, subtasks) each login
One cached task-bundle; mutate locally; bulk-save changes on logout.
Currency rates from external API
Poll API → save each rate
Fetch JSON → plugin bulk-create minimal Rate objects; one wrapper for display; refresh daily.
Temporary option sets (page-only)
Combine Data from separate APIs into one Type|Add to global Option Set (bloats every page load)
Need to on page or backend combine and save as text|Build client-side list in plugin, style with upcoming searchbox; zero impact on other pages.
Convert API call response into object and save to database. Option to add additional key value pairs for different API response data types|
Beyond WU Savings
Global communication – Exposed states mean any element, anywhere—header, popup, reusable—can read/update the same dataset instantly.
Conditional events – Trigger follow-up workflows only when certain fields change, when bulk call succeeds, or when a specific error is caught. This means greatly improved data processing timing for subsequent workflows
Security layering – By creating lean variants, you physically exclude sensitive fields before privacy rules even run. Additionally, for some use cases like contact management systems, the legacy approach of one data type for all contacts can be replaced with a new hybrid approach of contact ‘objects’ stored as a list field on user data type ensuring contacts owned by the user can never be inadvertently exposed to other application users.
Advanced Filtering on Related Data – With the hybrid approach you can store ‘objects’ as a single item on a field of a custom data type like Contact, such as address. Where the address ‘object’ holds all relevant key value pairs such as street number, street name, latitude and longitude etc. without a need to use an ‘extract component’ operator, and thusly allows the nested ‘object’ to be filtered on when searching/filtering the normal custom data type of Contact. Additionally the soon to be added search/filter element allows for filtering by nested fields.
Migration in Three Easy Steps
Pick one high-volume list (e.g., Orders) and create a Orders_Lite ‘object’ + a single Orders_Wrapper as a custom data type.
Swap the page’s data source to the wrapper via the plugin’s fetch action. Remap data fields.
Replace old create/update flows with the plugin’s built in client side CRUD operations and normal bubble workflow actions to save to DB.
What’s Next
Searchbox element (multi-field, nested-key search, CSS ready) and paginator/prev-next helper – shipping soon.
Template Apps – free shopping-cart and product-search templates so you can copy-paste working demos.
Improved videos – shorter, focused clips replacing the rough first batch. @augusto1
Your feedback drives the roadmap. If you spot an edge case, have an idea for an enhancement, or just want a sanity check on your implementation, let me know—happy to dive in.
Just put together a simple example of how to leverage Data Jedi to create large Option Sets that can be dynamically created by your users if you choose to. This approach to utilizing Data Jedi and a Hybrid approach to data structuring in Bubble DB, can also be applied to augmenting or replacing your use of App Text.
I put this together as I am adding the URL Path List Extractor element that makes working with URL Path Lists simple, and in essence improving your SEO as it comes with the built in Structured Data for Breadcrumbs that can be conditionally exposed to the page, which when added into a single reusable element Data Center makes it a very robust element for modularly built apps that can benefit from a little SEO breadcrumb love.
This figure is for data Fetch using the Hybrid Data Structuring approach that the plugin makes more readily accessible to all bubble developers regardless of experience level. For creating data using the Hybrid approach the WU savings are 99%+ (this is a sliding scale, the more ‘objects’ you create at once, the larger the WU savings as a percentage compared against traditional approaches). It also has the actions built in to take advantage of the bulk create API call and has the exposed value with the correctly formatted JSON for that call, which when using that approach to create in bulk custom data types, when compared to other approaches such as schedule on a list or recursive backend workflows the WU savings for creation are very high as well.
Now, the WU savings the plugin enables to be more in reach for any Bubbler and the Hybrid data structuring approach used to achieve those results are not the primary value proposition of the plugin. It is however, the issue that sparked my investigations, tinkering, hypothesizing and formulation of the Hybrid data structuring approach, that caused my need to build the plugin as I needed to build all CRUD actions required to work with the API connector and Plugin Objects just as we would with custom data types or option sets.
Some other value propositions are the performance improvement as content download times are 30-50% faster when fetching data built in via the Hybrid data structuring approach compared to traditional fetch that uses the legacy approach to performance improvement of ‘satellite data types’ (ie: same number of field values and number of objects returned). This means it makes it cheaper to run the app and improves performance of the app.
Emmanuel in the AMA on AI made the point clear that WU and performance are related. It naturally makes sense since the WUs charged are directly related to the amount and duration of processing data, or the amount of data returned, which thusly impacts the speed at which it can be returned. I think it is a point I’ve tried to make several times when discussing WUs and the need to optimize for the reduction of them, as not so much just the idea of reducing a Cost, but rather improving the Speed…which when thinking around costs or generally, money, having even the slightest performance improvement or increase in speed can equate to lots of money saved and earned as running adverts and pay per click with slower load times, more users jump off app, and so a waste of marketing budget, and loss of potential revenue. This is a great article that explains why loading speed (ie: content download time) is important to a website and the financial success of the app.
That is not the only issue. It is also the generalized approach to demonstrations, length of videos so far, lack of clear use case examples with structured videos or step by step guides.
This is my fault as I actually released it earlier than expected…I honestly just couldn’t control myself and my excitement caused me to run with 3 legs instead of walking in a straight line on two.
My goal is to start providing some content that helps translate what people already know (Bubble custom data types) of how to setup and structure their Bubble DB, into how the setup for utilizing and implementing the Hybrid data structuring approach.
No worries at all, I am responsible for not making the explanations and content more understandable. It is also the messaging, as it seems like based on my historical obsession of improving performance (I mean reducing WUs), and releasing this with first content to demonstrate the immense WU savings, that the value proposition of the plugin has been lost in my communication.
From my 7 years of building on Bubble, I know what this plugin can do, and because of that, my excitement and enthusiasm for the plugin is through the roof. It has opened so many cool feature potentials, and made it so that we can scale our apps better on Bubble (not from usage perspective but feature enhancements and additions). Based on this, the AI movement and mobile apps, I’ve finally made a decision to open a Bubble Development Agency and really go all in on Bubble as my business. Due to that decision, I’ve begun making new product lines, and to support those, I need to make lots of content.
The Data Jedi Plugin will have (and does already) very detailed documentation both in the plugin on every field, action and event, plus Notion documentation in markdown form to be easily digestible by LLMs for guided assistance with implementation. It will continuously be improved upon (ie: based on me using it in everything I build where applicable I’m finding areas to enhance it’s functionality in ways that make it even more versatile and useful) and made in such a way that it will always be extremely flexible enabling even more modular builds for features and functions.
As I have been building on Bubble for 7 years and my presence and consistency on the Forum as a clear indication of my commitment to Bubble and opening of a development agency, users of the plugin can rest assured it will be maintained, updated, and fixed when notified of bugs. I’ll also always be willing to add in feature enhancements based on requests that would benefit all users and help the plugin to be more flexible.
As I continue, my focus will be on creating more content with solid use case examples (yesterday I built a shopping cart feature) that will be available as free template downloads so users can easily get more complicated features into their apps quickly, or use them as learning resources to understand how the plugin works and can be implemented into their apps.
As there are so many different potential use cases for it, it will be a long process to get as much content ideas created as I’ve already planned for.
In the meantime, if you are interested in learning more, please reach out via PM and we can schedule a free call where I can answer some questions you may have, or demonstrate some of the functionality or perhaps implement it into your app for a specific use case. Or if you have some use cases you think it may help, let me know and I may be able to build it out as an example.
Thanks for taking the time to give a thoughtful reply.
Also, congratulations on your Bubble Agency. You’ve helped a lot of people on the forum and I’m sure you’ll help a lot of people with your agency.
I took all the info on your plugin I could find on the forum and gave it to my overpaid assistant and asked for a marketing brief. Ok, just kidding I asked AI and this is what I got:
Your Secret Weapon for Faster, Cheaper, Smarter Bubble Apps
Let’s be honest. Building powerful Bubble apps often means hitting a frustrating wall: sluggish performance that drives users away, OR scary Workload Unit (WU) bills that stifle your growth.
You deserve better.
Introducing Data Jedi – the revolutionary plugin meticulously crafted to shatter those limits. Think of it as your smart, invisible assistant working tirelessly inside Bubble, optimizing your data handling like magic.
Data Jedi empowers YOU to build the lightning-fast, cost-effective, and powerful apps you’ve always envisioned, easier and faster than ever before.
Here’s How Data Jedi Transforms Your Bubble Development:
SLASH Your WU Costs: Watch your Bubble bills shrink! Data Jedi uses hyper-efficient methods, especially for handling lists and bulk operations – potentially cutting specific WU usage by an incredible 99%+! Keep that money for growth, not just operations.
BOOST App Speed DRAMATICALLY: Deliver the seamless, instant experience your users crave. Load data 30-50% faster and make your entire app feel incredibly responsive with smart data caching right in the user’s browser. No more waiting!
SIMPLIFY Complex Workflows: Stop wrestling with tricky data logic and endless workarounds! Data Jedi bundles advanced database operations, API calls, and error handling into simple, elegant actions. Build faster, debug less, and launch sooner.
UNLOCK Advanced Power, Easily: Seamlessly implement flexible data structures (‘objects’), access data instantly anywhere in your app (WU-free!), trigger workflows with pinpoint precision, and handle errors gracefully. Build like a seasoned pro, regardless of your technical experience!
STAY 100% NATIVE TO BUBBLE: Get all these incredible benefits without the headache of adding complex external databases or services. Data Jedi enhances the Bubble platform you already know and love.
Why does this matter? Faster apps mean happier users, better engagement, and higher conversions. Lower costs mean more profit and runway to scale your dream. Faster, simpler development means bringing your vision to life now.
Stop letting performance limits and WU anxiety dictate your app’s potential.
Thought it wasn’t too bad. I’m sure it could be improved. But, the plugin sounds like something that is going to be very useful.
Thank you. And thank your assistant for me that write up is way better than mine, I’ll have to interweave it into a landing page when I get a site up and running.
Looks cool, I have a use case which maybe you can let me know if this would improve it.
I have a user-facing page with a RG of 500 or so rather large objects with 25 fields per object (Built this table years ago so it’s not optimized). Rather than returning the direct objects, I have a backend API call that returns just the title, icon, and UID of each object to keep the JSON slim.
When the user clicks on a RG item, we fetch the actual item from the DB so we’re not loading everything at once.
Would using this plugin achieve a similar function?
This looks fascinating! Still trying to get my head around it and figuring out if and where it would best help my app.
One initial question… What are the limits? I mean usually pulling in thousands of records at once is frowned upon and doing so really slows the computer, for example when storing a list of search items into a state. Bubble also has set limits such as 50, 100k results etc.
Maybe this is totally irrelevant with your plugin? Forgive me if my understanding is so off that this question doesn’t even make sense maybe
I have not put together a set of test values yet that exceeds 1,000 items to see how it handles larger data sets. When I am working with larger data sets, the same type of ideas related to amount of data to download equate to amount of time required to download per user device capacity as it does when working with any other type of data in Bubble.
There are reasons to use it beyond WU savings or performance improvements, so I have not spent my time devoted to testing against large data sets that I am not able to segment easily into smaller sets of data. My expectation is that you would see improvement if pulling in API Connector objects versus custom data types in the same ranges on large lists as smaller lists, which from my testing is usually around 30-50% faster content download speeds due to the reduce amount of characters returned from the server, which is due to the reduction in overall fields returned (built in fields on custom data types do not need to be returned if using api objects) and reduction in characters because of lack of added suffix to data field names as custom data types do (ie: data field named as ‘name’ of type text is returned as ‘name_text’ rather than just ‘name’). As each of these additional characters on their own is not that large, when lists are smaller, the performance improvement as a percentage compared to normal custom data types is smaller, but as the list size increases the percentage improvement in performance goes up, which is just simple math based on characters returned and the overall content download speed.
What this all means, is I don’t think there are any limits, but computing power and overall data load should be considered when thinking about features to build with it. I personally, wouldn’t be spending any of my time putting features using any type of data that have 50K+ items downloaded at once.
But, if you have a 50,000 item product catalogue, you can load the first hundred to populate your search on page load, and once page is fully loaded, download the remaining if you’d want, but again, I wouldn’t do it myself, and instead I’d aim to find ways to load more or less only what is needed for the user.
I’m working on content that will help with that. In short, you can use it everywhere in an app as api connector objects or plugin objects work the exact same way in bubble as custom data types do, so can be used to set off database trigger change events, or in any dynamic expression. Due to that, the Hybrid Data Structuring approach that the plugin enables to be easily accessible to everybody (it is NoCode - and just Bubble), can be used to build any feature just as custom data types can. But, I wouldn’t advocate for people to just start building everything with the approach as there are definitely use cases where a custom data type is just likely better suited or the api connector object is just on par with so no reason to use. However, because the way in which you can use this is so incredibly flexible, it is easy to see how so many more features can be built into an app if thinking through the correct approach for the use case.
For example, it is possible to have an Option set in bubble with an attribute that is a file type. You can store onto that option attribute a json file with thousands of objects, and use that file URL as the URL in an API call from API connector. In my test it cost 0.72 WUs to download the 1,000 products (name, description, price). Because there are use cases for data that doesn’t change at all or very in frequently, this approach might be a good approach to take, especially if that data is fetched often. For that scenario, I have been building out my Data Exporter function that works with API connector objects and custom data types to export into multiple file types. The concept generally is that you could then use the base64 encoded value of the file to send into other APIs to send large amounts of data in a small payload (think chatgpt for in view on page data training in api call) but also to run the optional file upload to store that as an actual file object or just download it and upload via editor to the option attribute (or custom data type field). I have actions already that enable an update to 1,000s of objects client side that is really flexible (can alter specific fields to each object or update the same field on all - it’s json supplied modifications). Combining them will enable for the modification to a large data set stored as a json file. This also leads to features of data backups, changelogs (know who changed what field from what value when and from where in the app).
For me, it is huge. It helps me builder faster, more modularly, reduces WU consumption dramatically and improves performance, while also opening opportunities for features that are more difficult or too costly. In my mind, I can save WUs on searches in order to apply them to other features like notifications, data backups or changelogs.
Some of the recently added features are SEO related, so Structured Data that can be added to a Global Data Center. Working on the Export feature that can be added to a Global Data Center. After the Export feature will be more ways to Import (currently can just ask ChatGPT to give you the JSON structure and values or take from database and convert into api objects) which will also be built so that it is as flexible and modular as necessary to be functional in a global data center.
I’m adding elements and functions I’ve built over time that were needed for my applications, as well as building client apps with it now, and find areas to improve it with high focus on flexibility. One small tweak I made today was to switch out checkbox field values (they just evaluate to yes/no) for a yes/no field because the yes/no field accepts a dynamic expression which can be a multi-level in-line conditional to perform various conditional evaluations if necessary to result in the correct yes/no value - only need one action instead two with conditionals.
No worries, I’m glad you find it interesting and your thinking through ways it may be beneficial to you. I have not had enough time to start putting together all the content to help explain it all, but over time it will be released. In the meantime, feel free to ask any questions you may have, especially those that are use case related.
Reply to Ken (
that write up is way better than mine, I’ll have to interweave it into a landing page when I get a site up and running.