The big story for this library is that we’re moving to a minimum engine version of Node 18 and upgrading a ton of dependencies in accordance. But there are a few things that aren’t fully covered by the changelog, and these are worth calling out here:

• ECMA compliance. We are now linting for dangling Promises (ones with no catch handler). Where possible, the cases this found were fixed to do something useful, and where that fix would’ve been non-trivial, we have added the void keyword for now.
• Upgraded TypeScript compiler. (5.8.3)
• Newly auto-generated gRPC classes. These underlie the higher level wrapper functionality that most users use. A really notable change here is support for request/response debug logging, for which I should probably write a whole separate blog.

Some changes are considered breaking, and may cause users to need to update their code. We always try to keep these to a minimum, but sometimes they just make sense:

• We had an old and somewhat broken implementation of OpenTelemetry tracing, implemented well before most of the other libraries (and well before we really knew exactly how we wanted to handle this important functionality). The legacy OpenTelemetry support was supported for quite a while, but that has now been removed. The new support uses the current standards with propagators as Pub/Sub message attributes.
• Legacy ack deadline options were removed. In the past, users could set ackDeadline by itself to fix the deadline at a number of seconds. This has been replaced by two knobs in the SubscriberOptions: minAckDeadline and maxAckDeadline. These have been used for a while with exactly-once delivery, but now they are the standard for all ack deadline limiting. These use our extremely lightweight polyfill for tc39’s Temporal Duration class, which will eventually be removed in favour of the real implementation.
• The FlowControlOptions setting maxExtension was renamed to maxExtensionMinutes for clarity, and maxExtension remained a compatibility shim. With a major, we are removing both of these and adding a new setting to SubscriberOptions (next to the *AckDeadline settings) called maxExtensionTime. This is also a modern Duration value to remove ambiguity about the time units.

As usual, if you have problems with the library itself, please post an issue or a discussion topic on the GitHub repo.

A new major version for the Node client library for Pub/Sub was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Disclaimer up front: This blog post isn’t the official word on anything; please, always check cloud.google.com for official answers and policies.

Note that the link above is about the APIs themselves, not client libraries — but we try to follow them for client libraries, too. Also note that what I’m talking about here is “end of support” rather than “deprecation”. The former is about how many person-hours we spend on maintaining older code, and the latter is about discontinuing it entirely.

In any case, I wanted to try to demystify this topic a little bit, in friendly, non-corporate language.

First, I’d like to link to this article that my colleague wrote, and which I poked at a little bit, too:

Google Cloud SDK moves Node.js 10 to maintenance mode | Google Cloud Blog

There have been some deviations from this because of our much longer than expected cycle to drop Node 12, but what that article says is essentially still our intent as developer relations and Cloud SDK. (It is also very similar to the policies at AWS, for example.) TL;DR, we want to support Node versions for 6 months past Node declaring them as unsupported.

I think that all of us know that, for customers and users, dropping support for things willy-nilly is extremely frustrating. Before I worked at Google, I worked at other companies just trying to make the best of still other companies’ APIs and SDKs. It’s part of our job as DevRel to feel your pain there and try to drive change if we can. It’s something I was excited about back when I interviewed.

Unfortunately, for Node specifically, we don’t get a huge amount of choice in the matter — V8, JavaScript, Node, and even TypeScript are fairly stable and backwards-compatible now. But the vast npm package ecosystem is not. Many prominent packages will bump their required engine versions on the day of the Node engine maintenance ending. This often means that there are no more security patches or fixes on the branch that supported the version we need to support. Security vendors quickly come behind and remind us of that fact. :)

And you can imagine that there is a transitive network effect — the packages that depend on those packages may be forced to upgrade the required engine, and so on. That’s just the uncontrollable fact of a huge open source ecosystem.

So here is what we’ve got, currently.

The three pillars (ugh) of this are:

