The trigger turned out to be a USB → 3.5 mm audio adapter, specifically:

UGREEN USB to 3.5mm Audio Adapter

https://www.amazon.com/UGREEN-Adapter-Support-Headphone-Compatible/dp/B08Y8CZB2S

Unplug the adapter, and sleep worked flawlessly. Plug it back in, and the system would appear to sleep — only to resume a few seconds later.

Why This Adapter Was in the Setup

This wasn’t an arbitrary addition.

My desktop sits under the table, making the onboard 3.5 mm audio jack hard to reach. On top of that, the machine is connected to a KVM switch, which further complicates cable access.

The USB adapter seemed like a clean solution:

• Extend audio output to an easily accessible USB port
• Avoid reaching under the desk
• Keep the setup KVM-friendly

Functionally, it worked exactly as intended. Power management, however, was a different story.

The Problem

The behavior was consistent and reproducible:

• USB adapter connected → system never stays asleep
• USB adapter disconnected → system sleeps normally

From the UI:

• Display turns off
• Fans briefly spin down
• Within ~5 seconds, the system resumes

At this point, I assumed this would be a fairly common issue with a well-documented fix.

That assumption turned out to be wrong.

Initial Analysis (and Dead Ends)

I started with the usual suspects:

Stack Overflow Superuser Reddit threads on Windows sleep issues

While there was plenty of generic advice, nothing directly explained a scenario where:

• powercfg /requests showed no blockers
• The system still failed to remain asleep
• A single USB device made or broke sleep behavior

Most of what follows was learned during the investigation, not beforehand.

Learning the Right Tools Along the Way

After exhausting forum searches, I started digging through documentation, blog posts, and scattered references — slowly building a mental model of how Windows sleep actually works.

That’s when commands like these entered the picture:

powercfg /requests
powercfg /a
powercfg /sleepstudy

Each answered a different question:

• Is something explicitly blocking sleep?
• Which sleep states does this system actually support?
• Is sleep failing or waking?

None of these were tools I was deeply familiar with before this issue.

Verifying Supported Sleep States

Running:

powercfg /a 

showed:

The following sleep states are available on this system:
    Standby (S3)
    Hibernate

The following sleep states are not available:
    Standby (S0 Low Power Idle)

This ruled out Modern Standby entirely and confirmed the system was using classic S3 sleep.

The Smoking Gun: Event Logs

The real breakthrough came not from forums, but from Event Viewer.

Every failed sleep attempt logged:

The system is entering sleep.
Sleep Reason: Hibernate from Sleep - Fixed Timeout

Followed shortly (~5 seconds) by:

The system has resumed from sleep.

This was the turning point.

This wasn’t a wake event — it was a failed sleep transition.

The system never actually reached S3.

What Was Actually Happening

Looks like, in an S3 sleep transition below is what happens at an high-level:

Windows prepares devices for suspend Control passes to firmware (ACPI) All devices must sleep correctly If any device fails, firmware aborts sleep

In this case:

The UGREEN USB audio adapter failed to suspend cleanly Firmware aborted the transition The system immediately resumed

The Fix

Disable USB Selective Suspend

The fix turned out to be simple:

Control Panel → Power Options → Change plan settings → Advanced

USB settings
 └─ USB selective suspend setting → Disabled

After rebooting:

• S3 sleep completed successfully
• The USB adapter no longer caused immediate resume

Final Thoughts

The USB adapter solved a real usability problem — extending audio from a hard-to-reach desktop connected via a KVM — but introduced a subtle firmware-level power issue that Windows could not clearly explain.

This experience was a reminder that:

• The internet doesn’t always have the answers — even for seemingly common issues.
• Digging into official documentation, scattered blog posts, and related resources can pay off.
• Patience matters: the issue you see may not be the root cause, and understanding it can take some digging.

This becomes even more complicated when dealing with disparate technologies. For instance, within my team at work, we handle React, .NET, Java, and Python for various UI/API workloads, along with a mix of MS SQL, Oracle, and Postgres for databases.

My team has been facing challenges with performing a good integration testing in their local system before pushing their code changes into the main branch, which in turn results in bugs leaking into our integration environment causing wasted efforts from Developers and QAs.

.Net Aspire

