latency in API calls

[eatyourpeas]

Currently with every API call this is some delay before the UI updates. Typically on button press in the user management pathway as lists of organisations are downloaded.

First we should put spinners on the buttons for htmx calls as we have done elsewhere and disable the button while the request is in flight, as we have done elsewhere.

Secondly though, is there any mileage in reanimating the persistence in session of the organisation list for the selects when the user logs in? This list should not change for the duration of the session and might reduce the amount of API calls and speed some of the load times

[mbarton]

is there any mileage in reanimating the persistence in session of the organisation list for the selects when the user logs in

I’m not sure it’s a good fit for session data but I think we do need a read through cache of org data for showing names rather than codes (#186) and that could also include relations between org and pdu.

[eatyourpeas]

Perhaps we could keep a simple list in a file on disk, say in the constants folder, which is kept up to date against the API periodically?

[mbarton]

The problem we'll have over time is that we won't remember everywhere that needs to be updated when we make the update upstream. Solving that problem would mean publishing the data versioned somehow (maybe a PyPi package as discussed before) and automating the version bumps in all consuming projects.

The read through cache doesn't have as much complexity, a the expense of not having data if the source API is down. But all NPDA needs to function should be the or and PZ codes which are hard-coded, although the UX would be degraded without the extra information.

[mbarton]

I don't think this is an issue any more? Please re-open if it is