1. We intend to support Node maintenance versions 6 months past their “best by” date. As the linked article says, “This may vary depending on critical security patches”. This means that, even if we make a new major/breaking version that requires the next Node version, we intend to do our best to keep supporting the previous one for 6 months; but ideally, we also prefer not to make that new major until the time window has passed. But see above, re: npm — there may still be circumstances that prevent us from doing exactly what we need to do.
2. We aim to minimize mandatory API changes. No one likes to rewrite their code for a new library version. There’s no one-size-fits-all answer to this problem, because sometimes changes simply do have to be made. But e.g. for the area I work most in (Pub/Sub) we try super hard to make all of the raw RPCs backwards compatible, and though we have some new SDK APIs planned, these are (a) meant to be pretty close the existing ones, and (b) planned to include a compatibility layer that will let you work with minimal changes for a while. We want to reduce your friction and pain for using our services. The Pub/Sub SDK team is pretty on board with this idea, because it lets us evolve without breaking all of your apps, but we’ve been advocating to other teams, as well, and it’s an idea that has been well-received.
3. We want to minimize “major churn fatigue”. Semver lets us make new major versions whenever something might break, but there is an internal culture of trying to avoid too many of these in a small time window.

So, to summarize, this is a hard problem; but we are all interested in trying to find good compromises, going forward. And hopefully this post will help to understand the mindset behind some of these releases and actions!

This is an opinion piece, and the views expressed in this post are my own, not my employer (Google)

Interesting times

I started at Google in DevRel just a short time before the pandemic ramped up to its early terror. I ended up doing my Noogler (you can probably guess, but it’s one of the many -oogler nicknames, in this case for new hires) orientation at the New York office. You might have heard stories about our offices — living walls, arcade games, scooters in the hallways, many cafes with free food. Well, in reality… it’s exactly like that, yeah. :) The left half of the banner image above is a picture I took from the terrace outside one of the NYC-9TH cafeterias. It’s a really phenomenal place.

There’s a truism about Google that Nooglers almost universally come in with “imposter syndrome”. The short version explanation of that term is… take it away, Wayne and Garth.

Google has a kind of glass tower reputation (and a monolithic facade) that I think makes it feel inaccessible to other developers. One of the functions of developer relations, at least in my mind, is to dispel some of this aura, to be in both your corner and ours. I do honestly believe that this is a special place (one of the best I’ve worked at), but at the end of the day, we are also just trying to make stuff that works, and more importantly, make stuff that works for you.

The Boring Show

Getting back to the title of my post, I’d like to bring up something really cool that the Flutter/Dart developer relations folks are doing: The Flutter Boring Show. The idea behind this effort is to drop the contrived examples / marketing / what-have-you, and focus on really hard, real world problems that are baffling both outside developers and our own. This is what we offer to people applying to work at Google (solve real world, really hard problems!) and I believe that we should offer it to all of you, as well. Our goal, then, is to take care of some of that complexity for you, so that you can focus on the hard problems that make your own work unique and interesting.

As part of DevRel engineering, my primary task is to make the libraries that interface with our services work well for you. That includes adding new features, looking at bug reports, and helping out with customer cases. My other primary task :) is to bi-directionally advocate:

• Helping users understand why things are the way we’ve designed them
• Helping us understand why things should be designed differently
• Trying to broker compromises between those positions

To that end, some focus has recently been placed on making full, end-to-end examples. A quick snippet of sample code and good documentation go a long way toward getting you started, which is really important; but in the end, you also need to know how to connect the pieces together, and where to go next.

These are all really important to us as Googlers. I can only speak for myself, but my impression is that it’s a shared aspiration — we really want to help you succeed, and nothing is more delightful than hearing that you have.

Buffering…

I’ll close out by talking about the right half of that banner image at the top. When the rubber hits the road, as they say, things get messy. Nothing in my lifetime has been as messy as trying to persevere and thrive through a global pandemic. I experienced a few scant months of that fabulous Google office life before we all started working from home. Network issues, cats taking over the camera frame, suddenly having to run to help the kids who are stuck at home.

