Abstraction layers in Video API solutions

Let's see how migrations look like when you start using a Video API. So at first, before you migrate or think about obstruction or things like that, you're going to pick a vendor. That vendor gives you a kind of a Video API. That's the green part over here. And then you start connecting to it. So you've got the first module, you initialize the Video API, you start using it. There is another module in your application and some others that need to access this API. So you just access them directly. Why? Because it makes sense. You're building application from scratch, time goes by, you want to migrate to another vendor, you want to have the ability to migrate, you want to use your stuff or just put things in order and you go to this kind of a solution. You were trying to keep things simple. Which means that now I'm going to pick one of the modules that I have. Let's say this is going to be module C. I'm going to call the Video API only from module C. All the rest of the modules are going to interact with module C if they need to access the Video API. So I would need to have some kind of an interface or an API in module C that module A or B or D are going to call, and that would be C phoned into the Video API. This is the approach that I usually suggest starting with. Even so, if you are going to use a Video API in an external vendor, try to keep the modules or the source code files that try to interact with the Video API to the bare minimum. If you can limit that to one like module C here, that would be the best approach. Don't overthink it, don't over architect it. Just make sure that the access is done from a specific place only. This will make maintaining it a lot easier. Then when the time comes to replace the Video API with an Aventa vendor, you can just switch and change module C. Or you can go to this approach that supports multiple vendors. Now I have my Video API A and B. I'm trying to either migrate from one to the other or use two vendors until I migrate. Or just to be able to be cost effective or to use different vendors for different scenarios due to feature set or costs. Okay, whatever the reason is, and here what we need to do is to build a vendor agnostic abstraction layer. How do we do that? So we're going to do what we did before. We've got module C. Module C is the one that connects to Video API and all of the other modules are calling it directly. So what we are going to do is to simply switch and decide to which API vendor to call based on which one we want to use for that specific session or in this module C instance. Okay, that's one thing that we can do. The other thing that I would suggest at this point is to make the interface between module C and the other modules something that is known and that would be your abstraction layer interface. Now all of the modules know what they are going to connect to and module C is in charge of defining and picking and choosing which video API vendor to use. This makes switching in and out easier. It's still going to be challenging because they are different in behavior and capabilities, but it makes things a lot easier to maintain if you want to use a multi vendor approach. Okay, so we started with no abstraction at all. We move towards keeping things simple, which is where I think you should start, and then going to an abstraction layer, which I would refrain from doing unless I must because it's too much effort from my point of view. Thank you. And if you liked it, check out my video API report. There is a lot more information there about what to do with these video APIs, how to select them and how to approach development with them.