How to handle dependent data

[ghost]

So I have a set of API routes that correspond to related data like so:

- /api/company
- /api/team
- /api/employee

The employee has a foreign key to team and team has a foreign key to company. Obviously I could use useSWR to fetch all the data at once like so:

const { data: cData } = useSWR("/api/company");
const { data: tData } = useSWR("/api/team");
const { data: eData } = useSWR("/api/employee");

My idea is to have a master detail UI where I have a list of companies. I can click a single company to get a list of teams. I can click a team to get a list of employees. However, what should happen if I delete a team with id 2? I'm just confused on how to handle mutations such that related cascade deletes. Furthermore if a local component usesSWR on /api/team/2 for example, wouldn't I have to mutate that unique key as well? What's the best way to handle relational data? At the moment I'm using Redux-ORM but that's probably overkill.

[sergiodxa]

You can trigger a revalidation of all the keys you know/suspect have the deleted item, if you delete the team with id 2 you may want to do mutate('/api/team') and mutate('/api/team/2') to revalidate both.

[ghost]

Is there a more effective way to structure the api to work better with useSWR?

[sergiodxa]

If I were going to build an API to work exceptionally well with SWR, I would make lists only return the sorted IDs and probably pagination data if required. This way the /api/team will only return a list of team ids like [1, 2, 3, 4, 5] then I will render each ID in its own component and make a new useSWR call to get that specific team (e.g. /api/team/2), this way I know any change to a team data should go to the key /api/team/:id and nothing else, only deletes would need to update both the list and the item, and probably only updating the list could also be enough too (if it's not in the list anymore you are not going to have a way to access it through the UI).

In case you are worried this could cause a lot of requests, yes, it would, however you will be able to also cache them better since you can cache each individual team and the list, a change to a team would only need to invalidate a single cached request instead of two possible ones (and more if you cache the sorted versions of the list), this cache would help you reduce the impact of multiple requests, combined with HTTP2 should not be a big deal.

However, there is no need to do any change to your API, SWR works perfectly with any kind of API, REST, JSONAPI, GraphQL, etc. even with non standard formats, and remember SWR will revalidate the data after a component is mounted again so if you update a team you can update it right away in the specific team cached key and once the user go back to the list it will see the stale date while SWR revalidate it and it will be updated, the whole idea of using SWR is to accept you will not have strong consistency but instead you will have eventual consistency, where things are going to eventually be consistent everywhere (more details about this will come soon to the website of SWR).

[ghost]

Ok I understand. I was just hoping there would be a way to reduce the number of requests. You see in my UI I have a list of tables with foreign keyed items appearing on a single page. Even if I paginate the tables to size P the number of requests to initially load that page before caching it P * N + 1 where N is the number of tables.

I get that caching will reduce the display of data on the page because it will just use the stale data in the cache but if I renavigate to that page with tables from another page it's still going to call a revalidation request P * N + 1 times to account for the separate counts of useSWR, no?

[sergiodxa]

Yes, but remember if you put a CDN on top of your API and cache your responses there, even if you do multiple requests it should not cause a big problem, most of them will not be processed again, only the updated items will need to be reprocessed.

But if this is a problem, you will need to have a list with the data and be sure to revalidate both, individual items and list.