-
Notifications
You must be signed in to change notification settings - Fork 75
ari 3.0 NATS Client and Server
A working nats client and gateway server are in v3 now.
This is the ARI gateway server, ready for embedding (with just Application implemented and no Bus). The tests in here test the ARI v3 nats client and server alongside an example Application client interface.
Wildcards in nats only work if you use a dot separator. Confirmed via automated testing in the natsgw package. No colons in the nats code now.
All handles now have ID methods. Required for this case, where ari.applications.all
returns a list of strings but upstream returns a list of Handles.
srv.subscribe("ari.applications.all", func(_ string, _ []byte, reply Reply) {
ax, err := srv.upstream.Application.List()
if err != nil {
reply(nil, err)
return
}
var apps []string
for _, a := range ax {
apps = append(apps, a.ID())
}
reply(apps, nil)
})
Slight abstraction over standard nats. Reply is a two argument function, the left which contains the response and the right contains an error. (natsgw.Handler could just as easily have those as return values instead which would make Reply redundant)
Here is the translation:
* reply(nil, errors.New("...")) ---------> err to nats queue "${replyID}.err"
* reply(resp, errors.New("...")) ------> err to nats queue "${replyID}.err"
* reply(resp, nil) ----------------------> resp to nats queue "${replyID}.resp"
* reply(nil, nil) ----------------------> {} to nats queue "${replyID}.resp"
The (simplified) nats client side, to determine 'err' vs 'resp'.
replyID := uuid.NewV1().String()
sub, err = conn.ChanSubscribe(replyID+".>", ch)
msg <- ch
msgType := msg.Subject[len(replyID)+1:]
All encoding is manual. Without msg.Subject
and msgType
details from above, we have no idea whether to decode the raw body as an error type or the given interface{}.
- Does ChanSubscribe with a wildcard slow things down much? We are using it on /every/ response?