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:

└ Api
  ├─ v1
  │  └ Controllers
  ├─ v2
  │  └ Controllers
  └─ v2_5
     └ Controllers

We faced difficulties and challenges to manages multiple versions in a single solution.

  1. There is a lot of code duplication
  2. There are many other things instead of just controllers, and if there is any change version specific, it becomes a puzzle.
  3. 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.

enter image description here

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

  1. Which is the best practice to in case of DB changes.
  2. 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.

  1. If you want to maintain one database and support multiple API versions, then you should handle this kind of validations in API and model layer. Just before the request hits the DB. Leave the schema untouched and flexible as much as possible. Else, you will break the API for existing customers and you will be forced to migrate them (which no customer likes).
  2. If you use separate databases, then it is like a completely different application. No need to sync data across versions. You may still need migration tasks to move customers over to newer releases.

IMHO, it is better to go with #1 above. Interested to see what others think.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.