As I say at the top, I can’t speak for my employer, only my own views and perceptions. But everyone I work with is dedicated to continuing to improve your experiences on our platform, as well as your own! We don’t always hit the mark (again, my opinion). It’s a given, and humility toward improving and doing better without drama is an internal virtue we try to export. We try, but, well… we are people too. :)

Why Elm?

Elm is a pure functional language with a syntax similar to Haskell, but optimized for writing front-end web applications. It has a transpiler that converts Elm modules into JavaScript, as well as a very small and fast runtime to interface with browsers.

Elm is pretty firmly positioned as a front-end tool, to make dynamic, single-page applications for browsers. But with the help of the elm-node package, much more is possible!

Caveats

This article will walk you through building an Elm application that runs in Node.js, and uses the Node.js Pub/Sub libraries for communicating with Google Cloud Pub/Sub. Please note that we do not recommend doing this for your production work at this time; this article is mostly for the curious!

Why “pure functional”?

Many of us are familiar with basic functional patterns, like passing a lambda function to map() in JavaScript.

Pure functional refers to programs that describe what it is that you want to figure out, declaratively. Most programs are written in an imperative fashion, which is to say that you, as the programmer, are telling the computer what steps to take, and in what order, and managing the state of the program. This introduces a great burden on the programmer, because one must constantly think about how to maintain the consistency of state, as well as what might go wrong to handle unexpected errors from unknown side-effects.

JavaScript tools have been developed to help with the state problem at least, such as Redux, whose model was inspired by Elm. Redux lets you declare your program’s state as an immutable structure that is updated using mutators. However, many things can still go wrong at runtime, because the compiler isn’t helping you to understand the possible flows through the logic.

A truly pure functional language has no flow control. There are no steps to run, and since your program is basically a mathematical equation, the compiler is able to fully understand it, and catch most logic errors at compile time. In fact, it is even possible to write proofs about pure functional programs.

Elm … on Node?

Because Elm is simply a transpiler, it’s also possible to run the resulting code using the Node.js runtime, rather than a browser. This gives you the ability to build very lightweight server processes using all of the existing Node compatible libraries from npm/yarn, while staying in Elm for as much of the application as you like. Elm’s lack of side effects also means that many logic and data structure modules can be shared between client and server.

This article will walk you through building an Elm application that runs in Node.js, and uses the Node.js Pub/Sub libraries for communicating with Google Cloud Pub/Sub.

My series of “Using Pub/Sub From” articles:
Using Cloud Pub/Sub from Kotlin
Using Cloud Pub/Sub on Node.js from Kotlin/JS

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

Project setup

Begin by installing a recent version of Node.js. (Or using nvm!)

You will also want the commands for Elm and elm-node, so install them globally:

npm install -g elm elm-node

You can then create an elm-node project:

elm init
elm-node --example-elm > src/Main.elm
elm-node --example-js > src/index.js
elm-node --js src/index.js src/Main.elm

Right away, I found an error in the generated sample code — index.js needs to refer to Elm.Main, not Elm.MainWithJs. These types of errors may be fixed by the time you try it.

The generated program is extremely simple. Some program declarations are made in Elm, including a port to talk with JavaScript. The JavaScript code then subscribes to the port and responds to calls.

App design

Because Elm and JavaScript are interfacing across two very different kinds of coding, we need to think about how they will communicate. The Elm guide discusses this in light detail. The recommendation is essentially to try to avoid piping every JavaScript call through to Elm. Instead, make an interface that makes sense in Elm. This also helps with the Elm/JavaScript transition, which relies on passing nothing more complicated than JSON. (No object handles or anything.)

For this very simple example, I’ve chosen to expose an interface to Elm that lets the Elm code request that messages be sent or ack’d, and then is able to receive messages in an event-driven manner. For a real application, you’d probably need something more complex, like passing numbers or JSON across to refer to specific topics or subscriptions, and caching those with a Map on the JavaScript side.

The ultimate recommendation of the Elm designers is to rewrite client libraries in native Elm, but given the size and complexity of the Node Pub/Sub libraries, this is probably not feasible at this time. So we will use ports!

Port definitions

