trading platform written in go (code review request)

1,144 views
Skip to first unread message

Joel Reymont

unread,
Aug 21, 2012, 4:46:25 PM8/21/12
to golang-nuts
Folks,

I have written a Go interface to IB TWS API [1], the trading API of
Interactive Brokers [2]. It follows existing APIs [3] but switches
from callbacks to messages and tries to do things the native Go way.

It's a work in progress but I'm actively improving it. I'm also using
it to write bots and trade my own money.

I would appreciate your comments on the code.

Thanks, Joel

[1] https://github.com/wagerlabs/go.trade
[2] http://www.interactivebrokers.com
[3] http://www.interactivebrokers.com/php/apiUsersGuide/apiguide.htm

roger peppe

unread,
Aug 22, 2012, 4:59:06 AM8/22/12
to Joel Reymont, golang-nuts
I always like to see more API interfaces, even if I won't use 'em!

My first impression is that there's a lot of stuff there and
no information as to how I might use it. For instance there are
quite a few types with no reference beyond their definition
(for example BondContractData).

I presume that quite a few of these are messages that
are sent or received from an Engine but there's no way
to tell that. References to the original API documentation
might be useful here, not to mention doc comments on everything.

The Engine type looks central. I would suggest that a channel-based
interface is not very usual. It would be more conventional
to have some methods on the Engine and use the channels internally
if need be (it looks like they're probably not necessary though).

For example:

func (e *Engine) WriteRequest(req Request) error
func (e *Engine) ReadReply() (Reply, error)

As a way to show what types are requests and replies,
you could define Request and Reply interfaces
which are satisfied by request and reply types respectively.
See the go/ast package for an example of this kind of thing.

cheers,
rog.

Joel Reymont

unread,
Aug 22, 2012, 4:57:43 PM8/22/12
to golang-nuts
Roger,

I changed the interface away from channels and will document the
various incoming and outgoing messages.

I'll think about request and reply interfaces as well.

Thanks, Joel
Reply all
Reply to author
Forward
0 new messages