Brainstorm - grpc-labview v2.0 improvements (gRPC Server)

[jplotzke]

I am starting this discussion thread to brainstorm ideas that I’d like to see implemented for a grpc-labview v2.0. I feel like this incorporates many of the suggestions that are in the open issues list, but starting a thread here to try to tie everything together. Comments and discussion are welcome.

These ideas are focused on the gRPC server; I'll create a separate thread for gRPC clients.

Goals

My main goals:

• All data and method should be encapsulated as much as possible into classes (as opposed to having code outside of classes)
• No user code should be part of the generated codebase. Re-generating the server code should preserve all existing user code
• Server implementation should be expandable to allow for custom implementation
• Easy portability / reusability of gRPC services into other applications
• More streamlined experience for a new user to get started

Implementation

To achieve this, I propose that each service is comprised of two classes: a service class and an implementation class.

The service class is generated by the LV gRPC generation tool and inherits from ServiceBase.lvclass (as it does now). The intent is that no user code is present in this service class. Complete re-generation of this class should have no effect on an application.
The implementation class contains all user code and allows for further customization of the server if desired. The LV generation tool would only create stubs for each RPC method. If these stubs are already existing, the generation tool would not replace the method.

To achieve this, each lvlib generated by the LV generation tool would contain a single service only. If multiple services are passed into the generation tool, the tool should create multiple lvlibs/lvclasses. As a result, there is no code inside the lvlib that is not inside a class. All service messages, typedefs, descriptors, etc are now members of the service class.

Service Class

In the generated service class, both Start Sync.vi and Start Async.vi would be populated with calls to implementation methods by the generation tool. (Again, the intent is that the user performs no modification on the generated service class after generation)

Implementation Class

The generation tool would create stub methods for each RPC method. This stub would contain a Get … Request.vi and a Set … Response.vi method to help speed up development. These methods are still used (as opposed to just passing request/response values via the connector pane) to allow for streaming RPC methods, where multiple calls to the Get/Set methods are used.

The other intent of the implementation class is the ability to override Start Sync.vi and/or Start Async.vi to create a custom service implementation. For example, if one wanted to just have a single VI handle all RPC methods, this can be done by overriding Start Sync.viand creating a new event structure. Of course, the generation tool would not update the custom Start Sync.vi if/when new methods are added in the future. The intent is that creating these custom implementations would be an edge case and that the standard implementation methods would be used the majority of the time.

Another advantage of the implementation class would be if one wanted to purposely “leak” the user event to register directly into their application (and not use any event registration in Start Sync.vi/Start Async.vi), this could be implemented in the implementation class. My intent would be that Read Server RPC Methods.vi would move to protected scope, but the Server Internal Message UE.ctl typedef remains in public scope. This way, one has to purposely create a method in the implementation class to “leak” the user events but this can be easily done. Since the typedef from the server class is used, if the typedef is updated for additional RPC methods in the future, this would be automatically propagated through to the custom method.

gRPC Server

All control of the gRPC services would be encapsulated into the server methods.

Services would be registered to the gRPC server using a Register gRPC Services.vi server method. This VI would call the registration methods of those service classes (as was done previously separately).

Running the services would be done by the server in the Run Server.vi method. This method would asynchronously call the Start.vi method of all registered services and wait until all services are complete. Executing Start Sync.vi or Start Async.vi is decided by the defined Service Model property. If in the future, more models are defined in the base grpc-labview deployment, more selections can be added (For example, I could see eventually adding a truly async/callback-style implementation in the generated code)

In addition, this allows for potentially multiple different service implementations, which are chosen at runtime, which can be used with a single service lvclass code as the implementation class is the registered with the server.

Generation Tool

The generation tool should ensure that no user code is deleted during creation of a service.

• The service class should always be completed re-generated during each run of the generation tool.
• The implementation class should only be (optionally) generated if it does not previously exist. If the implementation class does exist, the generation tool should look if there are any missing implementation RPC methods. If any are missing, the generation tool should create those methods only.
• The generation tool should only create an lvlib if one does not already exist. If one already exists, the tool should just add the newly created service class and optionally created implementation class to it.

For a new user creating a gRPC server, I feel like the new implementation class methods are much easier to understand and develop than knowing which event structures need to be modified.

[jplotzke]

@jasonmreding - Not sure if you get notified on new discussion threads, but since we had chatted about some of this in previous PRs wanted to ping you. No urgency, just wanted to make sure you knew this was here.

[pettaa123]

Thanks for bringing this up. One thought I have is how two services, sharing the same message would be handled? Would we duplicate the messages into each class(services)?

[jplotzke]

Thanks for bringing this up. One thought I have is how two services, sharing the same message would be handled? Would we duplicate the messages into each class(services)?

Good question! I've done some comparing to how the gRPC parsing tools handle this for other languages to give this some thought.

As an example, let's say we have following proto files, services, and messages:

• 3 proto files
• ProtoFileA.proto and ProtoFileB.proto contain services. SharedTypes.proto only contains shared message types as is included into ProtoFileA and ProtoFileB
• ProtoFileA.proto contains 2 services. ProtoFileB.proto contains 1 service.

ProtoFileA.proto
├── Service1
│   ├── Method1_A (Request: Method1ARequest; Response: Method1AResponse)
│   └── Method1_B (Request: SharedRequest; Response: SharedResponse)
├── Service2
│   └── Method2_A (Request: SharedRequest; Response: SharedResponse)
├── Method1ARequest message
└── Method1AResponse message

ProtoFileB.proto
├── Service3
│   ├── Method3_A (Request: Method3ARequest; Response: Method3AResponse)
│   └── Method3_B (Request: SharedRequest; Response: SharedResponse)
├── Method3ARequest message
└── Method3AResponse message

SharedTypes.proto
├── SharedRequest message
└── SharedResponse message

In Python/C++, running the proto generator on ProtoFileA.proto and ProtoFileB.proto would result in 3 generated files -- one for each proto file. There would be separate classes generated for each Service and message types generated for each individual message.

If we take this over into LabVIEW, that would give us 3 lvlibs -- one for each proto file, but separate classes for each service. Something like this:

So:

• LabVIEW would generate one lvlib for each proto file being passed to the generator. If a proto file includes another proto file, separate lvlibs would be generated (one for each separate proto file)
• An lvclass would be generated for each individual service defined in the proto files. If multiple services are defined in a single proto file, multiple lvclasses would be generated in that lvlib.
• Messages would be defined in each separate lvlib, outside of the lvclass (this case makes it more obvious why that's done in the current release -- In gRPC, messages are not tied to a specific service)
• In the case of a shared message, these services would use the shared lvlib message types. If ProtoFileA.proto was generated from at a different type from ProtoFileB.proto, the generator would still link to SharedTypes.lvlib and not create a bunch of new types.

This scales back the original proposal a bit that aligns more to how the current generation is done. I still see the key differences being:

• Separate (multiple) lvlibs would be generated based on a 1:1 relationship from proto file to lvlib
• Shared message types would be shared between services, even if the generations are done at different times
• Separate implementation class still holds to ensure no user code is part of the generated code

Does that make sense to you? I like trying to align the LV generation to how the existing proto generation tools in other languages are based. If you don't see any immediate flaws, I'll update my original post incorporating these suggestions.