The place we must start here is to define our ports. To define our ports, we must first decide what sort of capabilities and interface we want to have on the Elm side. How much will be declared in Elm, and how much will reside in JavaScript/TypeScript?

Let’s briefly pick this apart a bit!

First, we have the definitions of the messages we will be passing back and forth. Our message payload for this example will be a simple string, so the MessageToSend will simply be an alias for String. When receiving a message, we must also know the Pub/Sub message ID, so MessageReceived has both the payload and the ID.

The ports themselves are basically declarations of messages that may be passed between Elm and JavaScript. The log port will let us print log messages, publish lets us ask for a message to be sent, receive goes from JavaScript to Elm for a received message, and ack lets us ack a Pub/Sub message. One thing to note is that I’ve chosen to make the parameter to publish a record rather than just a string. This is to make it simpler to add more parameters later on, if we wanted to.

You can see that the messages that go from Elm to JavaScript are functions returning type Cmd msg. This is a generic type that specifies a command the Elm program requests in order to get to the next state. Messages from JavaScript to Elm use Sub msg, which is a function returning type Sub msg. This means that we are subscribing to messages with a parameter type of MessageReceived, and will use those to trigger a state update.

Elm model

Now that we’ve defined our ports, let’s define our Elm-side model.

In this case, our very simple example is just sending one word of this sentence at a time (thus toSend for what’s left to send, and receivedMessage for what we’ve received). Also, we define Msg here as the type we will take in to trigger a state update. In this case, the only message we’ll receive is Received, with a parameter of type MessageReceived. But you might have others here in a more complex application.

Elm Main

If this looks more like a data structure than a program, you wouldn’t be wrong! In Elm, they are one and the same.

The main symbol we export in this Elm module is main, and it will be a worker program (no UI). The init function will specify the initial state. The subscriptions function will list the messages we’re willing to receive. And update will define how to get an updated state from a received message, as well as further actions.

This defines the init function, which returns a tuple. This includes the initial state (toSend has all but the first word, and receivedMessage hasn’t received any yet) as well as next steps to take. The Cmd.batch function builds an array of commands to execute, in any order, probably all at once. Note that these are our ports from above.

This one is very simple! We’re simply saying that we are able to receive message type Received (defined above as part of Msg).

This is the core of the logic in the Elm app. Basically when the Elm app is passed type Received with a message (again, defined above) and a previous state model, we will return a new model. The model will update toSend to be one fewer word than the previous model; we will also add the new received word to receivedMessage. (Note that these updates are not done in-place, but this is returning a new model; so we must use let if we want those values right away.) Finally, the Cmd batch will print out what we’ve received, ack the message in Pub/Sub, and potentially publish the next word. (All of which may happen at once, in any order.) If there’s nothing left to send, then no further commands are issued.

Running the app

Your process will no doubt vary here, but for the complete sample, I have created an npm run script that you can use to start it. You should see something like this:

> npm run run
[…]
Use Ctrl+C to exit.
Elm starting Pub/Sub Elm test
JS publishing: Mary
JS: received: 1 : Mary
Elm received so far: ‘Mary’
JS publishing: had
JS acking: 1
JS: received: 2 : had
Elm received so far: ‘Mary had’
[…etc…]

Note that, because our app is publishing messages sequentially, the final message string will always be in order. A nice exercise for the reader would be to have it publish more than one message (one per word) at a time, and you can see that they may come out of order. From there, you might play with assembling them in order again, and so on.

Next steps

Check out a full working example that runs on the Pub/Sub emulator:

https://github.com/feywind/elm-node-pubsub

Have you used Elm on the server side with Node.js? Do you find this interesting and wish to hear more? Please feel free to leave a comment about this post or things that you find interesting/promising in regards to Elm on Google Cloud Platform!

Using Cloud Pub/Sub on Node.js from Elm was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why Kotlin/JS?

Kotlin is commonly used for front-end JVM work, but as shown in the previous post about Kotlin and the JVM, Kotlin can work quite well on the server side as well. In order to maintain a full Kotlin stack in a web application, Kotlin/JS was developed.

