Forem: Naman Singh

Default HTTP/3 .NET Support

Naman Singh — Tue, 28 Mar 2023 10:44:01 +0000

As the world of web development continues to evolve, the need for faster, more efficient, and secure network protocols becomes increasingly crucial. In .NET 8, developers now have access to the power of the HTTP/3 protocol by default. In this blog post, we will delve into the technical aspects of this feature, covering how it can boost your application's performance and security and go over a basic implementation.

What is HTTP/3?

HTTP/3, the third major version of the Hypertext Transfer Protocol, is the successor to HTTP/2. Built on the QUIC transport layer protocol, HTTP/3 improves upon its predecessor by offering several advantages, including:

Faster connection establishment
Better multiplexing and prioritization
Improved connection migration
Enhanced loss recovery

.NET 8 Default Support

To leverage the advantages of HTTP/3 in your applications, .NET 8 has incorporated it as a default feature, streamlining the development process. The following sections will detail how to enable and utilize HTTP/3 support in your .NET 8 projects.

To enable it for your applications, set the SocketsHttpHandler.Http3Enabled property to true



var handler = new SocketsHttpHandler { Http3Enabled = true };
var httpClient = new HttpClient(handler);

To enable HTTP/3 support on the server-side using Kestrel, you need to configure the server to listen for QUIC connections. This is achieved by specifying the HttpProtocols.Http3 protocol and providing a valid TLS certificate:



var host = new HostBuilder()
    .ConfigureWebHost(webHost =>
    {
        webHost.UseKestrel(options =>
        {
            options.ListenAnyIP(5001, listenOptions =>
            {
                listenOptions.Protocols = HttpProtocols.Http3;
                listenOptions.UseHttps("testCert.pfx", "testPassword");
            });
        });
    })
    .Build();

host.Run();

To enable for gRPC:

Since gRPC relies on HTTP/2 for communication, enabling HTTP/3 support for gRPC in .NET 8 requires a few adjustments. To use gRPC with HTTP/3, you need to configure the client and server to use HttpClient and Kestrel, respectively:

Client-side:



var channel = GrpcChannel.ForAddress("https://localhost:5001", new GrpcChannelOptions
{
    HttpHandler = new SocketsHttpHandler
    {
        Http3Enabled = true
    }
});

Server-side:



var host = new HostBuilder()
    .ConfigureWebHost(webHost =>
    {
        webHost.UseKestrel(options =>
        {
            options.ListenAnyIP(5001, listenOptions =>
            {
                listenOptions.Protocols = HttpProtocols.Http3;
                listenOptions.UseHttps("certificate.pfx", "testPassword");
            });
        });
    })
    .ConfigureServices(services =>
    {
        services.AddGrpc();
    })

.Configure(app =>
{
    app.UseRouting();
    app.UseEndpoints(endpoints =>
    {
        endpoints.MapGrpcService<MyGrpcService>();
    });
})
.Build();
host.Run();

In the next series of this I will post on how to achieve testing and debugging against the HTTP/3 protocol.

Keep coding!

References:
https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-8
https://blog.cloudflare.com/content/images/2018/07/http-request-over-quic@2x.png
https://images.ctfassets.net/ee3ypdtck0rk/5oX21p5upAslPIzwJlVPCw/d50a0811796d5c9307ad84ddd0332c90/Screen_Shot_2021-01-28_at_6.46.26.png?w=1323&h=661&q=50&fm=png

gRPC and brotli compression: A powerful combination for efficient data transfer

Naman Singh — Thu, 12 Jan 2023 08:47:04 +0000

gRPC is a high-performance, open-source framework for building remote procedure call (RPC) APIs. It is based on the Protocol Buffers data serialization format, which is efficient and highly extensible. gRPC allows for the creation of lightweight, high-performance APIs that can be easily implemented in a variety of programming languages.

One feature that sets gRPC apart from other RPC frameworks is its support for brotli compression. Brotli is a lossless compression algorithm that is specifically designed for compressing web content, such as HTML, CSS, and JavaScript. It is able to achieve higher compression ratios than other algorithms, such as gzip, while still maintaining a fast decompression speed. This makes it an ideal choice for use in gRPC, as it allows for the efficient transfer of data over the network.

When compared to other compression algorithms, brotli has several advantages. For example, it typically achieves a higher compression ratio than gzip, which is the most widely used compression algorithm on the web. This means that brotli-compressed data will take up less space, which can be especially beneficial for mobile devices or other low-bandwidth environments. Additionally, brotli's fast decompression speed makes it well-suited for use in real-time applications, such as streaming video or gaming.

Another advantage of brotli is its support for dynamic dictionaries. This feature allows the algorithm to learn and adapt to the specific characteristics of the data being compressed, which can result in even higher compression ratios. This is particularly useful for gRPC, as it allows for the efficient transfer of large amounts of data, such as images or videos.

If you're looking to build high-performance, efficient APIs, gRPC and brotli compression are definitely worth considering. With their combination of fast performance, high compression ratios, and support for dynamic dictionaries, they offer a powerful solution for transferring data over the network.

Monolithic and Distributed Monolith Applications: Understanding the Pros and Cons

Naman Singh — Mon, 02 Jan 2023 11:50:34 +0000

In the world of software development, there are many approaches to designing and building applications. One commonly used approach is the monolithic architecture, in which the application is built as a single, self-contained unit. While monolithic architectures have some advantages, such as ease of development and testing, they can become difficult to maintain and scale as the application grows in size and complexity.

To address these issues, some organizations have turned to distributed monolith architectures, which involve decomposing the monolithic application into smaller, independent components that can be developed and deployed separately. There are two main approaches to implementing a distributed monolith: microservices and modular monoliths.

