paulc4
commented
4 years ago The service classes expose each use-case offered by the underlying microservices - in this case everything you can do with products, carts and payments. How you expose them in the web microservice is up to you. One web-controller per service and one service per microservice is the model I have used.
One big web-controller or service is not recommended. Indeed, in a large system you might break the service class into multiple classes, handling different functionality groups (but talking to the same back-end microservice) driven by one or more controllers.
In a small system the number of classes seems excessive, but there are advantages:
- You can mock each service and test just the web-controller
- both in a JUnit test and using Spring's MockMvc framework to imitate incoming HTTP requests
- You can drive the services programmatically in a test, ignoring the web-layer
- Any additional business logic needed can be put in the service classes
- For example to co-ordinate actions across multiple microservices in the same request
- Some requests may involve using more than one microservice, so a single web-controller may invoke methods on 2 or more services
If you combine each controller and service into a single class, this would not be possible. And the resulting combined class can quickly become a lot more complicated that you expected.
Similarly having just two classes (your proposed WebController and WebService) is not scalable and eventually would have to be split up.
Bottom Line: You are doing extra work up front for flexibility and scalability later.
Whatever you decide, make sure to justify why you have chosen the architecture you did when you submit your project.
I hope this is helpful and that you are keeping safe. Paul.
blancaat
Hi @paulc4, I'm a computer science student who's about to finish my career. I'm working on a project that involves making a website through microservices and to inform myself I've been analyzing your code. My architecture would be based on four microservices: web-service, products-service, cart-service, and payment-service.This is where my doubt comes in. You in the project have included the WebAccountsService and WebAccountsController classes to manage the account-service information. What would happen when I want to include controllers and services to handle information from the rest of the microservices? Should I create more classes of the style 'WebProductsController"? I don't think because there would be a project with many classes. I also don't know if it would be good practice to create two classes, WebController and WebService, to handle all the information (WebService would contain all microservices access URLs). I've searched the internet for information but I know there are several ways to approach web UI management in microservices. Thanks! :)