![]() To our fortune, REST and HTTP are ready to do the first part of the job for us. We need to find a way to replace microservice A version 1.0 (MSAv1.0) with version 1.1 (MSAv1.1), not only without breaking existing clients but having them utterly unaware of the change (in our example, microservice B, MSB). So, applying LSP to microservices, you don't want to break existing clients of the service, but replace it with a better or enhanced one. In other words, you don't want to break existing code but alter the behavior. The reason to follow LSP in OOP is to enable your code using type T1 to use type T2 instead, as T2 is a subtype of T1. Refactoring (enhancing the code structure). ![]() I can think of several reasons to build a new version: So, if my entity is a microservice, the equivalent entity is the new version of it. ![]() The reason why you usually have to replace a microservice is that there is a new version of it. The critical question now is, what an equivalent entity is in this context? Microservice Versioning I'm using the Edge API Gateway pattern, but regarding the discussion about LSP, we can also use the two-tier gateway pattern, micro-gateway pattern or a service mesh, the important thing is that microservices communicate through a proxy (the API Gateway). Microservice A will reference B through an API Gateway, and we'll try to comply with LSP. ![]() I'm going to give you an example where the entities are microservices, and the interface they provide is a REST API.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |