Forem: Shailendra Kumar Gupta

Mastering Multi-Cloud with Go: A Practical Guide to the Cloud Development Kit

Shailendra Kumar Gupta — Mon, 26 May 2025 19:21:10 +0000

Have you ever worked on applications that interact with multiple cloud providers to store or retrieve data?

Yes?

Then you know the pain of writing custom code for each cloud provider’s API. With so many providers on the market, it’s crucial to support as many as possible to attract and retain customers. This flexibility allows customers to choose the best cloud for their needs — otherwise, it’s easy to lose them.

However, each cloud provider has its own API for interacting with cloud storage, making multi-cloud support in a single application challenging. Every new cloud adds more code to maintain.

What if there were a common interface that allowed developers to write generic code to interact with any cloud storage?

This is where the Go Cloud Development Kit (Go CDK) comes in — a set of Go libraries providing a common interface to interact consistently with multiple cloud providers. The goal is to help developers write cloud-agnostic code that runs in any environment with minimal changes.

In this article, I’ll show how to use Go CDK to write cloud-agnostic code for interacting with cloud storage and the local file system. Yes, it even supports the local file system, making it a very flexible solution for all types of storage.

Quick Overview: The `blob` Package

The blob package is a core component of Go CDK, used to read, write, list, and delete blobs (objects/files) from underlying storage.

It uses drivers to support multiple cloud providers:

fileblob: Local filesystem storage
gcsblob: Google Cloud Storage
s3blob: Amazon S3
azureblob: Azure Blob Storage
memblob: In-memory storage (useful for testing)

Now that you understand the basics, let’s dive into some code examples demonstrating how to use Go CDK in Go applications.

Installation and Setup

Install Go CDK using:

go get gocloud.dev

This article uses Google Cloud Storage (GCS) for demonstration.

For GCS:

Download your service account JSON and set it as an environment variable:

export GOOGLE_APPLICATION_CREDENTIALS=<PATH_TO_JSON_FILE>

(You can download this from your GCS service account settings.)

Create a bucket in GCS where you will write objects/files.

Writing an Object to a GCS Bucket

The following example reads data from a local input file and writes it as an object to a cloud bucket:

func testStoringFiles() {
    ctx := context.Background()

    if *bucketURL == "" || *filePath == "" || *objectName == "" {
        log.Fatal("Usage: go run main.go -bucket BUCKET_URL -file FILE_PATH -object OBJECT_NAME")
    }

    bucket, err := blob.OpenBucket(ctx, *bucketURL)
    if err != nil {
        log.Fatalf("Failed to open bucket %q: %v", *bucketURL, err)
    }
    defer bucket.Close()

    f, err := os.Open(*filePath)
    if err != nil {
        log.Fatalf("Failed to open file %q: %v", *filePath, err)
    }
    defer f.Close()

    w, err := bucket.NewWriter(ctx, *objectName, nil)
    if err != nil {
        log.Fatalf("Failed to create writer for object %q: %v", *objectName, err)
    }

    if _, err := io.Copy(w, f); err != nil {
        w.Close() // ignore error from Close if copy fails
        log.Fatalf("Failed to write data to object %q: %v", *objectName, err)
    }

    if err := w.Close(); err != nil {
        log.Fatalf("Failed to close writer for object %q: %v", *objectName, err)
    }

    fmt.Printf("Successfully uploaded %q to bucket %q as object %q\n", *filePath, *bucketURL, *objectName)
}

bucketURL: The bucket where the object will be stored
filePath: The local file to read
objectName: The name of the object to write in the bucket

Reading an Object from a GCS Bucket

This example opens an object in a bucket and prints its contents:

