Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v1 Design proposal #49

Open
2 of 3 tasks
trustmaster opened this issue Oct 31, 2018 · 0 comments
Open
2 of 3 tasks

v1 Design proposal #49

trustmaster opened this issue Oct 31, 2018 · 0 comments
Assignees

Comments

@trustmaster
Copy link
Owner

trustmaster commented Oct 31, 2018

7 years after starting this project, after writing and maintaining some FBP apps in production, after collecting feedback on this project (#48), it's time to propose the design for v1.0 of GoFlow library. The main goal is to make the library itself less complicated and make effort from zero to a real app minimal.

Steps

  • Updated basic Components and Graphs in pure Go
  • Updated component Registry and Factory
  • FBP DSL parser and loader written in GoFlow

Components

First, to reduce complexity, the following features are removed:

  • Sync/Async mode
  • Worker pool
  • State locks
  • Lifecycle management (initializer/shutdowner)

It is still be possible to implement all that functionality in the components themselves in pure Go code.

Structure

The structure definition of the components will be simplified:

type ExampleComponent struct {
	Foo <-chan int  // inport
	Bar chan<- int  // outport
}

Process

Reactive port handlers are removed in favour of more generic Process() function, defining the whole behaviour of the component.

So, long-running ("looper") components can be implemented like this:

func (c *ExampleComponent) Process() {
	for f := range c.Foo {
		// Do something
		c.Bar <- data
	}
}

A short-running ("non-looper") process would just return immediately after reading the input:

func (c *ExampleComponent) Process() {
	f := <-c.Foo
	// Do something
	c.Bar <- data
}

Graphs

API

The API for working with Graphs remains the same as before.

Underlying code is to be refactored, but no dramatic changes are expected. Yes, it will still use reflection to connect nodes in the network - because that brings a lot of convenience and run-time capabilities and only affects performance upon application start.

FBP files

One of the goals for v1 is to use FBP DSL as primary way to define graphs. So, instead of many lines of Go code, you could write something like this:

INPORT=Server.Port:Port
OUTPORT=Logger.Output:Log

Server(http/Server) Req -> Req Handler(app/Handler) Err -> Logger(log/Logger)
Middleware(http/Middleware) Funcs -> Middleware Server

Support for FBP files is built into runtime, so it can be called like:

n, err := flow.LoadGraph("app/main.fbp")

port := make(chan int)
n.SetInPort("Port", port)

wait := flow.Run(n)

port <- 8000

Runtime

For v1.0, the runtime should be powerful enough just to load and run .fbp graphs.

Support for FBP Protocol and Flowhub is to be added later. Though, existing work such as compatibility with JSON graph format will be kept to make future integration easier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant