Architecture: One giant servicer of many services vs. one servicer per service?

[Kakyo Kickass]

Setup

• My app uses gRPC for frontend/backend separation
  
• Backend (server + services) is written in Python
  

Goals

I'd love to achieve hot-updates including:

1.  Updating existing services
   
2.  Adding new services
   
3.  Removing services
   

Problem
I can achieve #1 by using Python's `importlib` feature. But there are fewer options for adding/removing services. It seems to depend on the app's gRPC implementation. The major constraints seems to be the fact that servicers can only be registered before running the server, i.e., through the call to

```python
add_MyServiceServicer_to_server()
```

So does adding reflection support, which is through the call to


```python
service_names = [
    MyService_pb.DESCRIPTOR.services_by_name[''].full_name,
    ...
]

reflection.enable_server_reflection(service_names, my_server)
```


Solution Candidates

• Approach 1: Having one servicer per service, much like [the official `SayHello` example of gRPC][1]
  
• Approach 2: Have one giant servicer that includes all the other services as its RPC methods.
  

Approach 1 seems to be intuitive, but it won't support adding/removing services while the server is running.

Approach 2 seems promising, but it is confusing by sticking the entire universe in a single servicer. And I'm not sure how gRPC's thread pool would like this approach.

Questions

• Can I achieve my goals with these approaches? 
  
• If true, which one is better in terms of both maintainability and performance?
  
• If false, are there alternatives?
  

  [1]: https://github.com/grpc/grpc/tree/master/examples/python/helloworld