func testReadingFiles() {
    ctx := context.Background()

    bucket, err := blob.OpenBucket(ctx, *bucketURL)
    if err != nil {
        log.Fatalf("Failed to open bucket: %v", err)
    }
    defer bucket.Close()

    reader, err := bucket.NewReader(ctx, *objectName, nil)
    if err != nil {
        log.Fatalf("Failed to open blob reader: %v", err)
    }
    defer reader.Close()

    data, err := io.ReadAll(reader)
    if err != nil {
        log.Fatalf("Failed to read blob data: %v", err)
    }

    fmt.Printf("Contents of %s:\n%s\n", *objectName, string(data))
}

Listing All Objects in a Bucket

This function lists all objects in the specified bucket along with their sizes:

func testListingFiles() {
    ctx := context.Background()

    bucket, err := blob.OpenBucket(ctx, *bucketURL)
    if err != nil {
        log.Fatalf("Failed to open bucket: %v", err)
    }
    defer bucket.Close()

    iter := bucket.List(&blob.ListOptions{})
    for {
        obj, err := iter.Next(ctx)
        if err == io.EOF {
            break
        }
        if err != nil {
            log.Fatalf("Failed to list objects: %v", err)
        }
        fmt.Println("File:", obj.Key, obj.Size)
    }
}

Deleting an Object from a Bucket

The following code deletes a specified object from the bucket:

func testDeletingFile() {
    ctx := context.Background()

    bucket, err := blob.OpenBucket(ctx, *bucketURL)
    if err != nil {
        log.Fatalf("Failed to open bucket: %v", err)
    }
    defer bucket.Close()

    if err := bucket.Delete(ctx, *objectName); err != nil {
        log.Fatalf("Failed to delete object %q: %v", *objectName, err)
    }

    fmt.Printf("Successfully deleted object %q from bucket %q\n", *objectName, *bucketURL)
}

Supported Storage Providers and Bucket URLs

The above functions work with any of the following storage providers by using the appropriate bucket URL scheme:

Provider	Bucket URL Scheme
Google Cloud Storage	`gs://{bucket-name}`
Amazon S3	`s3://{bucket-name}`
Azure Blob Storage	`azblob://{container-name}`
Local File System	`file:///{file-path}`

Conclusion

I hope this article has given you a clear understanding of how to use Go CDK in Go applications. Try out these examples to get hands-on experience. In the future, consider using Go CDK to build cloud-agnostic applications — it simplifies multi-cloud deployment by abstracting provider-specific differences behind a single interface.

Important note: Go CDK supports accessing objects in cloud storage (read, write, list, delete), but it does not support creating buckets. To create buckets, you’ll need to use cloud-specific libraries. For example, to create a bucket in GCS, you must use the Google Cloud Storage client library: cloud.google.com/go/storage.

Bonus Tool Recommendation

If you’re tired of spending time searching for and understanding internal APIs, check out the AI tool LiveAPI. It helps you discover, understand, and use APIs within large codebases, making your API work much easier.

The API Boom: How AI Is Supercharging the Future of Software

Shailendra Kumar Gupta — Sun, 18 May 2025 13:35:45 +0000

Hey everyone,
I'm Shailendra.
Recently, I was studying more about APIs while diving deeper into APIs and exploring how the space is evolving, I stumbled upon a few really interesting reports—especially the Treblle API Report for 2024. That got me digging further, and I came across even more articles and stats showing just how fast the API market is growing.

Here are a few links worth checking out:

Feel Free to download the reports and go through articles to understand more about the API growth over the time.

APIs Are Growing—A Lot

Across the board, all these reports make one thing clear: the API space is growing fast, and a big reason for that is the rapid rise of AI.

As per the Nordic APIs article and Treblle, 83% of All Internet Traffic Belongs to API-Based Services.
As per Imperva, a Thales company, quotes 'API calls make up a massive 71% of all web traffic'.

These all reports very clearly mention that APIs are growing drastically.

Some other stats:

Postman users grew by 40%. Source – Postman State of API 2024
AsyncAPI downloads jumped by 240% in 2023. Source – AsyncAPI 2023 Summary
API-first development is up by 74%. Source – InfoWorld

So both AI-related and non-AI APIs are growing, but the AI ones? They’re blowing up.