Kotlin/JS is basically a standard Kotlin compiler, but instead of writing to JVM bytecode, it transpiles* into JavaScript. It serves much the same purpose in this situation as TypeScript, providing type safety and syntactic sugar to some common operations. Like TypeScript, it also provides a concept of external typings for JavaScript libraries. Using the Dukat utility, one may also convert TypeScript typings into Kotlin typings, making it very easy to get full type safety in a Kotlin/JS application.

* Transpilation is like compilation, but converting from one human-readable language to another, rather than binary code.

With Kotlin on both the client and server side, generally using React and a JVM, respectively, it’s possible to share some code directly, like generic business logic and data classes. It’s also possible to leverage existing competencies in Kotlin for a team developing a vertical application stack.

Kotlin/JS … on Node?

Yes, it’s true! Because Kotlin/JS is simply a transpiler, it’s also possible to run the resulting code using the Node.js runtime. This gives you the ability to build very lightweight server processes using all of the existing Node compatible libraries from npm/yarn, while staying in Kotlin for the whole application.

Caveats

This article will walk you through building a Kotlin/JS application that runs in Node.js, and uses the Node.js Pub/Sub libraries for communicating with Google Cloud Pub/Sub. Please note that we do not recommend doing this for your production work at this time; this article is mostly for the curious!

Project setup

Begin by installing a recent version of Node.js. You may also install it using nvm, but you’ll need to set the path to npm in the project settings below.

Open either IntelliJ IDEA or Android Studio and create a Kotlin/JS project targeted at Node.js. As of this time, the new IR compiler is still experimental, so I recommend using LEGACY to keep things simple. (By the time you read this, that may not be the case.)

To work with the Pub/Sub libraries, we must add them to our Gradle build configuration. Edit the build.gradle.kts file, and add the following line:

As the comment suggests, you could normally enable generateExternals, and it would invoke Dukat for you to automatically convert any TypeScript typings in @google-cloud/pubsub. Unfortunately, it is currently failing, so we’ll make our own very simple typings!

Kotlin/JS Typings

In order to call the Pub/Sub library in a type-safe way, we need to add some typings. I like to create a file with the same naming convention as TypeScript, such as pubsub.d.kt, but your tastes may vary.

Begin the file pubsub.d.kt like this:

This tells the compiler several things:

• This file contains typings for the @google-cloud/pubsub library
• The typings may be used outside of a Kotlin/JS module setting
• The items described should have a Kotlin namespace of google.cloud.pubsub

Our types will use JavaScript Promise<> objects, so we also need to import those typings:

Finally, the actual typings. You can find the full example here, but for example, for the PubSub class:

I also like to make a Kotlin-idiomatic data class for JSON blobs we’d normally pass in. These can’t be in the same file — you must make a separate non-external file for that.

In JavaScript, this will turn into a standard { projectId: null, apiEndpoint: null } object.

Interfacing with Pub/Sub

We can now call the Node.js Pub/Sub library in a more or less normal way. This example uses the emulator:

This is pretty nice! The subClient.on() call has turned into a Kotlin operator like “use”.

Kotlin/JS and Coroutines

Let’s take a look at another operation that might be common:

Unfortunately, this returns a Promise<>, not the value we want. You can interface with this in the normal JavaScript way:

And again, this looks pretty good thanks to the Kotlin lambda parameter syntax. But we can do better.

In TypeScript, you’d simply use async and await. Kotlin/JS doesn’t currently support JavaScript native async and await. It does, however, provide Kotlin coroutines! And it turns out that it’s not too hard to bridge the two. That discussion is from a while ago, and coroutines have since come out of the experimental phase, so it requires a little bit of work to bring it up to date.

First, we need an adapter between JavaScript Promise<> and Kotlin coroutines. This extension function will let you call .await() on any Promise<>, and the call becomes a suspend function call:

And since Kotlin/JS isn’t running on the JVM, we can’t use JVM-native operations like runBlocking. So this implements a bridge from non-suspend code to a suspend function, kind of like calling an async function in JavaScript without await:

And now we can do this sort of thing:

Hey, that’s looking pretty good, actually! We’re back to the ease of use of TypeScript async and await, but we are also writing Kotlin. This will transpile down gracefully into an application you can run on Node.js with no JVM.

Next steps

Check out a full working example that runs on the Pub/Sub emulator.

Have you used Kotlin/JS on the server side with Node.js? Do you find this interesting and wish to hear more? Please feel free to leave a comment about this post or things that you find interesting/promising in regards to Kotlin and Kotlin/JS on Google Cloud Platform!

Using Cloud Pub/Sub on Node.js from Kotlin/JS was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why Kotlin on the server side?

In regards to Google products, Kotlin seems most well known as a language to build Android applications. But Kotlin’s lovely type safety and code brevity features work great on the server side, as well. And since it compiles and runs natively on the JVM, it is pretty easy to slot it into any place where you’d run a Java application.

Thankfully, it is also quite easy to use the existing Pub/Sub libraries written for Java.

(Please note that this is not officially supported at this time, but hopefully this will get you going if you’re trying it!)

Project setup

It’s possible to create Kotlin projects that build using both Maven and Gradle, but Gradle is the preferred and “native” choice for Kotlin, so I will proceed with that.

The first step is to use either IntelliJ IDEA or Android Studio to create a Kotlin command line project that builds with Gradle. Make sure to make a Console Application, and to set a JDK. (It doesn’t have to be 11.)

There’s not much to change on the second page:

To work with the Pub/Sub libraries, we must add them to our Gradle build configuration. Edit the build.gradle.kts file, and add the following implementation line:

Of course, that is the current version as of this article; you should probably visit the Maven Central entry for the Pub/Sub library and check for the latest version.

(If you have Gradle build errors, be aware that a recent IntelliJ update caused some of those; make sure you’re on 2020.3.1+.)

You should now be able to make calls to the Java Pub/Sub library, like this one:

Compilation should succeed, though it won’t do much just yet!

Interfacing with Pub/Sub

Now that your basic project is in place, you can use the Java APIs but with the brevity and type safety in Kotlin that we know and love. For example, this function will begin listening on a subscription, calling the message receiver for each message received, until an exception happens.

You could use that function in something like this sample, which will simply receive and ack messages, and occasionally (once per 10 seconds) print a count of how many have been received:

Next steps

From here, you can start to do things like creating fluent data classes for your message schema. The examples I gave above are also pretty simplistic, and maybe not quite idiomatic (apologies for being a bit rusty!) They could probably be improved using Kotlin flow operators and such. Kotlin continuations might also be used very gracefully to handle async communication.

See a complete example which runs on a local emulator.

Have you used Kotlin on the server side? Please feel free to leave a comment about this post or things that you find interesting/promising in regards to Kotlin on Google Cloud Platform!

Using Cloud Pub/Sub from Kotlin was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

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!

Things I wish I knew about Google Cloud Pub/Sub was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

I started at Google, in Developer Relations, in October 2019, with a focus on the Pub/Sub client libraries under Node.js. My focus has expanded over time to include the general Node.js ecosystem within GCP Developer Relations, as well as our GitHub automation tooling.

In a more general sense, I’ve been in the industry for quite a while, working across many different languages and libraries, such as C++, C#, Java, Kotlin, and even a few variants of assembly language. I’m especially interested in game development, but that’s a very occasional hobby. My time with Node.js and TypeScript started somewhere around 2016, working with the Predix platform at GE Aviation.

Outside of work, I have many hobbies! Drawing art, making music, sometimes writing fiction. In more normal times, I also love to hike in the mountains, and I’ve taken a few blissful flights on a hang glider. (That’s a hobby I’d love to be more involved with, but the opportunity hasn’t been available lately.) You might also guess, from my avatar, that I’m a fan of Final Fantasy XIV.

In the coming months, I’m hoping to present you all with some blog posts about Pub/Sub in Google Cloud Platform. I’m looking forward to it!