RTK Query: baseUrl, scaling, and microservices

[azangru]

I understand Redux team's recommendation is to have as few api slices as possible; ideally, just one. I've also heard that the recommended way of growing an api slice is via the injectEndpoints property of the slice.

In view of this, I would like your advice on how to scale the api slice to talk to various microservices. Consider the following four examples:

Example 1

Given two services, one at /api/service-one, and the other at /api/service-two, both of which are roughly restful, i.e. have different urls for different endpoints, how would you model the api slice? I am particularly interested in the value of the baseUrl parameter in the following code snippet from the docs:

const api = createApi({
  baseQuery: fetchBaseQuery({ baseUrl: '/' }),
  endpoints: (build) => ({}),
})

Example 2

Same two services as in example one above; but now hosted at different hostnames: one at https://service-one/api, and the other at https://service-two/api. Will this make any difference for the modelling of the api slice as compared to Example 1? What would the value of the baseUrl option be?

Example 3

Two services, but now they are speaking different json dialects: one, at /api/rest, is roughly restful; the other, at /api/graphql, is graphql. Would this require two api slices, since the baseQuery functions are going to be different?

Example 4

A combination of example 1 and example 3. Four services now, with two being roughly restful (/api/rest-one, /api/rest-two); and two graphql (/api/rest-one, /api/rest-two). How many api slices would you suggest creating — two or four? What should the baseUrl option be?

[EskiMojo14]

Example 1

I would set baseUrl to '/api'. You'd then have separate endpoints with '/service-one' and '/service-two'.

Example 2

It depends on how related the data returned might be. The main reason you'd want to have as few API instances as possible is that you can't use providesTags and invalidatesTags for automated refetching between API instances - it only applies for the given endpoint's API slice. There are of course also (mild) performance concerns when you have more API instances, since that's more middleware to run and more reducers.

You can provide a full URL (e.g. 'https://service-one/api') for a given endpoint, and baseUrl will not be used (joinUrls, isAbsoluteUrl). You can use this to fetch from your different domains while using the same API instance with fetchBaseQuery.

You could also decide that they're completely unrelated, and you're okay with having them in separate instances.

Example 3

Normally you would need separate API instances for separate base queries, yes. However, I wrote a recipe over at #3161 that allows you to create a "polymorphic" base query that discerns which base query to call based on the arguments provided to it. I use this at my work to use the same API instance for both REST fetch requests and AWS Amplify GraphQL queries.

Example 4

Essentially the same as above, the answer is "it's up to you". If they were all related data that I wanted to be able to invalidate each other, then I would use one API instance and a polymorphic base query. If the GraphQL endpoints were all entirely unrelated to the REST ones, then maybe it would be okay to have separate API instances for them. I'm not sure I would ever want 4 API instances for that setup, though.

In general I've found that the benefits of keeping it all in one API instance have outweighed the downside of the necessary workarounds to keep it that way (absolute URLs, polymorphic base query).