Graphical data from Treblle, showing the AI related API growth:

Quick Recap: What Are APIs and AI APIs?

What is an API?

APIs (Application Programming Interfaces) are basically bridges—sets of tools and protocols that let different apps talk to each other, safely and efficiently. They’re what glue the digital world together.

What is AI?

AI (Artificial Intelligence) is all about machines mimicking human intelligence—understanding text, images, sound, and making decisions or predictions based on that.

And AI-related APIs?

These are APIs that bring AI features into apps. Think: language understanding, image recognition, voice processing, etc.—all made easily accessible via simple API calls. No need to build complex models from scratch.

So Why Is AI Driving API Growth?

Honestly, I think it’s a two-way street—AI and APIs are helping each other grow. Here's why:

AI models need lots of data, and APIs are a major way to get that data.
Most AI services expose their capabilities through APIs—makes tracking, scaling, and integration much easier.
APIs make it super simple to plug AI features into apps, products, or services.

So naturally, as AI adoption grows, so does the demand for APIs.
Check out some graphs that depicts the API growth in past few years.

But It’s Not All Smooth Sailing

One thing several reports pointed out—and something I’ve seen firsthand—is that a lot of APIs are poorly documented or managed. This slows everything down.

Developers end up spending too much time figuring out how an API works instead of actually building things. And with the pace we’re moving at, that’s a problem.

That’s why I was glad to see some cool AI tools popping up to solve this—LiveAPI is one I came across that looks promising. It’s designed to help developers better understand, manage, and work with APIs more efficiently.

If you're working with APIs, I’d highly recommend checking it out. Go try it—it might really boost your productivity!

Wrapping It Up

2024 is clearly a breakout year for APIs. A few quick highlights:

We’re now looking at 15,000+ APIs, 500,000+ endpoints, and over 1 billion API requests
The average API now has 42 endpoints, nearly double from last year
Large enterprises are managing 1,000+ APIs, mostly for internal use
And AI-related APIs? They grew by a whopping 807%—compared to 10% growth in other API sectors

This isn't just about tech—it’s about how businesses operate and scale. APIs are at the heart of digital transformation, and with AI in the mix, that momentum is only picking up.

Big players like Amazon, Google, Salesforce, and Meta are a great example—they’ve deeply embedded APIs and AI into their products and operations, and it shows in their growth and market dominance.

Final Thoughts

APIs are no longer just backend utilities—they’re core to modern business. They enable speed, scalability, security, and innovation. And in this AI-driven world, getting APIs right is crucial.

If you’re working in tech today, understanding and leveraging APIs (especially AI-driven ones) isn’t just useful—it’s essential.

Digging Deeper into Code with Tree-Sitter: How to Query Your Syntax Tree

Shailendra Kumar Gupta — Wed, 14 May 2025 00:30:48 +0000

Hello everyone! I'm Shailendra.
In my last post — 'Tree-Sitter: From Code to Syntax-Tree' — I talked about how we can use Tree-sitter to generate a syntax tree for a given language using its grammar.

In this post, we’ll go one step further and see how Tree-sitter can be used to make queries on your source text to understand and analyze various parts of the code.

This is another very interesting feature of Tree-sitter that can help you get deeper insights into your source code. For example, you can write a query to list all the functions present in a repo's source code. And that's exactly what we’ll explore in this post.

Just like the last post, I’ll use GoLang for demonstrating the use cases. If you’re not familiar with how to use Tree-sitter in GoLang, please check the previous post for installation steps and the basic code setup.

Our Use Case

Now, let’s get into our use case. As mentioned, I’ll demonstrate how to list all the functions from a given source file.

Here’s the GoLang code we’ll be analyzing:

package main

import "fmt"

func add(num1 int32, num2 int32) int32 {
    return num1 + num2
}

func subtract(num1, num2 int32) int32 {
    return num1 - num2
}

func calculator(operator string, num1, num2 int32) int32 {
    switch operator {
    case "+":
        return add(num1, num2)
    case "-":
        return subtract(num1, num2)
    default:
        fmt.Errorf("Unknown operator")
    }

    return -1
}

