Recommended RPC architecture for Igntion 8.3 modules with multiple providers

[manuele.longhi]

Hello all,

I am currently in the process of migrating an Ignition module from version 8.1 to 8.3 and I've run into an existing architectural pattern that I need to either validate or refactor.

Currently, the module defines multiple Providers are defined (each with their own implementation), each of which is instantiated by the GatewayHook, Each of these Provider is then passed to a single, static RPCHandler. This handler acts as a proxy, duplicating every method from every provider to expose them via RPC.

Crucially, some providers are accessing this static RPCHandler instance to call methods that are implemented on other providers.

Is this architecture recommended for Ignition 8.3, or should I refactor this?

I have already started refactoring marking each of the Provider with the @RpcInterface tag, as well as implementing the getRpcImplementation() in the GatewayHook, returning

GatewayRpcImplementation.of(ProtoRpcSerializer.DEFAULT_INSTANCE,
    implementedProvider1,
    implementedProvider2,
    implementedProvider3,
    …
);

so I figure the old RPCHandler shouldn't be needed, am I correct? In that case, is there a way keep the submodules communicating?

Thanks

[paul-griffith]

First, here's my introduction writeup on the new RPC system:

ModuleRPCFactory to ProtoBuf

I'll reproduce the full 'dev introduction' document here - I wrote the thing, and there's nothing sensitive here. It'll eventually end up in the SDK docs, but no idea when. This is more general context about the whole thing and the technical details than purely a migration guide from 8.1 -> 8.3. The closest thing to a 'tl;dr' is the last ~third of part 2. Part 1

That may help enough on its own.
I'll also mention that the new RPC system is (deliberately) a lot more flexible and less dogmatic. Both the 'routing' layer and the 'serialization' layer are completely within your power to override and provide your own solution. RpcInterface, RpcDelegate, and the annotation based model are provided for convenience (and are what we use internally) but you don't have to use them if they don't fit your model. Ditto ProtoRpcSerializer; if you want to keep using Java serialization for your module we won't (can't) stop you.

The only underlying requirement (if you want to use our RPC system) is that your gateway hook returns a GatewayRpcImplementation. That interface contains RpcRouter, which you can choose to implement using whatever logic you want based on the incoming RpcCall triple (module ID will be static, but the package ID and function name can be used to disambiguate however you want). You just have to implement the routing function and return an RpcHandler, which is a relatively straightforward functional interface.

[manuele.longhi]

Thanks Paul! Very helpful (as always)

I missed that post on the forum, thanks for linking it