One area where .NET Aspire could greatly help is in orchestration. Aspire assists with various tasks, such as orchestration of different components, Integrations, Deployments etc.

Since I was dealing with multiple technologies, my primary focus for leveraging Aspire was around the below areas,

1. Orchestration
2. Consistent starting point for integration
3. Local logging and Observability
4. Integration Testing

Orchestration

Here Aspire allows us to programmatically specify how to spin up the different components involved, configure them and wire them up. Don’t let the “.net” in its name fool you, its not just meant for orchestrating .Net workloads, but it can work across .Net projects, Containers, and Executables. And with its Extensibility Support, possibilities are endless to extend it to other areas too. For instance, I will cover later about how I am leveraging support for Java’s Spring Boot applications.

Consistent Starting point for integration

While this is not something specific to .Net Aspire, this is one of the major pain points for our team at work, where our QAs had to comb through our Test environment for hours to gather all the test data needed for them to run their test cases.

The goal is not just to bring up all the necessary components, but also to ensure that every time this happens, all components have a standardized set of data as a starting point. This way, developers don’t have to worry about what data to use for testing during feature development, and integration tests can rely on a consistent set of data that is referenced across all components.

Local logging and Observability

During the development phase, all developers leverage logging as a tool to help troubleshoot problems, but having Observability in other integration and Production environments is what makes everybody’s life so much more easier.

Integration Testing

The final goal is to run the automated regression test suite on the developer’s local machine without needing to go through tedious data collection (whether automated or manual) every time the tests are run.

Setup

Before I started trying out our actual production workloads via Aspire, I puttogether a POC using .Net, Java and Postgresql to float this idea within the team (to my surprise, no one at this point in time within my team - all .Net developers, had come across .Net Aspire). This POC setup is what I will be talking about here.

I wanted to get things setup very quickly, so I ended up using the sample Project template .Net Aspire comes with, and plugged in a Java Spring Boot application and a Postgresql Database along with them.

My POC setup had the below components in it,

1. .Net Blazor Web App for UI
2. .Net ASP .Net Core Web API Project for API
3. Java Spring Boot Application for API
4. Postgresql Database that Java API uses

The relationship/dependency between them is as below.

Pre-requisites and my challenges

I am not going to be covering the tooling or installation/setup as part of this article, as Microsoft’s documentation covers it at good lengths. But rather, I will be talking about what challenges I ran into while getting my POC running in our Enterprise setup (On the personal front, it was a breeze)

First of all, one of the key things that makes things easier with Aspire is the ability to run containers as part of the orchestration. This is also how some of the out-of-the-box components like PostgreSQL and Elasticsearch are run by Aspire.

This is where I started running into issues with my org’s dev environment setup - I can’t use Docker Desktop due to licensing restrictions—Challenge #1.

As a logical next step, since Aspire supports Podman, I was eager to try it out. Only to find out that the Dev environment was running an older version of windows which cannot install/support Podman - Challenge #2.

I was trying out ways to get the Windows version updated, but also parallely was researching in my person PC to see if Podman is going to solve my problems. Glad I took this step before moving too much forward with seeking approvals and exceptions to get the windows version upgraded, as I ran into issues while using Podman, which I have not run into while using Docker Desktop.

All problems I have run into seemed to have been around networking, where the containers running inside WSL was not able to communicate with Aspire Proxt, and vice versa.

I assumed this is a problem with Podman itself, and then went on to try running Docker runtime in WSL, and try setting up Docker CLI in windows that can route all the commands to Docker running in WSL. Sure enough, I ran into the same problems as that of when I was running the containers through Podman.

So, this looks like some networking issues in being able to bridge the system’s local network with that of the virtual network that WSL uses. Docker Desktop seems to be doing some networking magic, that somehow makes things work seamlessly.

At this point, I pretty much gave up on Aspire+Containers combo, and decided to get things working without any Containers involved.

Not that anyone reads my blog, but if someone from Microsoft happens to be stumbling into this post - “Considering the licensing requirements around Docker Desktop, please prioritize addressing the networking issues involved in Aspire+Podman/WSL, and support Podman as a first class citizen to ensure rapid enterprise adoption of Aspire.” In my case, chances of mass procurement of Docker Desktop licenses for the org. and making everyone adopt might not be a feasibility, at least in the near future.

POC

When it comes to the POC itself, again, I am not planning on covering the .Net pieces as Aspire documentation does a good (enough?) job of covering it.

Rather, I will be focusing on how I got the Java and Postgres instances setup, as well as how I made them all talk to one another.

To refresh, my POC will be focusing on the below connectivity,

1. Java API -> PostgreSQL
2. Java API -> .Net API
3. Blazor UI -> Java API

Hosting the Java API

My initial plan for running the Java application was to run it using Aspire’s Container support. But, now that I would have to do away without Containers, I started looking for alternate option.

I was already aware that I could run any executable via Aspire, using

builder.AddExecutable()

method. But then, I realized that there is a Community built Java support via CommunityToolkit.Aspire.Hosting.Java.

While I could have achieved similar outcome with AddExecutable(), AddSpringApp() method from the above Nuget package makes things easier. Here’s how I approached it:

var javaApi = builder.AddSpringApp("javaapi", "../Other Dependencies/sampleapi",
        new JavaAppExecutableResourceOptions() {
            OtelAgentPath = "lib/",
            ApplicationName = "target/sampleapi-0.0.1-SNAPSHOT.jar",
            Port=8090
        })
    .WithMavenBuild()
    .WithEnvironment("DB_URL", $"jdbc:postgresql://{postgresHostname}/{postgresDBName}")
    .WithEnvironment("DB_USERNAME", $"{postgresUsername}")
    .WithEnvironment("DB_PASSWORD", $"{postgresPassword}")
    .WithOtlpExporter()
    .WithHttpEndpoint(8090, name: "javaapi-http", isProxied:false)
    .WithReference(apiService)
    .WithReference(postgresDB)
    .WaitFor(postgresDB);

Did you notice, it even allows triggering a Maven Build before launching the instance, which is pretty neat.

I am injecting few Environment variables into the Service, so that I can later refer to it within the Java Application.

    .WithEnvironment("DB_URL", $"jdbc:postgresql://{postgresHostname}/{postgresDBName}")
    .WithEnvironment("DB_USERNAME", $"{postgresUsername}")
    .WithEnvironment("DB_PASSWORD", $"{postgresPassword}")

Here, WithReference(postgresDB) isn’t really helpful, as it primarily injects information allowing that service to be configured via connection strings. Since the service I am running is a Java workload, I don’t think they help in any way, but I still wanted to retain it as it explicitly calls out the dependency for anyone looking into that code.

Since Postgresql connection strings are defaulted to what is needed for .Net, I was looking at options to see how to override formatting of the connection strings. But, since I wasn’t able to find a way to do it, I ended up pulling the individual pieces of information and framing the URL myself.

Managing Dependencies (Java API -> PostgreSQL and .Net API)

As I had mentioned above, for configuring the Postgres instance, I am injecting the connection string, User name and Password as environment variables, so that I can refer to those within the Java Config files.

For my purposes that environment variables used as DB_URL, DB_USERNAME and DB_PASSWORD.

I referenced them within the Java application.properties file like this:

spring.application.name=sampleapi

spring.datasource.url=${DB_URL:}
spring.datasource.username=${DB_USERNAME:}
spring.datasource.password=${DB_PASSWORD:}

api.weather.url=${services__apiservice__http__0}

As for the URL of .Net API that I wanted to refer to, Aspire injects it as part of the call to WithReference(apiService) as an environment variable. I am merely refering to the same, by following the naming convention it uses.

