README
¶
Pipehub
A programmable proxy server. Please, don't use it in production yet! It's nowhere near stable and changing too much.
Why?
Software development is getting harder and harder, on a typical medium/large solution there are lot's of servers at the request path: API Gateways, Load balancers, Cache servers, Proxies, and Firewalls, just to name a few. These generate latency and require much more engineering and monitoring to do it right.
The core idea of this project is to do more with less. pipehub being a programmable proxy, users can extend and customize it as needed. Features found in other servers can be added with Go packages instead of actual external services.
How?
The code is extended with a thing called handler. It's a plain old Go code that is injected at compile time at the application. Being a Go project gives much higher flexibility at the handler because it can really be anything.
Bellow a configuration sample:
server {
http {
port = 80
}
}
host {
endpoint = "google"
origin = "https://www.google.com"
handler = "base.Default"
}
handler {
path = "github.com/pipehub/handler"
version = "v0.5.1"
alias = "base"
}
The handler points to the place where the Go code is, it should be a go gettable project. A handler is a generic processor that can be used on multiple hosts. A host track the endpoint the proxy gonna listen, where the origin is, and which handler gonna be used to process the requests.
A real example of a handler can be found here.
How to run it?
First, create a config file:
cp cmd/pipehub/pipehub/pipehub.sample.hcl cmd/pipehub/pipehub/pipehub.hcl
# edit cmd/pipehub/pipehub/pipehub.hcl
Generate the binary:
make generate
Execute it:
./cmd/pipehub/pipehub start -c ./cmd/pipehub/pipehub.hcl
It's also possible to build from a docker image, just need to pass the config and a directory where the binary gonna be writed:
docker run --rm -v $(pwd)/pipehub.hcl:/pipehub.hcl -v $(pwd):/pipehub/output pipehub/build:0.1.0
By default, it generates a linux amd64 based binary, but this can be changed with this arguments:
docker run --rm -e GOOS=darwin -e GOARCH=amd64 -v $(pwd)/pipehub.hcl:/pipehub.hcl -v $(pwd):/pipehub/output pipehub/build:0.1.0
All the possible GOOS and GOARCH can be found here.
Documentation
¶
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Client ¶
type Client struct {
// contains filtered or unexported fields
}
Client is pipehub entrypoint.
func NewClient ¶
func NewClient(cfg ClientConfig) (Client, error)
NewClient return a configured pipehub client.
type ClientConfig ¶
type ClientConfig struct {
Server ClientConfigServer
Host []ClientConfigHost
AsyncErrHandler func(error)
}
ClientConfig holds the client configuration.
type ClientConfigHost ¶
ClientConfigHost holds the configuration to direct the request from hosts to handlers.
type ClientConfigServer ¶
type ClientConfigServer struct {
HTTP ClientConfigServerHTTP
Action ClientConfigServerAction
}
ClientConfigServer holds the server configuration.
type ClientConfigServerAction ¶
ClientConfigServerAction holds the action server configuration.
type ClientConfigServerHTTP ¶
type ClientConfigServerHTTP struct {
Port int
}
ClientConfigServerHTTP holds the http server configuration.
type Generate ¶
type Generate struct {
// contains filtered or unexported fields
}
Generate the dynamic files to include custom handlers at the final build.
func NewGenerate ¶
func NewGenerate(cfg GenerateConfig) (Generate, error)
NewGenerate return the struct that will generate the dynamic code.
type GenerateConfig ¶
type GenerateConfig struct {
Filesystem afero.Fs
Handler []GenerateConfigHandler
}
GenerateConfig has all the information needed to execute the generate.
type GenerateConfigHandler ¶
GenerateConfigHandler has the information needed to represent a handler.
Source Files
Directories