Currently, we have the module type in our GraphQL schema which contains functions that wrapper devs would implement but unlike plugin where plugin devs can easily extend the generated IModule interface, In the case of the wrapper, wrap dev needs to define the global functions with appropriate args, and return type. It would be more developer-friendly if we also provide an interface that developers can extend and provide an implementation for.
Let's take an example of a simple wrapper with the following schema:
type Module {
simpleMethod(arg: String!): String!
}
Now let's see how the codegen and wrap devx. would look like for Rust dev.
Here's how generated IModule interface would look for the simple wrapper with above schema
pub struct Module {
env: Option<Env>
}
pub trait IModule {
fn simple_method(
args: ArgsSimpleMethod
): String;
}
Here's how a wrap dev can implement the IModule trait for Module struct
impl IModule for Module {
fn simple_method(args: ArgsSimpleMethod): String {
return args.arg;
}
}
Methods that need to access env can access it with self.env.
Currently, we have the module type in our GraphQL schema which contains functions that wrapper devs would implement but unlike plugin where plugin devs can easily extend the generated
IModuleinterface, In the case of the wrapper, wrap dev needs to define the global functions with appropriate args, and return type. It would be more developer-friendly if we also provide an interface that developers can extend and provide an implementation for.Let's take an example of a simple wrapper with the following schema:
Now let's see how the codegen and wrap devx. would look like for Rust dev.
Here's how generated IModule interface would look for the simple wrapper with above schema
Here's how a wrap dev can implement the
IModuletrait for Module structMethods that need to access
envcan access it withself.env.