` services__SERVICENAME__ENDPOINTNAME__EDNDPOINTINDEX

Note: Default endpoint name assigned is “http”/”https”.

Hosting the Database

For the database, I decided to use containers, so I set it up like this:

var postgresDB = builder.AddPostgres("localPg", pgUsername, port:60123)
    .WithBindMount("../Data/postgres/seed-data", "/docker-entrypoint-initdb.d")
    .AddDatabase("postgres");

This creates a new Postgresql container with “postgres” as the database, User name passed under pgUsername, Port as 60123, and a random password.

Do also note the use of WithBindMount() which allows us to execute arbitary SQL commands at the time of initializing the container. I am using this to ensure that the necessary tables are created as well as they are loaded with some initial data.

Managing Dependencies (.Net -> Java API)

This direction of dependency is pretty easy to Handle with Aspire’s Service Discovery capabilities.

All that is needed is for us to tell Aspire that the .Net Project depends on the Java Project, like below,

builder.AddProject<Projects.MyTestAspireApp_Web>("webfrontend")
    .WithExternalHttpEndpoints()
    .WithReference(apiService)
    .WithReference(javaApi);

and then refer to the Java API by its service name, and let Service Discovery do the trick for us.

builder.Services.AddHttpClient<JavaAPIClient>(client =>
{
    client.BaseAddress = new("https+http://javaapi");
});

Observability

Observability is one of the key things that I love about Aspire - it makes it so much easier to achieve within the local dev environment.

For any .Net projects that leverages ServiceDefaults, Open Telemetry is autoconfigured by default.

But, for my Java workload I had to take some extra steps (nothing too complex though). To begin with, the java otel instrumentation agent had to be downloaded and placed within AAspire solution folder, which then needs to be passed into AddSpringApp(). After that the WithOtelExporter() needs to be called to ensure that all environment variables related to OTEL (with URL, Password etc.) is injected into the service.

End Result

You can refer to the code mentioned above in this GitHub repository.

I am pretty pleased with what we could achieve with Aspire, and how much time it could help save for developers and QAs.

If you haven’t already tried Aspire, do give it a spin right away!

A recent encounter

I have been using Google Cloud Platform (GCP) for around 4 years now, and I recently stumbled upon something that got me thinking about this topic.

GCP’s Cloud Run service seems to have made a subtle but impactful change to its billing configurations. Previously, we had a config that was called “CPU only allocated during request processing” and “CPU always allocated”, to control whether we want the service to be always active listening for traffic, or wake up only in cases when traffic comes in. While these names were functional, they could leave users scratching their heads, especially when it came to understanding their billing implications.

The new names, “request-based billing” and “instance-based billing,” bring immediate clarity. With these terms, the behavior is more intuitively understood. “Request-based billing” communicates that CPU resources are allocated only during active requests, while “instance-based billing” signifies that CPU is allocated for the entire lifespan of the instance, regardless of request activity.

This simple change in terminology makes it easier for users to quickly grasp how their billing is structured, without wading through technical jargon. It highlights how something as basic as naming can impact the user experience, making services more approachable and minimizing the learning curve.

Takeaway

For developers and product teams, this is a reminder of the power of names. A well-thought-out name can provide a clearer mental model for users, reduce confusion, and improve overall satisfaction. When designing, building or documenting software, taking the time to get the names right is not just a good practice—it’s a fundamental part of delivering a great product.

Or, should I say, almost forgotten—because, over the holidays, I randomly started thinking about it again and decided to test the solution just to satisfy my own curiosity, if nothing else.

A Recap of the Potential Solution

Here’s a quick reminder of the approach I was considering:

1. Keep the database in the US region: Creating a regional replica would be cost-prohibitive.
2. Deploy the APIs to EMEA/APAC regions.
3. Introduce PgBouncer: Use PgBouncer between the API and DB, hosted in the US region (closer to the DB).
4. Persistent Connection Pooling: Configure PgBouncer with a pool of 20-30 connections to the DB and keep them persistent (min and max pool size set the same).
5. API Connection to PgBouncer: API instances would connect to PgBouncer and maintain a persistent connection.

Instead of setting up an elaborate testing environment, I decided to simplify things. Since I’m not on my organization’s Google Cloud instance, I had to figure out how to simulate the original problem of cross-region database connectivity. After a fair bit of searching, I settled on the following setup:

After some fair bit of searching for options, I landed on the below setup,

1. A simple .NET console application: This would connect to the database, run 50 queries, and log the time taken.
2. I’d repeat this for different databases and configurations (more on this below).
3. For the database to be hosted in different regions, I decided to use CockroachDB—they offer a free option, and it’s wire-compatible with PostgreSQL.

Testing Scenarios

In this round of testing, I wanted to evaluate the following configurations:

1. DB hosted on the same machine as the client application.
2. DB hosted in the GCP us-central1 region using CockroachDB, while the client application runs on my desktop.
3. DB hosted in the GCP eu-west1 region using CockroachDB, while the client application runs on my desktop.

For each of these configurations, I ran through the following scenarios:

1. No Connection Pooling
2. 1 Pooled Connection with a 5-second lifetime
3. 1 Pooled Connection with a 5-minute lifetime

I wrote a simple .NET console app that would issue 50 sequential queries to the database with a 0.5-second delay between each query.

Results

Below are the performance results across the different configurations:

As expected, the performance was poor when no connection pooling was applied. The performance improved as we pooled connections for a shorter time frame, with the best results seen when the connections were persistent (5 minutes in this case). Given the sample runs lasted about 1 minute, this persistence was sufficient for optimal performance.

Note: I am based out of US West

Visualizing the Results

Here are some charts that capture the timing across the different configurations and scenarios:

Note: The spikes on the red lines indicate connection disposal, which forces the application to reacquire a new connection to the DB, causing those performance dips.

While the DevOps team worked hard to move most of the workload to their corresponding regions—mirroring services for both EMEA and APAC regions—there were still spikes in latency around key parts of the website after the migration. That’s when my team was asked to look into it.

We rely heavily on database queries in the areas my team manages, and it turns out that, for cost reasons, the databases weren’t replicated in the corresponding regions. And now, you probably see where this is going…

##The Core Problem: Cross-Region API to DB Connectivity

While the API services were successfully migrated to EMEA and APAC regions, they still needed to reach the database in the US region. This cross-region DB connectivity introduced substantial latency, which became more problematic when the connection pool frequently disposed of DB connections. This meant that connections had to be reacquired often, which was both slow and costly.

The reason we can’t have the API maintain long-lived connections to the DB is that the APIs run on 10-20 different Cloud Run instances at any given time, with the potential to scale up to 80 instances. If each instance were to maintain around 5 persistent connections, the number of active connections to the DB could quickly become unmanageable, leading to DB performance issues.

After much deliberation, we decided to move the APIs back to the US region. This would eliminate the DB latency, leaving us with only API-to-API calls that had to cross regions. Since these API-to-API calls were much less frequent than the API-to-DB calls, the overall cross-region latency was significantly reduced.

##Other Thoughts: A Potential Solution for the Future

While this solution provided immediate relief, I still had some ideas floating around for improving things long-term. We didn’t have the time to fully implement, test, and deploy a more permanent fix, but here’s what I’m considering:

1. Keep the database in the US region: Creating a regional replica would be cost-prohibitive.
2. Deploy the APIs to EMEA/APAC regions.
3. Introduce PgBouncer: Use PgBouncer between the API and DB, hosted in the US region (closer to the DB).
4. Persistent Connection Pooling: Configure PgBouncer with a pool of 20-30 connections to the DB and keep them persistent (min and max pool size set the same).
5. API Connection to PgBouncer: API instances will connect to PgBouncer and maintain a persistent connection.

The main idea is to establish the connection once and reuse it as much as possible. Introducing PgBouncer would help limit the number of connections the API holds, regardless of how many instances are running at any given time. This is not an ideal solution, but given the cost constraints on replicating the database, it might just be a workable solution.

Of course, this is still a theory at this stage, and I plan to run some experiments to validate it.

What is a KVM Switch?

A KVM switch is a device that allows you to control multiple computers using a single set of peripherals—specifically, a keyboard, mouse, and monitor(s). This means I can easily switch between my laptop and desktop without the hassle of constantly unplugging and replugging cables.

My KVM Setup Explained

Here’s how I’ve integrated the KVM switch into my workspace:

1. Dual Monitors for Enhanced Productivity

• I have two 24-inch monitors connected to my KVM switch. This setup provides ample screen real estate, allowing me to work on multiple applications at once, whether I’m using my laptop or desktop.

2. Connected Peripherals

• My keyboard and mouse are connected directly to the KVM switch. This means I can use them interchangeably with both computers, maintaining a clutter-free workspace.

3. USB Hub for Shared Devices

• I’ve added a USB hub connected to the KVM switch. This allows me to share additional peripherals, such as external drives or printers, between my laptop and desktop. It’s a convenient solution that saves me from having to switch cables or devices manually.

4. Streamlined Workflow

• The KVM switch acts as a central hub for all my devices, effectively simplifying my workflow. I can manage tasks across both computers without interruption, making it easy to transition from work to personal projects.

5. Effortless Switching

• The KVM switch connects both my laptop and desktop monitor outputs. With just the press of a button, I can toggle between devices. This feature is particularly useful during busy workdays, as it allows me to stay organized and efficient.

Below block diagram depicts my setup at a high-level:

Conclusion

My KVM setup has significantly improved my workspace experience. By allowing seamless switching between my laptop and desktop, along with efficient management of peripherals, I’ve streamlined my workflow and enhanced my productivity. If you’re looking to optimize your own setup, I highly recommend considering a KVM switch. It’s a small investment that can lead to big improvements in your daily work routine. Happy switching!

Dual 24-Inch Monitors

Having two 24-inch monitors side by side has transformed the way I work. The extra screen space allows me to multitask efficiently—whether I’m juggling emails, documents, or video calls, everything is now within reach. No more constantly switching between tabs! This setup has made my workflow smoother and more organized, helping me stay focused on the task at hand.

KVM Switch for Seamless Switching

To streamline my workspace even further, I added a KVM switch to easily toggle between my work laptop and personal desktop. This nifty device lets me switch control without the hassle of unplugging cables. With a simple button press, I can jump from work tasks to personal projects in seconds. It’s a fantastic way to keep everything tidy while maximizing efficiency. (Will add more details about this setup in a later blog post)

Comfort with the Steelcase Leap Chair

Last but not least, I upgraded my seating to the Steelcase Leap chair. Comfort is key when you’re spending long hours at your desk, and this chair delivers. Its ergonomic design supports good posture, and the adjustable features let me customize it to my needs. I’ve noticed a significant reduction in discomfort during long work sessions, which is a huge win for productivity.

Conclusion

These upgrades have significantly improved my workspace. The dual monitors, KVM switch, and Steelcase Leap chair not only enhance my productivity but also make my work environment more comfortable and enjoyable. If you’re considering a setup refresh, I highly recommend making similar changes!

The Context

My team develops and maintains a high-volume API serving tens of thousands of customers, generating hundreds of thousands of hits every day. Until recently, this was all hosted on-prem, but it was recently moved to the Cloud (GCP Cloud Run). While the transition itself was smooth (thanks to Docker), as bulky servers were replaced by small and rapidly scalable containers, we faced some challenges.

The Problem

In the previous setup, we had two servers load-balanced to handle the load, each capable of handling approximately 1000 requests per second. The equivalent Cloud setup consisted of small instances capable of handling 50 requests per second, dynamically scaling up to 50 instances depending on load (for cost reasons).

Previously, each instance was set up to consume a maximum of 50 connections per database, which worked well. However, when migrated to the Cloud, this fact was overlooked. Consequently, our APIs, which used to make a total of 100 connections to each DB, ended up attempting to create up to 2500 connections per database. Since this DB was shared across multiple consumers, we had a hard limit of 500 simultaneous connections allowed to that DB.

Even reducing the maximum connection pool size to 10 per instance per DB would have meant consuming all the connections the DB could support.

So, once that threshold is met:

1. This API was facing connection failures.
2. Other applications connecting to the database were refused further connections.
3. Overall database performance degraded due to the increased load on it.

While we could have simply increased the maximum connections allowed or created read replicas for the database to allow for more concurrency, these solutions would have merely thrown money at the problem without addressing the root cause.

How did we solve this?

Fortunately, this issue manifested in a PostgreSQL instance. For PostgreSQL, we have a utility called PgBouncer, which acts as a proxy for the PostgreSQL instance, effectively managing connection pooling.

We decided to introduce PgBouncer between the application (API) and Database, so the application doesn’t have to directly interface with the Database. Since PgBouncer is wire-compatible with PostgreSQL, we didn’t have to make any changes to the application code itself, except for config changes to point to PgBouncer.

PgBouncer supports three modes of operation:

1. Session pooling
2. Transaction pooling
3. Statement pooling

We opted to use “Transaction Pooling” with our application, which pools connections and assigns connections to clients on a transaction basis. Once the client completes a Transaction, the connection is returned to the pool to be reused for a different Transaction—either for the same client or a different one.

Here, you can control how many actual connections you want to establish at max with the Database. Since the connections are shared at the transaction level across all APIs, we wouldn’t need as many connections as we originally needed when each instance was connecting to the database individually. We ended up configuring PgBouncer to use a maximum of 50 connections to the database (even fewer than what we had originally consumed).

After a few regression tests and performance tests, we were satisfied with the performance but noticed that our applications’ use of prepared statements occasionally failed. This turned out to be unsupported in the version of PgBouncer we initially opted for (v. 1.16) at the Transaction level. We then had to upgrade our version to 1.21 and configure PgBouncer to support it.

Once this was set up, the API worked as expected.

While this is just scratching the surface of what is possible using PgBouncer, we are still figuring out ways to better host and share it across different applications, as well as gain visibility into which application is making the most connections, etc. Hoping to write more on this as I learn more about PgBouncer! ```

