mattheath: curious if my idea of the interaction between Transport and Codec maps to yours... viz. http://play.golang.org/p/BgcgWvkSSR yeah think so i’d see the codec as the serialisation part between the transport (http/zmq/rmq) and the server itself which handles a decoded request there are some pretty blurry lines though previous implementations i’ve worked on we used rabbitmq and protobuf by default, but the underlying serialisation part supported both json and protobuf and put a header on the wire indicating which the payload was so one concrete codec implementation with a sort of type switch? i guess yeah, it wasn’t very abstract switched on a content type header (actually a rabbitmq header) hrmm rather irritating that github hides inline comments when i modified something nearby but not the actual thing ;) :\ if all server endpoints will implement the same interface, then I guess the tricky part is figuring out how to transform a service interface method to that form. `go generate`? package reflect? that is, I'd expect maybe something like `type MyService interface { Process(int) error }` --transform--> `func (x MyServiceProcessAdapter) Serve(ProcessRequest) (ProcessResponse, error)` so Request and Response would I guess have to be interface types or did you have something else in mind? ptrb & # afk a little while, but will read shortly ah ok, so I’m used to having a standardised Handle interface - something like Handle(server.Request) (server.Response, error) rather than the finagle style of function as a service and then dealing with that in the handler with any custom logic that then also simplifies the server as it takes a request, identifies the correct handler, and executes it with the same interface each time though appreciate it makes the handlers more verbose as you have to unmarshal your request body inside the handler due to the type system I'm actually working over a tool that'll generate wrappers around functions, stuff to turn a function like func Add(x int, y int) int {} into a pair of structs for easy codec handling what would that output though? my current goal is to have it be a codec generator, tell it an service and it'll generate out structs and helper functions to call the service's functions with the end goal being a function that you can pass a message into and it'll call the service, then return the response message initially going for a json codec generator, but I'd like to make it generic ok, interesting. sounds a bit like thrift? i’ve used protobuf a lot, which gives you structs and serialisation. but usually had a defined client interface to call another service - maybe something like: client.Call(serviceName string, request, response proto.Message) error well, I want to make it a little simpler to consume simpler? underneath it marshals to the on the wire format, sends the request, and puts the response into the struct or gives you an error ofc also you have service discovery, deadlines etc in that, so you probably need a configurable client not sure it'll really fit into gokit, but I'd like to spit out "client side" packages that are the same interface as the service, and it handles the stuffing the structs with the params and stuff so like http://golang.org/pkg/net/rpc/ ? but generated? :) yeah, but no lol ha generated code, and no fixed 2 struct, one in, one out type stuff so you could do z, err := client.Add(x, y) and it'd do all the magic to get it across the wire and everything not sure there’s much difference tbh? just moving around params err := client.Add(struct{int, int}{x, y}, z) uglier i admit ;) but the data formats i usually use are a lot more complex than adding numbers appreciate its just an example lol, yeah part of it is getting rid of reflection and ensuring types match and everything any particular reason for getting rid of reflection? its used in a lot of places anyway mattheath: what I'd *really like* to avoid is requiring gokit services to implement their own Handle function to bridge the Go domain (type MyService interface) to the, for lack of a better term, SOA domain tbh i’ve written services that do 10’s of thousands of requests per second with sub-ms response times and casually ignored the fact my requests and responses were using reflection for marshalling internally but I haven't thought about the problem long enough to know if it's infeasible, especially with all the touchpoints (sorry dumb q) by Handle function you mean? actually setting up a server and handling requests? I mean as you put it: " a standardised Handle interface - something like Handle(server.Request) (server.Response, error)" -- which I presume you'd expect all gokit servers to implement think we have a difference in terminology - i see servers having many handlers unlike (from what I can tell) finagle where a function is a server? please correct me if i’m wrong I don't know enough about Finagle to speak on that ah k one of my personal goals is to be able to make a generic golang library into a service with minimal modification Vendan, interesting, that’s definitely not my use case ;) I'm thinking right now that a gokit server would map one-to- one with a type MyService interface { ... } ptrb: so my thoughts on the handlers were, simple server library - i register some handlers with a name and a func to execute, and they do their thing and maybe you have one Handler per MyService method i’ll knock up something quick but I'd want those handlers to be created by the gokit server.New(myService, ...) ptrb, would a service interface have multiple functions? Vendan: yes, it would be in the business domain of my organization also, is there any particular reason interface and not struct? type LikeService interface { Like(UserID, TweetID) error } Vendan: yes, of course; services are defined by their behavior (interface) not their implementation (struct) Vendan: more concretely, I should be able to pass a MockLikeService to server.New() and it would work exactly the same wouldn't you still pass LikeService, cause that's the interface?but somewhere else the server decides to create a MockLikeService? Vendan: yes, you'd still pass a LikeService, but it can be backed (implemented) by anything: a real implementation, a mock implementation, etc. k var s LikeService ; s = NewRealLikeService(...) /* or NewMockLikeService() */ ; server.New(s) http://play.golang.org/p/ul_CJ_xilk ptrb reads but with interfaces naturally ;) hrm, does the server even understand the difference at that point?I mean, unless you are generating a lot of code, that server.Now is just looking for an interface{} Vendan: the server would only care about the interface definition, so it can generate the appropriate stubs, invoke the Go-domain methods, and perform the appropriate decoding/encoding mattheath: in this example, RegisterEndpoint takes Endpoints that implement (or wrap implementations of) my business logic? is server.New in this example generated code though?are you talking about generating code on the fly? ptrb: yeah RegisterEndpoint would take something that satisfied a Handle() interface that contained your business logic, and the server would deal with getting requests to and from your code Vendan: no, server.New is not generated code. and I'm not sure at what stage the stubs would be generated, it could be at compile time (e.g. `go generate`) or initial runtime (e.g. `package reflect`) also, that endpoint type def is off, it would need a field named Handle in the struct but that's minor Vendan: there are a lot of things wrong with the code i wrote ;) sorry! mattheath: right. if at all possible, I'd like to implement my business logic in code that had no concept of server.Request or server.Response ok, without a standardised input and output, how would the types work? (unrelated, the request would likely be, or implement a context interface) mattheath: and I'd like the mapping of my business logic functions to server.{Request,Response} to be done for me, though I'm willing to cede that point and force users to write mappers for a MVP mattheath: either through generated stubs, somehow, or reflection on the business logic interface, somehow definitely possible heh, that's the first stage of what I'm working on, ptrb Vendan: excited to see your first draft :) well, haven't had much time to work on it yet FYI this is rather similar to chuhnk’s implementation: https://github.com/asim/go-micro#init-server weekends are busy for me but I'll probably have a PoC out tomorrow I do contract work, so I can set aside a hour or 2 to work on it mattheath: I see, yes mattheath: but -- this was good. I feel like we understand each other :) tidyed up the typos in the code here: http://play.golang.org/p/FV7gLMpMJa night :)