[Looking for reviews] ff - server side framework

[Michał Korman]

Hi everyone,

TLDR: I'm looking for your suggestions and opinions about the framework I've been working on recently - https://github.com/mkorman9/ff

First of all, I'm relatively new to Go, but have a strong Java background. Despite the facts I love Go and I'm really amazed by its vast amount of tools, there are still things back in Java that I miss. One of them is an awesome framework named Vert.X - http://vertx.io/. Vert.X shines when it comes to clustering multiple independently running applications together. It allows to quickly spawn a few instances of an application inside something like Kubernetes and communicate them with their Event Bus -> http://vertx.io/docs/vertx-core/java/#_the_event_bus_api. It is also very easy to publish REST APIs and perform routing of incoming requests.

I would really like to be able to use Vert.X in my Go applications, so I took a subset of its features, introduced own fluent interface and implemented them in form of a Go library. I'm not an expert in Go, and the framework itself probably misses a lot of features, so I decided to make it public and make incremental changes while actively looking for opinions. Please keep in mind that ff is meant to be an implementation of certain Vert.X features, rather than a complete port. Also ff has completely different API than Vert.X.

Repo: https://github.com/mkorman9/ff

Examples: https://github.com/mkorman9/ff/tree/release/_gettingstarted

[matthe...@gmail.com]

Hi Michal, here's some comments:

Why not a break here after true is set? https://github.com/mkorman9/ff/blob/release/clustering.go#L208

I had to resort to grep to find where Parameters was defined (context.go).

Instead of:

type RemoteEventEndpoint struct {
 clusterMember *ClusterMember
 context       Context
}

You could do:

type RemoteEventEndpoint struct {
 *ClusterMember
 Context
}

In the case of a mutex it would make your locking cleaner (holder.Lock() instead of holder.mutex.Lock()). This struct embedding pattern would reduce many of your function calls.

I’ve been making the case to have a type for use of interface{} like this:

type ClusterConnectionPool interface {
 ResolveConnection(target interface{}) error
}

Where target would be a specific "type YourName interface{}" that hints at how it will be used.

Instead of "type JsonCodec struct{}" I’d just have functions. You may be doing this for interface adherence and maybe that makes sense but it could also just be too much abstraction.

The standard library HTTP server and router are pretty good, are you sure you’re adding value by having a wrapper? Just a thought, I don’t know the answer.

Are you sure about linking runtime/pprof and runtime/trace into all of your users' servers? My thought is they have no effect unless triggered, but I could be wrong.

iota only has to be defined on the first item (https://github.com/mkorman9/ff/blob/release/plugins.go#L5).

I’ve put in fun names like PoisonPill before but recently I’ve preferred a name more directly describing functionality.

Your godoc is longer than usual: https://godoc.org/github.com/mkorman9/ff

Matt

[pml...@gmail.com]

Cool, what about a crazy idea here. Try to implement a cluster manager in go. In this case you could use java and vertx where it makes sense and go where it makes sense. Since the cluster managers are the base for the eventbus it could work.