You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
A short-running ("non-looper") process would just return immediately after reading the input:
func (c*ExampleComponent) Process() {
f:=<-c.Foo// Do somethingc.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:
Support for FBP files is built into runtime, so it can be called like:
n, err:=flow.LoadGraph("app/main.fbp")
port:=make(chanint)
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.
The text was updated successfully, but these errors were encountered:
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
Components
First, to reduce complexity, the following features are removed:
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:
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:
A short-running ("non-looper") process would just return immediately after reading the input:
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:
Support for FBP files is built into runtime, so it can be called like:
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.
The text was updated successfully, but these errors were encountered: