In modern software development, deciding between a REST, gRPC or any other API approach dictates how easily your systems will scale, integrate, and deliver value. Your API design choices are no longer just internal implementation details, they shape your entire development lifecycle.

In the world of RESTful APIs, we have long lived by a strict set of (self-imposed) rules. Whether you are fetching data with GET, creating an entity with POST, or updating a resource with PUT, the HTTP method tells the server what your intention is.

Quite recently, RFC 10008 got published, which defines the new QUERY method for HTTP. Why is this needed when we already have other HTTP methods? Let's find out.

Kreya 1.20 is here with a new authentication configuration called Login operation, a reworked response view, support for macOS HTTP/3 and TLS 1.3, and Linux support for AppImage and Flatpak. A major focus of this release was improving performance and transitioning to Avalonia UI.

In modern development workflows, API clients are indispensable tools. API clients let developers inspect, debug, and test endpoints efficiently. Popular options like Postman or Insomnia have become the default for many teams, especially when collaboration is key. However, these tools often come with an overlooked trade-off: a hidden cost of relying on cloud-first architectures.

In this post, we will show you how to test your REST API using Kreya. This involves starting with simple status code assertions, progressing to advanced response assertions, and concluding with snapshot testing. Ultimately, we will demonstrate how to automate your tests in your CI/CD pipeline.

In this post, we'll show you how to use Kreya to automate the Google Cloud authentication flow, allowing you to call Google Cloud Platform services effortlessly.

With the release of Kreya v1.19.0 support for GraphQL was added. This guide will walk you through setting up your first GraphQL operation, from schema import to automated testing.

In my previous post we explored the full gRPC protocol stack, from the .proto contract down to the HTTP/2 frame on the wire. We ended with a cliffhanger: browsers cannot speak native gRPC. I promised to cover that gap. This is that post.

We will look at why browsers are fundamentally incompatible with the gRPC HTTP/2 protocol and how gRPC-Web works around those limitations at the byte level. Along the way, we will dig into the Fetch API's streaming internals and close with what is (hopefully) coming in the near future.

The API development lifecycle has changed. In 2026, the choice of API testing tools is no longer just about sending requests. It's about data ownership, seamless team collaboration, ensuring reliable deployments and deep protocol support.

For years, Postman has been the industry standard, but its shift toward a "cloud-mandatory" ecosystem has caused discontent for developers who value privacy and local workflows.

On the other side of the spectrum sits Kreya, a "privacy-first" desktop client designed to run where your code lives: in your file system and your version control.

Displaying a large amount of messages in a list can destroy the performance of an application. The naive approach to displaying these messages would be to render each message as a DOM element (in a webpage context). But this quickly degrades the performance, since the browser needs to spend all its time laying out these elements, repainting them during scrolling and holding the huge list of DOM nodes in memory.

Chat apps, log message visualizers and various other applications all face this problem. Today, we are going to take a look how we solved this in Kreya.