API Gateway handling Webservices in a Microservice Architecture

1
votes

I have an architectural question. We are transforming an old Monolith to a Microservice Architecture. Therefore we have in plan to identify the bounded contexts and make Microservices out of these.

To keep up with our public API we will have an API Gateway which routes the stuff properly. The internal communication will be done via REST (at the first shot). Unfortunatelly our existing public API is about WebServices most of the time.

If we do transformation from Webservices to REST communication we already need to know stuff of the Domain Objects. Isn't that already a violation of the Microservice Design. In the end that means adding a field in the Microservice A implies also touching the API Gateway. Which I do not like.

Am I wrong here? What is your opinion on this?

enter image description here

2
web-servicesrestarchitecturemicroservices

2 Answers

1
votes

Don't see any violations here if you are not going to use your domain entities as input parameters to your internal REST services. Use plain old DTO objects as input parameter and then map them to your domain objects.

Also I wouldn't go with API Gateway solution if I were you. I understand you are trying to make your changes transparent for your API clients but the API Gateway adds a redundant step and it might cause performance problems.

I suggest doing the following:

  1. Extract domain logic into reusable libraries, so they can be used by both old and new API.
  2. Build a new version of your API using the libs from item #1
  3. Make sure all your new clients are using the new API and promote it among the old ones

Yes, it won't be easy to support both API's for some time but you will get rid of that API Gateway in the long run.

0
votes

If my understanding is correct (see my comment in Maksym's replay), your API gateway is similar to a ESB as in SOA. If that's the case, you can borrow a few common patterns in ESB to help address your concern. In ESB, we frequently put in customized adapters to translate message format between services or between services and open standard. In your case, you will need to introduce an extra layer in your API gateway to translate the public API's data models to the data models MS A and B understand and vice versa. By doing that the public API and MS A and B are still loosely coupled. It's true you will have to make changes to the adapters if data models in either MS A and B or the public API changes. But its impact will be minimum as the adapters are so light weight they are designed to be replaced quickly.