Skip to content

Commit 66d5b3c

Browse files
authored
Create README.md
Added readme for plugin framework.
1 parent 86bf3a5 commit 66d5b3c

File tree

1 file changed

+139
-0
lines changed

1 file changed

+139
-0
lines changed

pkg/plugin/README.md

Lines changed: 139 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,139 @@
1+
# BECKN-ONIX Plugin Framework
2+
3+
Welcome to the BECKN-ONIX Plugin Framework! This repository provides the core components to build your own custom, modular, and extensible Beckn Onix SDK. You can pick and choose your own technology stack, whether it's multi-cloud, open-source, or your own proprietary services.
4+
5+
## Why Use a Plugin Framework?
6+
7+
We have out-of-the-box Beckn Onix SDKs available for different technology stacks. However, in case you want to further customize your setup, this framework provides the tools to do so.
8+
It was designed by the core team of FIDE and Google Cloud engineers, with a plugin-based architecture to give you maximum flexibility.
9+
10+
-**Multi-Cloud & Hybrid-Cloud**: Mix and match services from different cloud providers. Use a cloud KMS for signing, your chosen cloud storage for media, and a self-hosted database.
11+
-**Open-Source Integration**: Plug in open-source tools like Prometheus for monitoring, Jaeger for tracing, or RabbitMQ for async messaging.
12+
-**No Vendor Lock-In**: Easily swap out a component or service provider without rebuilding your entire application.
13+
-**Extensibility**: Add your own custom functionality by creating new plugins that meet your specific business needs.
14+
15+
## How It Works: Core Concepts
16+
17+
The framework is built on a few key components written in Go.
18+
19+
### Plugin Definitions
20+
21+
This is the contract. It's a Go library that defines the interfaces and structs for every type of plugin. For example, it defines what a Signer or a Logger must be able to do, without worrying about how it gets done. Your application code will depend on these interfaces.
22+
23+
### Plugin Implementations
24+
25+
This is the logic. An implementation is a specific tool that fulfills the contract defined in the Plugin Definitions.
26+
27+
- A **Default Implementation** might provide basic, sensible functionality.
28+
- A **Custom Implementation** is one you create. For example, you could write a MyCustomSigner plugin that implements the Signer interface using your preferred signing service.
29+
These implementations are built as standalone Go plugins (.so files) that can be dynamically loaded at runtime.
30+
31+
### Plugin Manager
32+
33+
This is the conductor. The Plugin Manager is the central access point for your application. It reads a configuration file, loads the specific plugin implementations you've chosen, initializes them, and makes them available to your application logic.
34+
35+
## Getting Started: Building Your Custom SDK
36+
37+
Let's walk through how to use the framework to build an SDK with a custom plugin.
38+
39+
### Prerequisites
40+
Go (latest version recommended)
41+
Git
42+
43+
### Step 1: Understand the Plugin Classes
44+
45+
First, familiarize yourself with the available plugin "slots" you can fill. These are defined as interfaces in the Plugin Definitions library. Core classes include:
46+
- Cache: For in-memory storage.
47+
- Decrypter: Handles message decryption.
48+
- Encrypter: Handles message encryption.
49+
- KeyManager: Manages cryptographic keys.
50+
- Middleware: For implementing custom middleware logic.
51+
- Publisher: Handles asynchronous message publishing.
52+
- Registry: For looking up network participant details.
53+
- Router: For routing requests to the correct service.
54+
- SchemaValidator: Validates Beckn message schemas.
55+
- Signer: Signs outgoing Beckn requests.
56+
- SignValidator: Validates incoming request signatures.
57+
- Step: Represents a single step in a transaction pipeline.
58+
59+
### Step 2: Implement a Plugin
60+
Choose a class you want to customize. For this example, let's create a simple custom logger.
61+
62+
Create your plugin project:
63+
```
64+
mkdir my-custom-logger
65+
cd my-custom-logger
66+
go mod init my-custom-logger
67+
```
68+
69+
Implement the interface: Create a main.go file. In this file, you'll implement the Logger interface from the Plugin Definitions package.
70+
```
71+
// main.go
72+
package main
73+
74+
import (
75+
"fmt"
76+
"[github.com/beckn-onix/plugin-definitions](https://github.com/beckn-onix/plugin-definitions)" // Assuming this is the path
77+
)
78+
79+
// MyLogger is our custom implementation.
80+
type MyLogger struct{}
81+
82+
// Log fulfills the interface requirement.
83+
func (l *MyLogger) Log(message string) error {
84+
fmt.Printf("MY CUSTOM LOGGER >> %s\n", message)
85+
return nil
86+
}
87+
88+
// Export a variable that the Plugin Manager can look up.
89+
// The variable name "Provider" is a convention.
90+
var Provider plugin_definitions.Logger = &MyLogger{}
91+
```
92+
93+
### Step 3: Configure the Plugin Manager
94+
95+
The Plugin Manager uses a yaml file to know which plugins to load. You'll need to update it to point to your new custom plugin.
96+
```
97+
# config.yaml
98+
plugins:
99+
logger_plugin:
100+
id: "my-custom-logger" # The unique name/ID for your plugin
101+
# ... any config your plugin might need
102+
signing_plugin:
103+
id: "default-signer"
104+
# ... other plugins
105+
```
106+
The id here is crucial. It tells the Plugin Manager which .so file to look for.
107+
108+
### Step 4: Build and Run
109+
110+
- Build your plugin: From inside your my-custom-logger directory, run the build command. This creates the shared object file.
111+
112+
```
113+
go build -buildmode=plugin -o my-custom-logger.so
114+
```
115+
116+
- Place the plugin: Move the my-custom-logger.so file to a known directory where your main Beckn Onix application can find it (e.g., /plugins).
117+
- Run your application: When your main Onix application starts, the Plugin Manager will read config.yaml, see the my-custom-logger ID, load my-custom-logger.so, and use it for all logging operations.
118+
119+
## Plugin Development Lifecycle
120+
121+
### Implementing a new Plugin for an existing Class:
122+
123+
- Create a new Go project for your plugin.
124+
- Implement the required interface from the Plugin Definitions package.
125+
- Define any configuration your plugin needs.
126+
- Export the necessary symbols for the Plugin Manager to discover.
127+
- Build the plugin as a .so file.
128+
129+
### Adding a new Plugin Class to the Framework (Advanced):
130+
- Add the new interface and required structs to the Plugin Definitions package.
131+
- Update the Plugin Manager to handle the loading and execution of this new plugin class.
132+
- Update the Plugin Manager's configuration struct if needed.
133+
134+
## Support
135+
136+
If you have any questions, face any issues, or have a suggestion, please open an issue on this GitHub repository.
137+
138+
139+

0 commit comments

Comments
 (0)