I have two services that communicate with each other using gRPC. In a situation, service1 asks service2 for a camera list and this is by now a unary request. But the list can be changed during the time, even every month or many times in a single hour or never at all in a long period.
So to get these updates I think I have three simple solutions using the gRPC protocol.
1- Make the main procedure server stream instead of unary.
2- Service1 gives service2 another unary procedure to be called on changes.
3- Service1 calls service2 procedure (the origin procedure) periodically.

Although the gRPC server stream seems very good for this solution (as the real-time vehicle example mentioned in this article) and gives good cohesion to my code, I have some worries (as the real-time update rate is very low often):
1- Is memory usage of server streaming (keeping procedure scope live) efficient for this use-case?
2- Keeping the stream live (re-request after failure) takes resources. Is it OK again for this use-case?
3- Is it good to use the gRPC server stream for a lifetime (endless) running stream (getting real-time updates) at all, or it is designed for limited streams?