Why the recommendation for a single API slice per app?

[joeattardi]

Our app is very large and we have a lot of different endpoints. One idea that's been suggested is to have a different API slice per "domain object" in the API. However, I see many times the strong recommendation to only have a single API slice for the whole app, or at least for a given base URL.

I am trying to understand this recommendation a little better. Is there a disadvantage to splitting up into multiple API slices?

[markerikson]

As covered in our docs ( https://redux-toolkit.js.org/rtk-query/api/createApi ):

Typically, you should only have one API slice per base URL that your application needs to communicate with. For example, if your site fetches data from both /api/posts and /api/users, you would have a single API slice with /api/ as the base URL, and separate endpoint definitions for posts and users. This allows you to effectively take advantage of automated re-fetching by defining tag relationships across endpoints.

This is because:

• Automatic tag invalidation only works within a single API slice. If you have multiple API slices, the automatic invalidation won't work across them.
• Every createApi call generates its own middleware, and each middleware added to the store will run checks against every dispatched action. That has a perf cost that adds up. So, if you called createApi 10 times and added 10 separate API middleware to the store, that will be noticeably slower perf-wise.

For maintainability purposes, you may wish to split up endpoint definitions across multiple files, while still maintaining a single API slice which includes all of these endpoints. See code splitting for how you can use the injectEndpoints property to inject API endpoints from other files into a single API slice definition.

Splitting endpoints should provide all the same conceptual / structural benefits of having multiple separate API instances, but with less overhead. The only potential issue is name collision. That's a case where it is up to you to make sure each endpoint name is unique. (There's been some requests for some sort of namespace prefixing, and it's not something we've tried to look into yet.)

[joeattardi]

Thank you for the explanation, that makes it much clearer to me!