API Gateway question

[Shawn Bernard]

I am relatively new to Go and Go-Kit, so my question might be a little basic.

I was under the impression that the API Gateway would be where, for a particular endpoint, the system would hit multiple microservices, consolidate the data into a usable form for the client, and then send it back to the requester. Where in the apigateway example would that happen?  I'm a little confused by exactly what is going on in the example.

Thanks,

S

[Peter Bourgon]

You're describing more of a backend-for-frontend pattern.

http://philcalcado.com/2015/09/18/the_back_end_for_front_end_pattern_bff.html

An API Gateway is generally dumber. It's more of a proxy or request
router, generally doesn't modify the request, and at most performs
general work like authentication. If there's business logic in there,
it's probably not an API Gateway anymore.

The apigateway example in Go kit is mostly meant to illustrate how to
programmatically consume from a package sd provider, and construct
client libraries. It's not meant to serve as the basis for an actual
API Gateway deployed to production. Although that's definitely
something you can do with Go kit, it's almost certainly a niche
requirement; you're almost certainly better off using a prepackaged
solution, like AWS API Gateway, a properly configured HAProxy or nginx
instance, or a next-gen tool like Traefik.

Hope this helps,
Peter.

> --
> You received this message because you are subscribed to the Google Groups
> "Go kit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to go-kit+un...@googlegroups.com.
> To post to this group, send email to go-...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/go-kit/5bb90863-2a8f-4a37-8e56-bdc6ab0b82e2%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Shawn Bernard]

But looking at 

http://microservices.io/patterns/apigateway.html

it looks like BFF is just a variation of an API Gateway.  I don’t want the client calling all the microservices individually, the client should just hit an endpoint which then hits all the necessary microservices to consolidate the data.  Whether you call it an API Gateway or a Public API or Public Layer, I don’t care so much (especially since those names seem to be used differently by different people).  What I am interested in, is how this would apply to Go Kit.  From what I’ve seen, I’ve really liked Go Kit for microservices, but I am not sure how to build the API Gateway/Public API/Public Layer. Would that be a separate Go app outside of Go Kit?  Could I use Go Kit for that? Or something else?

Thanks for helping me out while I get my bearings in this new world of Go.

-S

[Peter Bourgon]

I don't necessarily disagree with Chris' assertion that the
Backend-for-Frontend pattern is an adaptation of an API Gateway. In my
opinion that stretches the definition of API Gateway toward something
very general. In my experience calling something "API Gateway" means
that you're typically a lot closer to infrastructure than business
logic. But it's all a matter of perspective and opinion.

You can definitely write an API Gateway using Go kit, be it dumb (just
routing requests) or smart (serving a composite response full of
business domain awareness) or anywhere in between. The transport layer
would likely be HTTP+JSON. Your service implementation would perform
the necessary business logic for each request, treating downstream
microservices as dependencies. I guess it would look something like
this


type APIGateway interface {
Login(...) (token string, err error)
UserRequestFoo(...) error
// ...
}

type apiGateway struct {
search searchService // implemented by a load-balanced pool of
connections
profile profileService // same
// etc.
}

Or, if you were deploying onto e.g. Kubernetes, you maybe wouldn't
need to keep a pool of connections to individual search services;
maybe you'd just forward requests to the search service DNS entry, and
let Kubernetes handle all the load balancing and etc. for you. Then
search would be a *url.URL, maybe.

With all of that said, my intuition is that you shouldn't need to do
this, in the general case. I'd instead hope that individual
microservices would implement reasonably broad bounded contexts, and
could be called directly by clients to perform complete
business-domain actions. Said another way: if every individual action
your users take in your e.g. web app requires calling multiple
microservices, this ·may· indicate that your microservices are too
granular.

> https://groups.google.com/d/msgid/go-kit/1B736EA9-229A-4EC8-9F4D-9FA23461237A%40gmail.com.