Remove all unbounded API calls from frontend about go-web-app HOT 2 OPEN

Starting to enumerate, we can create separate tickets for these if needed:

• https://github.com/IFRCGo/go-frontend/blob/develop/src/root/actions/index.js#L70 getRegionalProjects fetches a limit of 9999 - @frozenhelium do you know this one / why / can we mitigate?
• Same for getProjects: https://github.com/IFRCGo/go-frontend/blob/develop/src/root/actions/index.js#L115
• getCountries: https://github.com/IFRCGo/go-frontend/blob/develop/src/root/actions/index.js#L155 (this we probably just want to paginate on frontend).
• This is silly, just for the "Actions": https://github.com/IFRCGo/go-frontend/blob/develop/src/root/actions/index.js#L199 - I'm okay implementing exceptions on the API for things like this, but would rather just implement a consistent pattern of paginating on the frontend.
• getAppealsList: https://github.com/IFRCGo/go-frontend/blob/develop/src/root/actions/index.js#L232 - this one is the most suspicious to me -- need to dig in a bit more here - I believe the frontend does some aggregations and calculations here with the results, which seem like they should move to happening on the backend. But we need to dig a bit more into this one.
• getLastMonthEmergencies https://github.com/IFRCGo/go-frontend/blob/develop/src/root/actions/index.js#L297 - again, can probably just paginate here.
• getEventsList - gets all events in a country https://github.com/IFRCGo/go-frontend/blob/develop/src/root/actions/index.js#L341 - need to see where this is used exactly
• getSitrepsByEventId https://github.com/IFRCGo/go-frontend/blob/develop/src/root/actions/index.js#L366
• getAdmAreaAppealList https://github.com/IFRCGo/go-frontend/blob/develop/src/root/actions/index.js#L421 - again, this seems suspicious / like we should not need to fetch everything here.
• .....

Looking through, we actually have a LOT of instances where we make calls with a high limit value. I think for MOST of them, we just want to switch to doing pagination on the frontend. For MOST cases, it's really harmless - we need to display everything on a map, or in a dropdown, we know there will likely not be many results, but don't want to cap it, so we set a high limit -- just setting pagination with a page size of 100 or 200 on the frontend should be fine for these.

There's cases like the call for "Active Personnel": https://github.com/IFRCGo/go-frontend/blob/develop/src/root/actions/index.js#L576 that need to fetch all items to display in a single chart - all these cases I think we should just handle in the same way we did CSV pagination.

I think then the only one that I'm really concerned about is the fetching of Appeals like https://github.com/IFRCGo/go-frontend/blob/develop/src/root/actions/index.js#L232 - I can't see a good reason why we need to fetch ALL appeals from the backend. We need to dig more into that and see if we can swap out the logic there, perhaps by doing some aggregation on the backend. For the rest, I would advocate finding a good pattern to just moving all these instances to doing pagination managed by the frontend.

Also, @frozenhelium, could you just comment on https://github.com/IFRCGo/go-frontend/blob/develop/src/root/actions/index.js#L70 getRegionalProjects - if this is needed, we can use the same frontend pagination approach.

cc @frozenhelium @tovari @szabozoltan69 @tnagorra

from go-web-app.

Would you mind to review @batpad, if these still need to be resolved? Thanks.

from go-web-app.