Parse Tree Output

Let’s quickly look at how the parse tree would look for this code:

(source_file
  (package_clause
    (package_identifier))

  (import_declaration
    (import_spec
      path: (interpreted_string_literal)))

  (function_declaration
    name: (identifier)
    parameters: (parameter_list
      (parameter_declaration
        name: (identifier)
        type: (type_identifier))
      (parameter_declaration
        name: (identifier)
        type: (type_identifier)))
    result: (type_identifier)
    body: (block
      (return_statement
        (expression_list
          (binary_expression
            left: (identifier)
            right: (identifier))))))

  (function_declaration
    name: (identifier)
    parameters: (parameter_list
      (parameter_declaration
        name: (identifier)
        name: (identifier)
        type: (type_identifier)))
    result: (type_identifier)
    body: (block
      (return_statement
        (expression_list
          (binary_expression
            left: (identifier)
            right: (identifier))))))

  (function_declaration
    name: (identifier)
    parameters: (parameter_list
      (parameter_declaration
        name: (identifier)
        type: (type_identifier))
      (parameter_declaration
        name: (identifier)
        name: (identifier)
        type: (type_identifier)))
    result: (type_identifier)
    body: (block
      (expression_switch_statement
        value: (identifier)

        (expression_case
          value: (expression_list
            (interpreted_string_literal))
          (return_statement
            (expression_list
              (call_expression
                function: (identifier)
                arguments: (argument_list
                  (identifier)
                  (identifier))))))

        (expression_case
          value: (expression_list
            (interpreted_string_literal))
          (return_statement
            (expression_list
              (call_expression
                function: (identifier)
                arguments: (argument_list
                  (identifier)
                  (identifier))))))

        (default_case
          (expression_statement
            (call_expression
              function: (selector_expression
                operand: (identifier)
                field: (field_identifier))
              arguments: (argument_list
                (interpreted_string_literal))))))

      (return_statement
        (expression_list
          (unary_expression
            operand: (int_literal))))))
)

Notice how the parameters in the add and subtract functions are presented differently. That’s because Go allows you to group parameters with the same type, and Tree-sitter reflects that nicely in the syntax tree.

Printing the Syntax Tree

Here’s the main code that prints the above Tree-sitter output:

package main

import (
    "context"
    "fmt"
    "log"
    "os"

    tree_sitter "github.com/smacker/go-tree-sitter"
    "github.com/smacker/go-tree-sitter/golang"
)

