你会在 .NET Core web/api 应用程序中的什么地方实现缓存？

Question

I have the following architecture:

• .NET Core 3.0 web application using razor pages for the UI
• .NET Core 3.0 web api application serving all the data to the web app. It talks to the database via Entity Framework

I am not doing a lot of complicated operations on the data. Most of the APIS are basic CRUD operations. That said, I want to eliminate unnecessary trips to the database and for long term scalability I want to implement a caching layer in my application.

What I am debating is in which layer to implement the caching layer? Let's use an example of the app displaying a list of your upcoming appointments.

Option 1 -> Do it in the web app. I could implement a factory or similar pattern where the web app no longer talks directly to the api. It could ask the appointment factory for my appointments, and the factory would check cache first. If its not there, it would hit the API, and then cache the result. However, unless I also made sure that any creations/updates also happened through the factory, the cache would not get updated if the data changed.

Option 2 - Do it in the web api app. I could essentially treat the API as a factory. Since I already know that all data manipulation will happen through the API, I can be assured that any time the data changes, I would know about it and could update the cache appropriately.

I don't know if I love the idea of doing it at the web api layer. Part of me feels like the API should just do one job - put data into the database and get data out of the database. Maybe it shouldn't be making decisions on whether or not the calling app/user wants to use a cached value or not.

I would love to hear any insight into your real world experiences with one or the other - and if you had to do it over again, would you do anything different? Are there long term benefits to one solution?

Answer 1

I would (and do) do this in the API for a number of reasons:

• It makes the API the central place where you ask for data.
  How it decides where that data comes from (cache, DB, another API, etc) is up to the API, and the UI doesn't have to care.

• By making the API the "master", you can create other applications which use it, and the data is always consistent.

• At some point you have to send the data to the API anyway so that it is persisted. One or more equivalent caches of data at the front end are going to be wrong at some point or out of alignment. Send it to the API, and use what the API returns. No thinking about it necessary.

• If you need to purge the cached data for some reason, you have one place to do it, rather than on every client.

• It keeps the presentation layers lighter.