ESP as an API Gateway for multiple services

[elliot...@gmail.com]

Just followed the how-to on using ESP in front of Cloud Run, and wondering if I can have one have one ESP as a gateway/proxy for multiple cloud run services? My only concern from what I’ve seen in the docs so far is that it seems like it would necessitate a giant openapi yaml for all those services, which I wouldn’t want. My primary motivation for wanting to use ESP is to secure the services for end users (who will be interacting with them from SPA’s using REST/https). So my questions are:

1. Is it possible to have one ESP for multiple cloud run services?
2. Does it make sense to do things this way?

[Chris Latimer]

Yes, you can have one ESP as the gateway for multiple services using the x-google-backend OpenAPI extension. It might make sense to do this if you are granting all your API consumers access to everything in your OpenAPI spec. If the OpenAPI doc gets too big you can always break it out into multiple docs that better describe the boundaries of your APIs, but then you will need multiple ESP gateways since each gateway is configured by a single OpenAPI spec. 

--
You received this message because you are subscribed to the Google Groups "Google Cloud Endpoints" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/5e78024e-c1fa-407d-94e6-071981d39cca%40googlegroups.com.

--

Chris Latimer clat...@google.com Product Manager, Apigee Mobile 1.614.596.8090

[elliot...@gmail.com]

Thanks for the quick reply. Two more questions on this:

1. Is there a way to forward requests in an NGINX-like way in the case of one ESP for several services? Example: GET /vehicles/cars/id to ESP -> vehicle service’s /cars/id route.

2. What’s the expected behaviour if user tries to hit a route that’s supported by the backend API but not included in the ESP’s YAML file?

[Chris Latimer]

Currently the only way to route to multiple backends is with the x-google-backend option via OpenAPI. I believe (and someone please correct me if I'm wrong) that any paths not defined in the OpenAPI spec will be rejected when the call comes into ESP even if the backend supports them.

--
You received this message because you are subscribed to the Google Groups "Google Cloud Endpoints" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/800ff14f-a1dc-47d6-8d60-acc6413f62f9%40googlegroups.com.

[elliot...@gmail.com]

Gotcha - I’m a little confused on the one-yaml-per-ESP since this seemed to imply you could do multiple yamls per endpoint?

https://cloud.google.com/endpoints/docs/openapi/openapi-extensions#x-google-api-name

[Chris Latimer]

Sorry, what I meant was one Endpoints Service not one OpenAPI spec; I had forgotten that you could combine multiple specs into a single service with x-google-api-name.

On Wed, Nov 13, 2019 at 9:07 AM <elliot...@gmail.com> wrote:

Gotcha - I’m a little confused on the one-yaml-per-ESP since this seemed to imply you could do multiple yamls per endpoint?

https://cloud.google.com/endpoints/docs/openapi/openapi-extensions#x-google-api-name

--
You received this message because you are subscribed to the Google Groups "Google Cloud Endpoints" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/07b2c150-d01d-446d-96e6-88370e8b8cd1%40googlegroups.com.

[Janez Dolinar]

Hi Elliot,

Have you managed to get this working? We're trying really hard to implement this but to no avail.

[Elliot Berman]

Hi Janez - sorry for the delayed reply. We ended up doing one ESP per service. Based on how things worked with Google Cloud, it would have been tough to do it otherwise because we would have to redeploy the central ESP yaml every time we deployed any service. I think there are ways to import yaml from different sources, but then we would have had to build a service that did this and it would have introduced a lot of complexity. On the whole we definitely wish that there had been a better integrated solution for this but so far haven't had many issues with the 1 ESP per service way of doing it. We store the yaml in each service's repo and wrote a fairly lightweight deployment script to deal with it.