func main() {
    parser := tree_sitter.NewParser()
    parser.SetLanguage(golang.GetLanguage())

    data, err := os.ReadFile("example.go")
    if err != nil {
        log.Fatal(err)
    }
    tree, err := parser.ParseCtx(context.Background(), nil, data)
    if err != nil {
        log.Fatal(err)
    }

    root := tree.RootNode()
    fmt.Println("Root type:", root.Type())
    fmt.Println("Tree:
", root.String())
}

Note: The source code above is part of the example.go file.

Querying Function Names

Now, let’s try to capture all the function names in the source. To do this, we’ll provide a query that matches all the function names in the syntax tree.

A function node looks like this:

(function_declaration
    name: (identifier)
    parameters: (parameter_list)
    result: (type_identifier)
    body: (block)
)

To extract just the function name:

(function_declaration
    name: (identifier) @function-name
)

Code for this query:

package main

import (
    "context"
    "fmt"
    "log"
    "os"

    tree_sitter "github.com/smacker/go-tree-sitter"
    "github.com/smacker/go-tree-sitter/golang"
)

var (
    function_declarations_query = `
        (function_declaration
            name: (identifier) @function-name
        )
    `
)

func main() {
    parser := tree_sitter.NewParser()
    parser.SetLanguage(golang.GetLanguage())

    data, err := os.ReadFile("example.go")
    if err != nil {
        log.Fatal(err)
    }
    tree, err := parser.ParseCtx(context.Background(), nil, data)
    if err != nil {
        log.Fatal(err)
    }

    query, err := tree_sitter.NewQuery([]byte(function_declarations_query), golang.GetLanguage())
    if err != nil {
        log.Fatal(err)
    }

    cursor := tree_sitter.NewQueryCursor()
    cursor.Exec(query, tree.RootNode())

    for {
        match, more := cursor.NextMatch()
        if !more {
            break
        }

        for _, capture := range match.Captures {
            node := capture.Node
            fmt.Println("Found function:", node.Content(data))
        }
    }
}

Output:

$ go run main.go 
Found function: add
Found function: subtract
Found function: calculator

Querying Parameters as Well

To print the parameters as well, update the query like this:

(function_declaration
    name: (identifier) @function-name
    parameters: (parameter_list) @parameter-list
)

We just added this:
parameters: (parameter_list) @parameter-list

Output:

$ go run main.go 
Found function: add
Parameters list: (num1 int32, num2 int32)
Found function: subtract
Parameters list: (num1, num2 int32)
Found function: calculator
Parameters list: (operator string, num1, num2 int32)

Final Thoughts

Hope this helps clarify how we can use queries in Tree-sitter to analyze different parts of the code. I encourage you to explore more by experimenting with different queries and observing the output. That’s the best way to understand how Tree-sitter represents various parts of source code using syntax tree nodes.

🔔 Important Note

Before we wrap up — if you’re someone who’s tired of wasting time searching and trying to understand internal APIs, do check out the AI tool LiveAPI. It’s a pretty handy tool for working with internal APIs in large codebases.

LiveAPI helps you discover, understand, and use APIs within big tech infrastructures.

Ease your API life with LiveAPI.

Tree-Sitter: From Code to Syntax-Tree

Shailendra Kumar Gupta — Sun, 11 May 2025 20:21:37 +0000

I’m Shailendra, and in this article, I’m going to talk about a very interesting tool called Tree-sitter. I recently came across this tool while going through another interesting tool for APIs: LiveAPI.

As per the definition, Tree-sitter is a parse generator tool and an increment parsing library.

Let’s understand what we mean by these terms. I’m sure many of you already know about it but just to make sure everyone understands, let’s describe them quickly.

Parse Generator Tool: These are the tools that automates the process of developing/creating parser (a component that analyses the syntactical correctness of a language and throws appropriate errors). One can avoid the manual work of writing parsers, by providing grammar specifications to such tools. The tool automatically translates it into a parser.

Input: Grammar for a language.
Output: A parser that can analyze texts for specified grammar.
Some other examples of parser generator tools: YACC (Yet Another Compiler Compiler), JavaCC (Java Compiler Compiler), Lark, etc.

Increment parsing library: This means that Tree-sitter efficiently parses the code by ONLY analysing the changed/modified part of the source file.

Now, that we know what about Tree-sitter. Let’s try to see it in action to understand how we can use it.
I’ll use GoLang to demonstrate my learnings about the tool. Also, I’ll use the same language parser to show the usages of this tool. However, the tool is supported on multiple languages. Feel free to use the learnings from here and apply it to your specific language.

There are two ways in which we can install for use.

Download the source from git and compile for use. Tree-sitter
GoLang wrapper libraries to ease your life.

I'll use second method as part of this article. Use below commands to download and install the dependencies:

Download the tree-sitter library for GoLang.

go get github.com/smacker/go-tree-sitter

Download the GoLang parser.

go get github.com/smacker/go-tree-sitter/go

Let’s analyse a basic GoLang code using tree-sitter.
GoLang code that we are going to analyse:

func add(num1 int, num2 int) {
    return num1 + num2 * 3
}

Main code for analysing the source text:

package main

import (
    "context"
    "fmt"
    "log"

    tree_sitter "github.com/smacker/go-tree-sitter"
    "github.com/smacker/go-tree-sitter/golang"
)

var (
    source_text = `
        func add(num1 int, num2 int) {
            return num1 + num2 * 3
        }
    `
)

func main() {
    parser := tree_sitter.NewParser()
    parser.SetLanguage(golang.GetLanguage())

    code := []byte(source_text)
    tree, err := parser.ParseCtx(context.Background(), nil, code)
    if err != nil {
        log.Fatal(err)
    }

    root := tree.RootNode()
    fmt.Println("Root type:", root.Type())
    fmt.Println("Tree:\n", root.String())
}

Output:

$ go run main.go
Root type: source_file
Tree:
 (source_file (function_declaration name: (identifier) parameters: (parameter_list (parameter_declaration name: (identifier) type: (type_identifier)) (parameter_declaration name: (identifier) type: (type_identifier))) body: (block (return_statement (expression_list (binary_expression left: (identifier) right: (binary_expression left: (identifier) right: (int_literal))))))))

Let's understand the output of the program. Tree-sitter gives output in the form of a syntax tree representing different parts of the text with root as the source file (containing the text).

source_file
└── function_declaration
    ├── name: identifier
    ├── parameters: parameter_list
    │   ├── parameter_declaration
    │   │   ├── name: identifier
    │   │   └── type: type_identifier
    │   └── parameter_declaration
    │       ├── name: identifier
    │       └── type: type_identifier
    └── body: block
        └── return_statement
            └── expression_list
                └── binary_expression
                    ├── left: identifier
                    └── right: binary_expression
                        ├── left: identifier
                        └── right: int_literal

From the input text, a programmer can understand that the input text is GoLang program representing as follows:
1. A single function.
2. Taking 2 integers as input.
3. Summing them up after multiplying num2 by 3.
4. returns the calculated value.

The Tree-sitter tool also outputs the same. It doesn’t prints the different identifiers and their names, as they are not required for syntax parsing. It just differentiates various parts of the text and related them as per the language grammar. The same you can see from the readable output of the Tree-sitter.

This shows how Tree-sitter uses a language grammar and analyses the source text. This can help you to understand whether a given set of source files follows your language grammar or not? In case of programmer languages, you can take Tree-sitter helps to verify the same without compiling all your source codes. Also, note that you do not need compilers to be installed for such analysis.

Hope this clarifies a use-case of this tool. Apart from this, there a lot of interesting use-cases for this tool. Some of them I'll try to cover in future posts. For more details on the tool you can refer the website: Tree-sitter
Also, do watch this interesting video of Tree-sitter:YouTube which helped me to understand the basic of it.

IMPORTANT NOTE:
BTW, before we wrap-up. If you are a person tired of wasting time on searching and understanding your internal APIs, do check the AI tool LiveAPI. It is an interesting AI tool for all your internal APIs. LiveAPI helps you discover, understand and use APIs in large tech infrastructures. Ease your API life with LiveAPI.

Forem: Shailendra Kumar Gupta

Mastering Multi-Cloud with Go: A Practical Guide to the Cloud Development Kit

Quick Overview: The blob Package

Installation and Setup

Writing an Object to a GCS Bucket

Reading an Object from a GCS Bucket

Listing All Objects in a Bucket

Deleting an Object from a Bucket

Supported Storage Providers and Bucket URLs

Conclusion

Bonus Tool Recommendation

The API Boom: How AI Is Supercharging the Future of Software

APIs Are Growing—A Lot

Quick Recap: What Are APIs and AI APIs?

What is an API?

What is AI?

And AI-related APIs?

So Why Is AI Driving API Growth?

But It’s Not All Smooth Sailing

Wrapping It Up

Final Thoughts

Digging Deeper into Code with Tree-Sitter: How to Query Your Syntax Tree

Our Use Case

Parse Tree Output

Printing the Syntax Tree

Querying Function Names

Output:

Querying Parameters as Well

Output:

Final Thoughts

🔔 Important Note

Tree-Sitter: From Code to Syntax-Tree

Quick Overview: The `blob` Package