https://github.com/adonese/weaver
https://github.com/adonese/weaver
Last synced: 5 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/adonese/weaver
- Owner: adonese
- Created: 2024-08-17T19:47:37.000Z (almost 2 years ago)
- Default Branch: main
- Last Pushed: 2024-08-23T11:07:42.000Z (almost 2 years ago)
- Last Synced: 2025-10-24T14:51:44.439Z (7 months ago)
- Language: HTML
- Size: 336 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Exinity payment gateway
This program simulates a payment gateway solution. In payment terms we call those Escrow Integration, or Service Providers Integrations. This system processes deposits and withdrawals requests, while providing a callback to update a transaction status. One simple scenario for this is an Exinity user who wants to "withdraw" some of their funds from their exinity wallet, to their bank account. In this case, we can call the withdraw api and that will initiate the transaction, and we provide a webhook (this callback) to the bank such that when the transaction is completed in their end, they will trigger this webhook (callback), for us to update the transaction status.
## How to run the program
The program uses generated file(s) from weaver namely `weaver_gen.go`
- Make sure that go is installed on your machine
- Clone the repo, `git clone https://github.com/adonese/exinity`
- cd into the project directory
- download depenencies `go get`
- run `go build -o payment_system`
- run `./payment_system`
### optional steps
- install weaver cli tool, `go install github.com/ServiceWeaver/weaver/cmd/weaver@latest`, to generate weaver files
- run `weaver generate`
## What is weaver?
Service Weaver is a new framework for writing microservices (modular monolith) in Go. It is very interesting in that, it has the benefits of the both worlds:
- for monolith, you still write your application the same way you would write a typical monolith application: a single binary that is `go build`-able
- that same single binary runs as separate microservices, managed by the service weaver runtime.
So essenatially, one gets the benefits of ease of develpment of a monolith, and the benefits of a microservice architecture.
`weaver.toml` is the configuration file for the service weaver runtime, it is a very compact toml with only `binary` as required field.
## Tests
The program is composed of an integration test that tests the full flow of a transaction from initiation to completion. You can run the tests via `go test -v ./...`
## Design decisions
- we decided to keep the backing storage of the transactions in memory, for the sake of simplicity and shared for both gateways
- unit tests for http handler; why? and not the full code. Well, for the starter this follows my philosophy and also experiance with payments: once an api is released we should respect that and never change it, that's why the emphasize for me was doing this integration testing as oppose to 100% coverage.