I'm building a simple app which pulls segment definitions from Adobe Experience Platform API to a webpage. I've got some doubts about how I set up my backend action. The action triggers whenever the app gets started or refreshed. It then queries a particular endpoint and adds all paginated results into a single object before the object is returned. It other words a large chunk of JSON is provided in the response each time the action runs.
Ultimately I expect 5-8 users to regularly use the app and the same process of calling the API and sending a large JSON to the front end will be repeating itself over and over. Being new to web dev I'm curious if this was a good practice or maybe a burden on runtime or the API itself. Perhaps file storage should be used to avoid constant querying of the API ?
For now the app works so and I'm thinking that for as long as my action does not exceed the 1mgb result limit there is not much to worry about, though I've not had the app published yet. Any comments would be much appreciated.
Here is a page with the standard list of limitations around Actions.
As you can see 1mb is the max result you can return so you have some limitations about how big your data can grow before you need to do Paging of the result set.
If the data you are retrieving from AEP does not to be real-time I would recommend catching the data then giving the users the same result setup until a time period has passed where the data would be too old to be considered useful in the app.
For example, if your app only needs to show yesterday's results in a dashboard you would only want to run the report once a day and store it in either STATE or FILE store.
In the use case above where I only have to store the data for a day, I would probably use the STATE store. It's simple to use and you can easily set the data to expire after a day. I would set the KEY to today's date like 7-19-2021 and store the result set in the provided 2mb value.
Here are some state limitations to be aware of.
'/', '\\', '?', '#'
Using File as caching would work as well and is not a bad way to do it as well.
I would definitely put caching in place though to greatly speed up the application and to reduce the unneeded overhead on AEP.