How to grasp the interface granularity of micro-service layer

suppose there are four classes
class Product {

private Long productId;

}

class ProductImage {

private Long productId;

private Long productImageId;

}

class ProductAttachment {

private Long productId;

private Long productAttachmentId;

}

class ProductDto extends Product {

private List<ProductImage> images;

private List<ProductAttachment> productAttachments;

}

in the micro-service architecture, the service interface is designed as follows:
1 Fine granularity: provide three separate interfaces, which are called by other services to obtain data, and return directly to the front end
interface ProductService {

after the Api gateway aggregates and synthesizes the ProductDto.
Product getProduct(Long productId);

List<ProductImage> listProductImage(Long productId);

List<ProductAttachment> listProductAttachment(Long productId);

}
2 coarse granularity: provides an aggregation interface, which is called by other services, and the Api gateway only forwards and returns to the front end
interface ProductService {

ProductDto getProduct(Long productId);

}

which way do you prefer, and how to grasp the interface granularity of the service layer?

Mar.04,2022

it all depends on the business you want to support.
first of all, I assume that you develop api using the restful specification. So, if there are no list product images or list product attachment requirements in the real business, then there is no need for development at all.

if you want a more dynamic and flexible approach, I recommend graphql . It is entirely up to the client to decide granularity .

Menu