Microservices involve dividing the application into self-contained services that communicate with each other through well-defined interfaces. This approach offers more flexibility and scalability than a monolithic architecture, as individual components can be developed, deployed, and scaled independently. However, microservices can be more complex to develop and maintain due to the need to coordinate and manage the interactions between the various components.

Modular monoliths involve dividing the application into logical modules that can be developed and deployed independently, but are more closely integrated than microservices. This approach offers a balance between simplicity and flexibility, but may be less scalable than microservices.

Both microservices and modular monoliths have their own set of trade-offs and challenges, and the best approach will depend on the specific needs and constraints of the application and organization.

In addition to these architectural approaches, there are also software development practices such as continuous integration (CI) and continuous delivery (CD) that can be used to streamline the development and deployment process for, both, monoliths and microservices. CI involves regularly integrating code changes and automatically building and testing the code, while CD automates the process of delivering code changes to production/staging/development environments. These practices can help organizations to deploy updates and new features faster and more reliably, and can be particularly beneficial for distributed monoliths and microservices.

Microservice Based Architecture

Naman Singh — Mon, 02 Jan 2023 11:19:36 +0000

Microservice-based architecture is a design approach in which a large software application is built as a suite of small, independent services that communicate with each other using well-defined interfaces. This approach has gained popularity in recent years due to its ability to improve the scalability and maintainability of complex software systems.

One of the key benefits of microservices is that they allow teams to work independently and in parallel on different parts of the system. This can lead to faster development cycles and a more flexible codebase. However, building a successful microservice-based system requires careful planning and the use of design patterns and clean architectural standards.

One of the key design patterns used in microservice-based architecture is the API Gateway pattern. This pattern involves the creation of a central gateway that sits in front of the individual microservices and exposes a single, unified API to the outside world. The API Gateway is responsible for routing requests to the appropriate microservice, handling authentication and authorization, and providing other security and monitoring features.

Another important design pattern is the Circuit Breaker pattern, which is used to prevent cascading failures in a microservice-based system. This pattern involves the creation of a circuit breaker that sits between the client and the microservice. If the microservice fails to respond within a certain time period, the circuit breaker will automatically open and prevent further requests from being sent to the service. This can help to prevent a single point of failure from taking down the entire system.

In order to ensure that a microservice-based system is maintainable and scalable, it is important to follow clean architectural standards. One such standard is the Single Responsibility Principle, which states that every module or class in a system should have a single, well-defined responsibility. This helps to keep the codebase modular and easy to understand, as each service has a clear purpose and is not cluttered with unnecessary functionality.

Another important architectural standard is the Dependency Inversion Principle, which states that high-level modules should not depend on low-level modules, but rather both should depend on abstractions. This helps to reduce the coupling between different parts of the system and makes it easier to change or replace individual microservices without affecting the rest of the system.

In summary, microservice-based architecture is a powerful design approach that can improve the scalability and maintainability of complex software systems. By using design patterns such as the API Gateway and Circuit Breaker patterns and following clean architectural standards, it is possible to build a robust and reliable system that is easy to maintain and evolve over time.

TCPs challenger: Homa

Naman Singh — Sun, 11 Dec 2022 14:44:13 +0000

What is it?

Homa is a high-speed transport protocol that was designed to challenge TCP (Transmission Control Protocol), which is the most widely used network transport protocol on the internet. Homa is optimized for datacenter environments, where it can provide significantly lower latencies and higher throughput compared to TCP.

Is this experimental at this point in time?

Yes - Homa can be considered an experimental protocol at this point. It was developed by researchers at Stanford University and Google, and while it has shown promising results in some initial studies, it has not yet been widely adopted or extensively tested in real-world environments. As a result, it is still considered to be a work in progress, and its practical applications and limitations are not yet fully understood.

So then, who cares?

As a Backend DevOps/Engineer, Homa could potentially affect your work in a few ways. First, if you are working on a system that involves high-speed data transfer within a datacenter, then using Homa instead of TCP could potentially improve the performance of your system. Additionally, if you are involved in the design or implementation of network protocols, then Homa could serve as an interesting point of comparison or inspiration for your work. However, it's important to note that Homa is still a relatively new and experimental protocol, so its practical applications and limitations are not yet fully understood.

gRPC Performance Benefits

Naman Singh — Sun, 11 Dec 2022 14:24:11 +0000

I am currently learning gRPC and gRPC-Web in the .NET space. I will be posting some theoretical nuggets of info as I go along - hope this is helpful to some :)

What is it

gRPC is a modern open-source framework for microservice-to-microservice communication. It uses the HTTP/2 protocol for efficient transmission of data and uses Protocol Buffers for serializing structured data.

Tell me something I didn't already know

One of the main advantages of gRPC is its use of HTTP/2, which allows for efficient transmission of data with support for full-duplex streams, header compression, and multiplexing requests over a single TCP connection. This makes gRPC an ideal choice for high-performant microservice architectures.

How does this affect what I am already "used to doing"

In comparison to SOAP and REST, which use XML and JSON respectively, gRPC offers a more efficient and compact binary representation of data. This can result in significant performance improvements, particularly in high-traffic environments.

Er, but from a consumer (client) perspective - browsers do not support the HTTP/2 protocol...?

gRPC can be used in the browser by using a gRPC-Web client library, which provides a JavaScript library that can be used in a web application to interact with a gRPC service. This library acts as a proxy, translating between the gRPC-Web protocol and regular gRPC messages. This allows gRPC to be used in the browser, even if the browser does not natively support HTTP/2.

Bonus

Another advantage of gRPC is its support for bidirectional streaming, which allows for real-time communication between microservices. This makes it a good fit for event-driven architectures and message brokers.