2. Conceptual Overview - Plugin Framework
Introduction to Plugins​
Goals
The Pact Plugin Framework was created in order to:
- Expand support to the widest range of use cases
- Improve time-to-market for new features
- Grow our community (users + contributors)
The framework allows users to extend Pact by creating new types of:
- Transports (e.g. gRPC, Websockets)
- Protocols (e.g. protobufs, GraphQL)
Interaction types
Pact has three types of interactions:
- Synchronous/HTTP - models standard HTTP interactions
- Asynchronous/Messages - models unidirectional events/messages
- Synchronous/Messages - models bi-directional or streaming events/messages

The combination of these interaction types with new transports and protocols, enables you to model almost any type of API and support any use case.
Conceptual Overview​
Diving a bit deeper, let's look at the various system actors and how they work together with Plugins.

- Your code 😉 
- The test framework executing tests e.g. Jest, JUnit 
- The Pact Client library used in the test e.g. Pact JS, Pact JVM 
- The Shared Core (Rust) or the Java Plugin Driver (for JVM projects) manages the lifecycle of a Pact test and provides key capabilities to client libraries. It oversees the use of plugins via the Plugin Driver 
- Plugin driver is responsible for discovering, starting and orchestrating plugins. 
- Plugin may communicate to/from the SUT e.g. in the case of a new transport it will serve as the mock server, and will also issue verification requests at the Provider API 
- The pact file contains additional information - Required plugins
- Transports
- Interaction type
- Markdown to display interactions