Below is a (actually, one of the) gripe I have about MS Teams and how I ended up mitigating it.

The Problem

Teams has the concept of Chats and Channel Conversations. Chats being the 1-on-1 interactions as well as Group Chats, whereas Channel Conversation refers to the Team discussions.

The primary difference between the two boils down to,

1. How you access them?

   Chats can be access from “Chat” icon, and Channels through the “Teams” icon and navigating to the Channel you are interested in.

2. How the discussions are conducted?

   Chats are basically organized in a linear timeline with ability to “Reply” to older messages.

   Channels are organized as threads.

In lots of scenarios, threaded conversation makes sense as it provides context on the discussion that is going on.

So, if it is great, where lies the problem?!

This is where those two distinctions between Chat and Channel Conversations come into play. For one, Chat live in its own screen and Channels live in their own screen. There is no ability to access one from the other. Since Channels get a second-class citizen treatment within Teams, it causes a huge adoption issue for Channels.

While I am not the first one to express this*, Microsoft doesn’t seem to be making any attempts to alleviate it.

How did I solve for this?

Well, I don’t know yet if I can confidently solved this or not, as I have just shared this with my team, and only time will tell how well received it is.

So, to put some disclaimer, this isn’t a clean solution by any means, as it is still a major inconvenience but this at least tries to keep things little bit manageable.

