Things I wish I knew about Google Cloud Pub/Sub: Part 1

Pub/Sub can seem like a simple topic, but there is actually a fair amount of subtlety to consider. It’s possible to overlook details that might make your experience more streamlined, less expensive, and less frustrating. To that end, the Developer Relations team for the Google Cloud Pub/Sub client libraries are starting a blog series with some information and tips you might find useful.

And without further ado…!

What is Google Cloud Pub/Sub?

Google Cloud Pub/Sub is a managed, globally available messaging service that scales automatically with demand.

To understand the service in its most basic terms, familiarize yourself with four key components: topics, subscriptions, publisher clients, and subscriber clients.

• Pub/Sub clients publish messages to topics.
• Pub/Sub clients receive messages from subscriptions. You can create multiple subscriptions for the same topic, in which case each subscription gets a copy of all of the messages in the topic. Some beginners assume that one would pull messages from a topic, which isn’t possible — topics are for publishing only. The subscription is where you will receive all messages.
• Your application can create multiple Pub/Sub clients to publish to a topic, across different processes. (With some caveats mentioned below.)
• Your application can also create multiple subscriber clients for a single subscription, in which case message delivery is load balanced across all of them. Messages are delivered to one client on the subscription, not all of them.

How do I call Pub/Sub APIs?

You can use Pub/Sub through both the Google Cloud Console and the Cloud SDK, and the official client libraries. The most common way to access Pub/Sub APIs is through the client libraries, available in 8 languages (C++, C#, Go, Java, Node, PHP, Python, Ruby).

These libraries provide language-idiomatic ways to create topics, publish messages to topics, create subscriptions to topics, and receive messages from subscriptions. These clients are handwritten and built on top of auto-generated libraries, which expose the basic RPC methods available from the Pub/Sub server. This allows us to add useful features centered around improving throughput, minimizing latency, and making it easier to handle incoming messages.

Because the libraries cache information like authentication tokens, we recommend instantiating only one instance of a Pub/Sub client per resource within one process, instead of creating multiple clients. This varies by language; for example, Java uses separate client classes, while Node has a PubSub class that should be created per process, per Pub/Sub server connection; that is then used to create clients for publishing and subscription.

In Node, it might look something like this:

let pubSubClient, topic;
async function main() {
  pubSubClient = new PubSub();
  topic = pubSubClient.topic(‘myTopic’);
  topic.publish(Buffer.from(‘test!’));
  await doOtherWork();
}
async function doOtherWork() {
  // ...
  topic.publish(Buffer.from(‘also test!’));
  // ...
}
main().catch(console.error);

Each library has a more fully featured Quickstart, for a more comprehensive sample; for example, the Node Quickstart.

If you would like greater control over features not available in our client libraries, you can build your own client library using the auto-generated libraries, REST, or RPC stubs. However, we strongly recommend that you look for a way that is supported natively by the client library. If you can’t find one, please add a bug report to the respective library on GitHub or Buganizer.

More to come

Thank you for reading, and please look forward to future posts (Part 2, 3) from the Pub/Sub Developer Relations team that will help your Pub/Sub usage become even easier! We would also love to hear from you about topics that you’d like discussed, or if you have any comments on the post!