We're working with ASP.NET Core web API and looking for a couple of doubts that we have.
The versioning documentation recommended creating multiple controllers:
Contoso └ Api ├─ v1 │ └ Controllers ├─ v2 │ └ Controllers └─ v2_5 └ Controllers
We faced difficulties and challenges to manages multiple versions in a single solution.
- There is a lot of code duplication
- There are many other things instead of just controllers, and if there is any change version specific, it becomes a puzzle.
- Even there is no change in the previous version, we re-deploying it with the newer version. Which could be error-prone.
Hence, we come with the solution to run separate instances for each version and use path-based routing using the application load-balancer.
This works fine, but the actual problem starts here on which we need help.
Assume that we're using the MSSQL server to manage the database. Now there is schema and SP changes into a newer version
v1.1. Now, this becomes difficult as we have a single database and multiple versions to manage. Any changes into a newer version need to be compatible with the previous one; otherwise, an older version would break.
For example, we want to make mandatory phone-number for users while registering if they are using an updated app version(API version internally), so in schema level, we have to make it not null. But in this case, the older version would break. Thus we anyway need to make it nullable field.
So, here are the two main questions
- Which is the best practice to in case of DB changes.
- If we use separate databases with each version, how data of each version synced with each other?
Or any good recommendation to handle this situation; I am wondering, how these big app providers are managing app, API, and DB versions.