Naming conventions for grpc service implementation

by ailav   Last Updated August 13, 2019 15:05 PM

Moving from REST to grpc microservices with Spring and Java. With REST the layered architecture is so straightforward for me - you have a Repository, Service and Controller. Now with grpc and protobuffs the situation is a little different.

Let's imagine I have an entity called Employee - again I have EmployeeRepository for DB-related operations, EmployeeService - for business logic but with the Controller things are little different because in protobuf in addition to the model Employee, I'll have an EmployeeService which will define my API contract. In Java world that is the equivalent to a Controller really, so how do I name them?

Option 1: EmployeeServiceImpl - I don't like it. It's confusing because in Java world it is not really a service or implementation of one.

Option 2: EmployeeController - it's more appropriate for me in terms of properly defining layers but still feels a little strange because we'll have code like this

public class EmployeeController extends EmployeeServiceGrpc.EmployeeServiceBaseImpl

and it looks like Controller is extending a Service, which might also look confusing.

Any thoughts or maybe articles, helpful materials I can use on settling on one of those or in general choosing the most proper approach in the case?

Related Questions

Version-postfixed class name for REST api

Updated August 19, 2016 08:03 AM

Method naming: to vs as vs get

Updated April 25, 2018 02:05 AM