Mete Atamel

In AsyncAPI, a channel can have a publish and subscribe operation. This can be confusing, depending on which perspective you’re considering (server vs. user) and what you’re comparing against (eg. WebSocket).

In this blog post, I want to go through an example to show you how to construct your AsyncAPI file with the right publish and subscribe semantics. As a bonus, I also show you how to refactor your AsyncAPI files with common configuration.

In my previous post, I talked about basic of AsyncAPI. In this post, I want to get into more details on some tools around AsyncAPI.

More specially, we’ll install AsyncAPI CLI and Generator, generate a sample AsyncAPI definition, visualize it in AsyncAPI Studio, and generate code from it. You’ll see how useful AsyncAPI can be in documenting and maintaining your event-driven architectures.

Install AsyncAPI tools

First, let’s install some of the AsyncAPI tools.

Recently, I’ve been looking into AsyncAPI, an open-source specification and tools to document and maintain event-driven architectures (EDAs).

In this blog post, I want summarize the basics of AsyncAPI and point to some useful links to learn more. In future blog posts, I’ll get into more details of AsyncAPI.

AsyncAPI: Why? What?

AsyncAPI is an open source initiative with the goal of making event-driven APIs as easy as REST APIs. Fundamentally, it is a specification to define asynchronous APIs, similar to what OpenAPI (aka Swagger) does for REST APIs.

Cloud Tasks is a fully-managed service that manages the execution, dispatch, and asynchronous delivery of a large number of tasks to App Engine or any arbitrary HTTP endpoint. You can also use a Cloud Tasks queue to buffer requests between services for more robust intra-service communication.  

Cloud Tasks introduces two new features, the new queue-level routing configuration and BufferTask API. Together, they enable creating HTTP tasks and adding to a queue without needing the tasks client library.

If you use Workflows, you’ve been crafting your Workflows definitions in YAML (or JSON). You’re probably painfully aware of the limited support you get in your IDE with syntax validation or auto-completion with these YAML definitions. This was due to Workflow’s schema being out of date, as I covered in my previous post last year.

I’m happy to report that our team recently updated the Workflows schema with the latest syntax. With a new schema, you get a much improved syntax validation and auto-completion of Workflows definition files in your favorite IDE. 

I talked about CloudEvents in the context of event-driven architectures before. In this post, let’s explore CloudEvents in more depth.

CloudEvents: Why? What?

CloudEvents is a popular specification for describing event data in a common way with the goal of increasing interoperability between different event systems.

Google Cloud’s Eventarc, open-source Knative, Azure’s Event Grid, and many more projects rely on CloudEvent specification to define their event formats.

Cloud Code is a set of IDE plugins for popular IDEs that make it easier to create, deploy and integrate applications with Google Cloud. Cloud Code provides an excellent extension mechanism through custom templates. In this post, I show you how you can create and use your own custom templates to add some features beyond those supported natively in Cloud Code, such as .NET functions, event triggered functions and more. 

In a startup, you need to get to the MVP fast, gather feedback from early adopters, and iterate in a quick cycle. Anything that takes time away from developing and iterating on features delays the launch and that’s a serious problem when time-to-market is crucial.

Google Cloud offers products that can help you to build and run your backend services on a fully managed serverless platform, saving time and freeing you from the burden of provisioning and managing infrastructure needed to run those services. Less time on infrastructure means more time implementing and iterating on your services. Additionally, most serverless products have a pay-as-you-go pricing model with little upfront cost at the beginning. Pricing increases in line with the scale of your services and your startup, so you only pay for what you need, when you need it

Cloud Code has been providing IDE support for the development cycle of Kubernetes and Cloud Run applications for a while now. I’m happy to report that the Dec 2022 version (1.21.0) of Cloud Code now supports Cloud Functions!

In this first release of Cloud Functions support, you can:

• Use the Cloud Functions Explorer to view your project’s Cloud Functions properties and source code.
• Download your Cloud Functions to edit your code locally, then configure your local workspace to deploy those changes directly from Cloud Code.
• Invoke your HTTP-triggered functions from VS Code.
• Use the Cloud Code Logs Viewer to view logs from your Cloud Functions.

Let’s take a closer look.

This is a three-part series of posts, in which we summarize Workflows and service orchestration patterns. In this third and final post, we talk about managing workflow life cycles and the benefits of using Firestore with Workflows.

If you’re not careful, the workflow definitions you create with YAML or JSON can get out of hand pretty quickly. While it is possible to use subworkflows to define snippets of a workflow that can be reused from multiple workflows, Workflows does not support importing these subworkflows. Thankfully, there are other tools, such as Terraform, that can help.