Approach 1

This approach uses the Browser’s ability to install a site as an App (aka PWA), where I suggested the team to install MS Teams as a PWA and leave it on the “Team” screen for quick access to Channels.

Approach 2

This approach uses Teams’ feature to pop out a Chat into its own window. If you have this capability turned ON, anytime you click on message notifications, the corresponding Chat/Channels will open in a new window.

But, unfortunately, this feature can be triggered manually from the UI only for Chats, and not for Channels. You can pop-out a specific conversation from the Channel but not the Channel itself.

Below are the steps I followed to pop-out a Channel Conversation any time I wanted to,

1. Open the Channel you are interested in, and go to the Files tab
2. Click on the ellipsis and choose Open in SharePoint
3. In the web page that opens, click on Go to Channel
4. Now, when prompted open the link using MS Teams (and optionally set is as the default behavior)
5. Create a shortcut for this URL (or) bookmark it in browser for easier access to it later on

While this is not the cleanest solution, it does seem to help a little bit. Again, this mainly works because I collaborate mainly on 2-3 Channels on a regular basis. If you do collaborate on multiple Channels, this could become cumbersome (but still better than switching back and forth between Chat and Teams screens!).

Do you face similar problems with Teams? How are you tackling it?

I have in the past tried multiple tools some which are below,

