https://pact.io logo
Join Slack
Powered by
:thread: Thread on plugins :point_down:
# libpact_ffi-users
m
🧵 Thread on plugins 👇
First go (spiking Golang) - it works with standard HTTP request/response 🎉
I was thinking how the gRPC plugin would work with the current protobufs one. I’m assuming that 
pactffi_interaction_contents
is the interface for a content type plugin, and we’d add a new ffi interface for a transport plugin? i.e. you would want to use these things together, but I can’t see how this interface would support something like gRPC. If that’s the case, then the current PactHandle methods aren’t going to look very sensible.
Copy code
i.UponReceiving("some interaction").
		Given("plugin state").
		WithRequest("GET", "/protobuf").
		WithStatus(200).
		WithPluginInteractionContents(INTERACTION_PART_RESPONSE, "application/protobuf", protobufInteraction)
That’s the example Golang plugin test I ran before which worked 👌 But assuming that gRPC would have a separate interface, e.g. 
pactffi_plugin_transport
or something?
Copy code
i.UponReceiving("some grpc interaction").
		Given("plugin state").
		WithPluginTransport("grpc", <some json configuration object?>)
		WithPluginInteractionContents(INTERACTION_PART_RESPONSE, "application/protobuf", protobufInteraction)
u
The Java ans Rust ones work by configuring the interaction as current, then start a mock server from that. The mock server updates the interaction to use a gRPC transport.
m
So how would I signal to the mock server that it should be a gRPC one, I guess. Is there going to be a new FFI method or is simply adding the plugin enough for the mock server to convert to a gRPC transport?
u
I haven't got to the FFI interface yet
👍 1
m
One of the primary reasons I’m asking is because I’m trying to figure out what the next iteration of the DSL looks like to JS/Golang. I’ve got some feedback on a builder/type-state DSL, but I think the plugin interface is going to significantly impact that design. Ideally I just do it once. In JS, we added a very JSON-like interface:
Copy code
{
      state: 'i have a list of projects',
      uponReceiving: 'a request for projects',
      withRequest: {
        method: HTTPMethods.GET,
        path: '/projects',
        headers: { Accept: 'application/json' },
      },
      willRespondWith: {
        status: 200,
        headers: { 'Content-Type': 'application/json' },
        body: {},
      },
    };
This makes it super easy to convert other JSON structures to a Pact interaction. But you can see how the validation on this sort of structure would get super messy with plugins (and indeed, some of the features in v3). I’ll probably preserve it for HTTP pact, but I’d like a more type safe API going forward if possible. e.g. you shouldn’t be able to add an HTTP header to a message pact. Or, if using a different transport, you shouldn’t be configuring other things on the HTTP mock server
s
3 Views
Open in Slack
PreviousNext
Powered by