Apigee edge limits and performance extension Google cloud Pub/Sub

Hello guys, I'm doing a study to define the design of the use of Google cloud Pub/Sub through the standard extension of Apigee for communication with GCP.

Reference links:

https://docs.apigee.com/api-platform/reference/extensions/google-cloud-pub-sub/google-cloud-pub-sub-...

https://cloud.google.com/iam

1 - After setting up I created a service account at GCP: https://cloud.google.com/iam/docs/service-accounts

Apigee Publisher:

Through ExtensionCallout policy I can post messages directly to a Google Cloud Pub/Sub topic.

Because the scenario I need to apply is 1 proxy api for 1 pub/sub.

So with this design it does not impact my operation if I need to do some maintenance on the service accounts.

But using this approach I would have a structure (1 account per api proxy * environments), for example:

  • gcp-caller-prd
  • gcp-caller-hml
  • gcp-caller-dev

I searched the forums and documentation on performance and limits of the above approach and did not find clear documentation on the subject.

My question is:

Are there limits on communication extensions with Google cloud Pub/Sub that can be configured in the apigee?

Can there be any performance problems if you use this approach in the apigee tool?Is there a better approach for this scenario?

Does anyone know a contraindication for this scenario?

0 3 227
3 REPLIES 3

> Are there limits on communication extensions with Google cloud Pub/Sub that can be configured in the apigee?

There are limits, but they're not configurable - https://docs.apigee.com/api-platform/reference/limits?hl=en

> Can there be any performance problems if you use this approach in the apigee tool?Is there a better approach for this scenario?

The biggest issue I see here is that each service account will require a deployed extension, and there are limits on the number of deployed extensions.

If you're looking to do high transaction volumes with this, I'd probably suggest calling the PubSub API endpoint directly rather than using the extension. Extensions are great for quick proof-of-concepts but if high volumes and low latency are important for you I'd suggest going direct.

suggest calling the PubSub API endpoint directly rather than using the extension.

I support this message!

This repo shows how to get an OAuth token for GCP endpoints; it shows how to connect with GCP Logging, but the same approach will work for GCP PubSub.

Apigee extensions are great.

But for your use case, is there potentially a better approach? Yes, create a cloud function (node.js, python, go, etc...) and have it front your pub/sub topic. This approach also allows you access into other key GCP resources.