• Insomnia
• Thunder Client
• Nightingale

One common thing about it all is the user interface remains somewhat similar to one another - you have collections, requests, tabs to shuffle across APIs, variables for customizing dataflow. After trying them out, none of them gave me a feeling of wanting to switch over to them.

And, to be clear I am purely interested in capabilities that allow accessing APIs alone and I don’t heavily rely on Postman for API Testing, API Documentation (for this, I use SwaggerHub), Mocking etc.

The Problem

One of the gripe I have over Postman and others I have tried out over the years, is the need to constantly switch tabs and enter data across multiple places when I want to trigger requests to multiple endpoint under the same/similar context.

Imagine you have multiple endpoints that share different level of details about your online order, and all of them take order number as the input, with some of them taking additional input parameters on top of order number. The way most tools handle inputs is through request-specific variables (or) through collection/environment variables. While setting a collection/environment variable does achieve setting the variable once and having it cascaded across different requests it is still an hassle to switch back and forth between tabs anytime data needs to be modified.

REST Client

Recently I came across REST Client (which is actually an extension for VSCode)

Installation

Assuming you already have VSCode, to install the extension search for humao.rest-client in VSCode.

Features

REST Client offers ability to access REST APIs, gRPC and GraphQL based APIs. Below are few of the core capabilities,

• Run Http requests and visualize results in a different pane
• Save response to disk
• Access history for API Requests made & use them to initiate a Request
• Fold/Unfold API Response that is in JSON or XML format
• Environments & Variables support

Standout Capabilities

Below are few capabilities, that stood out to me,

1. Single text file that can contain all your API definition

The text file where you put in all your Requests can follow HTTP standards, with each individual Requests separated our by ### in their own line. This is a great alternative to having N number of tabs depending on the number of endpoints you are dealing with.

2. Support for file-scoped variable

This is another benfit to having all the Requests defined in a single file. Where any variables defined with a File-scope will be available for use across all the Requests. For instance, going by the example mentioned above - if you have 5 endpoints all requiring order number as input, you could define the order number variable once and refer it in all the requests; invoking the endpoints for a different order number is as simple as updating one single variable which propagates it across all the endpoints.

3. Split-pane view for api-definitions and viewing results. This allows you to work on multiple API endpoints without switching tabs/screens

Results of the current Request show in a split-editor view, so there is no toggling between windows/tabs even for accessing the response headers. Also, the status bar shows useful information like breakdown of time taken & breakdown of response size.

4. Support for accessing JSON/XML response/headers for other API requests that you have already made

This is one of the great things where, lets say you have two interlinked API endpoints, where you need to pull data points from one’s Response and feed it into the Request of another. There is no need to copy/paste those across Reqests OR setup “test scripts” to copy response values into a Environment/Collection variable for accessing it outside the Request context.

Take below example, if one of the endpoints returns all objects and in a different endpoint you want to pass in the “id” of first item returned to get more details, you can have it setup as below,

# File Variables #
@baseUrl = api.restful-api.dev

###

# List of objects by ids
// @name allObjects
GET https://{{baseUrl}}/objects
    ?id=ff8081818ad150c5018ade970fab1017
    &id=13

# Single object
GET https://{{baseUrl}}/objects
    ?id={{allObjects.response.body.$[0].id}}

Notice the usage of // @name allObjects which assigns a name to that Request, and once it is run, the response (including headers) can be accessed in a different Request within the same file. It is referenced in another Request with the syntax - {{allObjects.response.body.$[0].id}}

5. Support for prompting user input when running a Request

Rather than provide all the inputs upfront, if you want to prompt user to key-in data at the time of triggering the request, that is possible too. You do it as below,

# File Variables #
@baseUrl = api.restful-api.dev

###

# Single object
// @prompt Id Enter the ID value you want to retrieve details for:
GET https://{{baseUrl}}/objects
    ?id={{Id}}

###

What next?

With a new kind of user experience, this extension definitely does feel like a breath a fresh air, in a space crowded with multiple tools offering kind of very similar experience. Overall, this is a well rounded offering and covers majority of features anyone would expect to get out of an API client. Like I mentioned earlier, this isn’t going to become a replacement for Postman especially at Work, as it would then entail changes to workflows my teams are already adopting to.

But, I am going to start using it for non-trivial API specs I have been maintaining for my personal hobby projects.

After getting a feel of what this extension offers, I was looking to see if there are similar kind of approaches used by other such tools. And, I indeed stumbled upon one - which is probably little newer that REST Client, and thus may be not as popular as this one.

httpYac is the one I found. This though is very similar to REST Client in lots of ways, from the looks of it, it does seem way more feature-rich than REST Client. With pretty good additions like plugin system, Scripting support (Javascript) and the ability for it to be plugged into CI/CD pipelines.

Pretty eager to give this a try sometime soon!