DEV Community: abibeh

Introduction to Gonyx

abibeh — Fri, 19 Sep 2025 10:07:00 +0000

Welcome to the Gonyx Framework documentation. Gonyx is a fast API development framework for Golang that makes it easy to build high-performance, scalable web applications.

What is Gonyx?

Gonyx is a modern Go framework designed to simplify the development of robust web applications and APIs. It provides a clean, structured approach to building backend services with Go.

For more information, please refer to Gonyx.io.

Key Features

Simple REST API Creation: Build RESTful APIs with minimal boilerplate code
High Performance: Optimized for speed and efficiency
Built-in Middleware: Common functionality like logging, error handling, and more
Clean Architecture: Promotes separation of concerns and maintainable code
gRPC Support: First-class support for gRPC services alongside REST

Getting Started

The quickest way to get started with Gonyx is to follow our Quick Start guide, which will walk you through creating your first Gonyx application.

If you want to dive deeper into specific features, check out our tutorials:

Simple Bookstore CRUD Tutorial: Learn how to implement a simple bookstore management API

Installation

To install Gonyx, download the appropriate package for your platform from our GitHub releases:

Download from GitHub Releases

Choose the package that matches your operating system and architecture:

Windows: gonyx-windows-amd64.exe
macOS: gonyx-darwin-amd64 or gonyx-darwin-arm64
Linux: gonyx-linux-amd64 or gonyx-linux-386

After downloading, make the binary executable and add it to your PATH.

Verify your installation:

gonyx version

This guide will help you create a Gonyx project from scratch and run it successfully.

Prerequisites

Before you begin, make sure you have the following installed:

Go version 1.23 or higher
Git for version control

Creating a New Gonyx Project

Creating a new Gonyx project is simple with the gonyx command-line tool. The basic syntax is:

gonyx init [application-name]

This will create a new application folder in your current directory. The application folder will be named according to what you specify as [application-name].

If you want to create the application in a specific parent directory, you can use the --path flag (or -p for short):

gonyx init my-gonyx-app --path /path/to/parent/folder

Project Structure

After running the gonyx init command, your project structure will look like this:

my-gonyx-app/               # Root of your project
├── .git/                   # Git repository
├── .gitignore              # Git ignore file
├── app/                    # Application core
│   ├── app.go              # Main application logic
│   ├── controller.go       # Controller definitions
│   ├── model.go            # Data models
│   └── proto/              # Protobuf definitions (if applicable)
├── commands/               # CLI commands
│   └── root.go             # Root command definition
├── configs/                # Configuration files
│   ├── base_sample.json    # Base configuration template
│   ├── http_sample.json    # HTTP server configuration template
│   ├── logger_sample.json  # Logger configuration template
│   ├── protobuf_sample.json # Protobuf configuration template
│   └── dev/                # Development environment configs
├── go.mod                  # Go module definition
├── go.sum                  # Go module checksums
└── main.go                 # Application entry point

The gonyx init command automatically sets up this structure for you, saving you the effort of creating these directories and files manually.

Understanding Your New Project

After creating your project with gonyx init, you'll have a complete, ready-to-use application structure. Here's what you need to know to get started:

Controllers

The app/controller.go file contains the definitions for your API endpoints. Controllers in Gonyx handle HTTP requests and produce responses. Here's an example of a controller from the generated code:

// SampleController - a sample controller to show the functionality
type SampleController struct{}

// GetName - return the name of the controller to be used as part of the route
func (ctrl *SampleController) GetName() string { return "Sample" }

// Routes - returning controller specific routes to be registered
func (ctrl *SampleController) Routes() []http.HttpRoute {
    return []http.HttpRoute{
        http.HttpRoute{
            Method:    http.MethodGet,
            Path:      "/hello",
            RouteName: "hello",
            F:         ctrl.GetHello,
        },
    }
}

// GetHello - just return the 'Hello World' string to user
func (ctrl *SampleController) GetHello(c *gin.Context) {
    c.String(200, "Hello World")
}

Controllers typically:

Define route handlers for different HTTP methods (GET, POST, PUT, DELETE)
Process incoming requests and validate data
Interact with models or services for business logic
Return appropriate responses to clients

In this example, the controller:

Defines a structure called SampleController
Implements the GetName() method to define the controller's name
Implements the Routes() method to register a GET route at "/hello"
Implements the handler function GetHello() that returns a simple "Hello World" response

Running Your Application

To run your application, use the gonyx runserver command:

cd my-gonyx-app      # Navigate to your project directory
go run ./main.go runserver      # Run both HTTP and gRPC servers

This command starts two servers:

An HTTP RESTful API server (default port: 3000)
A gRPC server (default port: 7777)

The servers use the configuration files in the configs/dev directory by default. You can create different configuration environments by adding new folders (e.g., configs/prod for production) and specifying the environment when running the server.

To access your API:

REST API: http://localhost:3000
gRPC: localhost:7777

Configuration Modes

Gonyx supports different configuration modes for various environments:

dev: Development mode (default)
prod: Production mode (create this folder and configuration files as needed)
Custom modes: You can create any named folder under configs/ for custom environments

The configuration files define settings like port numbers, database connections, logging options, and more.

Next Steps

Congratulations! You've created your first Gonyx application. Here are some suggestions for next steps:

Explore more advanced Gonyx features like middleware, validation, and database integration
Implement structured routing with controllers
Add authentication to your API
Create a more complex data model
Connect to a database

For more detailed tutorials and examples, check out the other documentation.

[Boost]

abibeh — Tue, 16 Sep 2025 10:33:22 +0000

abibeh

Sep 10 '25

Getting Started with HTTP/3 in Python

#http3 #python #programming

Comments

12 min read

[Boost]

abibeh — Mon, 15 Sep 2025 06:54:16 +0000

abibeh

Sep 12 '25

Getting Started with HTTP/3 in Golang: A Practical Guide

#go #http3 #programming

Comments

7 min read

Rust + Flutter: How to Build Fast, Safe, Cross-Platform Mobile Apps

abibeh — Sun, 14 Sep 2025 17:42:13 +0000

Benefits of Using Rust in Flutter Apps

When integrating Rust into Flutter, the main idea is to let Flutter handle the UI/UX while Rust powers the core logic. This combination provides several benefits:

🚀 High Performance

Rust compiles directly to native machine code, making it ideal for performance-critical tasks such as cryptography, media processing, networking, or financial calculations.

📱 Cross-Platform Core Logic

With Rust, you write your business logic once and use it across both Android and iOS. This avoids duplicating complex code in Kotlin and Swift, and ensures consistent behavior across platforms.

🛡️ Memory Safety

Rust’s strong type system and ownership model catch many bugs at compile time, reducing crashes and improving app reliability. This makes Rust a safe choice for handling sensitive logic like authentication or encryption.

⚡ Concurrency and Async

Rust provides powerful tools for multithreading and asynchronous programming, which allows you to run heavy background tasks without blocking Flutter’s UI. This is essential for apps with real-time data, chat, or streaming features.

📦 Rich Ecosystem

The Rust ecosystem offers a wide range of crates (libraries) for cryptography, networking, databases, serialization, and even machine learning. By reusing these crates, you can quickly add advanced capabilities to your app.

🔧 Maintainability

By keeping your core logic in one shared Rust library, you reduce code duplication and simplify long-term maintenance. Updates are easier to roll out since both iOS and Android share the same core implementation.

✅ In summary: Flutter + Rust lets you build apps where Flutter delivers the smooth user interface, and Rust delivers the speed, safety, and cross-platform consistency for the underlying logic. This architecture scales well from small prototypes to large production apps.

Real-World Applications Using Embedded Native Code

Many production applications embed native code (C++, Rust, or other compiled languages) inside their mobile apps to handle performance-critical, cross-platform logic. This is exactly the approach we are exploring with Rust + Flutter. Here are some notable examples:

🔹 Telegram

What they do: Telegram uses a C++ core for their messaging engine, encryption, and network protocol handling.
Why they do it: By embedding C++ inside Android and iOS apps, Telegram ensures high performance, reliability, and consistent behavior across platforms.
Takeaway: This shows that even large-scale apps rely on a compiled, cross-platform core for heavy business logic while keeping the mobile UI in native frameworks (or Flutter-like layers).

🔹 Signal

What they do: Signal embeds native libraries (C/C++) for encryption and secure messaging.
Why they do it: Critical cryptographic operations need to be fast and memory-safe, which is difficult to achieve with pure Java/Kotlin or Swift alone.

🔹 Discord

What they do: Discord uses C++ for parts of their audio/video pipeline in mobile apps.
Why they do it: Real-time media processing requires low latency and high efficiency, which is best handled in a compiled language.

🔹 Brave Browser (Mobile)

What they do: Brave embeds a native Chromium engine (C++) in mobile apps.
Why they do it: To ensure consistent rendering, speed, and security, the same native engine runs across iOS and Android.

Summary: Embedding compiled, cross-platform code inside mobile apps is a proven production approach. Companies like Telegram, Signal, Discord, and Brave rely on it to deliver performance-critical features while keeping mobile UIs responsive. Using Rust in Flutter is a modern, safe alternative to this same strategy, giving developers high performance, memory safety, and cross-platform code reuse.

TL;DR

We'll build a small Rust library that exposes a C ABI (extern "C") and load it from Flutter using dart:ffi.
For Android: build .so for each ABI, place them under android/app/src/main/jniLibs/<ABI>/libmylib.so and Flutter will pick them up.
For iOS: produce an XCFramework (or link a static .a) and add it to the Xcode Runner app; then use DynamicLibrary.process() or open the framework.
Tools that make life much easier (optional but recommended): cargo-ndk (Android), cargo-lipo (iOS), and cbindgen (generate headers).

This doc contains reproducible commands, Rust and Dart snippets, integration steps and a short debugging checklist.

Assumptions / prerequisites

Make sure you have the following installed and configured on your machine:

Flutter and a working Flutter project. (flutter --version)
Rust toolchain (rustup + cargo). (rustc --version, cargo --version)
Android SDK + Android NDK (for Android builds). You can install via Android Studio or sdkmanager.
Xcode (for iOS builds) and CocoaPods (for Flutter iOS plugins).
Optional helpers (recommended):
- cargo-ndk (cargo install cargo-ndk) – cross-compile for Android easily.
- cargo-xcode (cargo install cargo-xcode) – build iOS universal/static libs. For iOS, prefer cargo-xcode over cargo-lipo
- cbindgen (cargo install cbindgen) – generate C headers from Rust code.

Tip: Keep rustup updated and add targets for the platforms you will build for.

High-level approaches — pick one

Manual dart:ffi approach (this tutorial focuses on this) — you write extern "C" APIs in Rust, build platform libraries, and call them from Dart via dart:ffi. This is generic and minimal-dependency; great for an educational article.
Use a codegen bridge such as flutter_rust_bridge or uniffi — they generate ergonomic bindings and often handle async/callbacks/serialization for you. Recommended for production complexity, but they require extra setup and will need codegen steps in your workflow. (I can prepare a separate tutorial for flutter_rust_bridge if you want.)

Approach 1 — Manual Integration (Full Control)

This approach gives you maximum flexibility. You manually create a Rust crate inside your Flutter project, configure Cargo.toml, build libraries for Android with cargo-ndk and for iOS with cargo-xcode or xcodebuild, and generate bindings with flutter_rust_bridge_codegen. You then load the generated bindings in Dart using DynamicLibrary.

This method is ideal if you want to deeply understand the build process, fine-tune platform integration, or add Rust into an existing Flutter app without scaffolding a new one.

Project layout suggested

my_flutter_app/
├─ android/
├─ ios/
├─ lib/
├─ rust_native/        # new Rust crate lives here
│  ├─ Cargo.toml
│  └─ src/lib.rs
└─ README.md

Put all Rust code in rust_native/ so builds are contained.

1. Create the Rust library crate

From your project root:

cd my_flutter_app
cargo new --lib rust_native
cd rust_native

Edit Cargo.toml to export C-compatible library artifacts:

[package]
name = "mylib"
version = "0.1.0"
edition = "2021"

[lib]
name = "mylib"
crate-type = ["cdylib", "staticlib"]

[dependencies]
# add dependencies here if needed

crate-type = ["cdylib", "staticlib"] tells Cargo to build both shared libraries and static libs depending on the target.

Create src/lib.rs with a tiny example API that uses a C ABI:

// src/lib.rs
#[no_mangle]
pub extern "C" fn rust_add(a: i32, b: i32) -> i32 {
    a + b
}

// Example returning a string (caller must free the returned pointer):
use std::ffi::CString;
use std::os::raw::c_char;

#[no_mangle]
pub extern "C" fn rust_hello() -> *mut c_char {
    let s = CString::new("Hello from Rust!\n").unwrap();
    s.into_raw() // ownership transferred to caller
}

#[no_mangle]
pub extern "C" fn rust_string_free(s: *mut c_char) {
    if s.is_null() { return; }
    unsafe { CString::from_raw(s); } // drops and frees memory
}

Notes:

#[no_mangle] keeps the symbol name stable.
extern "C" ensures C ABI compatibility (necessary for dart:ffi).
For strings we hand out an allocated char* and also export a free function so the Dart side can release memory.

2. (Optional) Generate a C header with `cbindgen`

cbindgen can generate a .h header from your Rust signatures. This is useful for iOS Xcode integration or for human documentation.

Install and run:

cargo install cbindgen
cbindgen --lang c --output include/mylib.h

This will produce include/mylib.h you can add to Xcode or include with -I flags.

3. Install Android NDK

In Android Studio:

Open Tools → SDK Manager → SDK Tools
Install NDK (Side by side) and CMake

Then set environment variables:

# Linux/macOS
export ANDROID_NDK_HOME=$HOME/Android/Sdk/ndk/<version>
export PATH=$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/linux-x86_64/bin:$PATH

# Windows (PowerShell)
setx ANDROID_NDK_HOME "C:\Users\<you>\AppData\Local\Android\Sdk\ndk\<version>"

Verify:

echo $ANDROID_NDK_HOME
ls $ANDROID_NDK_HOME

4. Build for Android (recommended: use `cargo-ndk`)

Install cargo-ndk if you like:

cargo install cargo-ndk

Then from the rust_native directory, run:

# target ABIs you want: armeabi-v7a, arm64-v8a, x86, x86_64
cargo ndk -t armeabi-v7a -t arm64-v8a -t x86 -t x86_64 --build-type release build --release --lib

If successful, you'll find .so files under target/<target>/release/ (or under a cargo-ndk output folder). The shared library name will be libmylib.so.

Copy `.so` to your Flutter Android project

Create (if missing) the jniLibs directory and ABI subfolders in your Flutter Android module:

android/app/src/main/jniLibs/arm64-v8a/
android/app/src/main/jniLibs/armeabi-v7a/
android/app/src/main/jniLibs/x86/
android/app/src/main/jniLibs/x86_64/

Copy each built .so to the corresponding folder and rename them libmylib.so (they likely already are named this way):

cp path/to/target/aarch64-linux-android/release/libmylib.so ../android/app/src/main/jniLibs/arm64-v8a/
# repeat for other ABIs...

Gradle will automatically package those .so files into the APK/AAB.

If you do not want to commit binary artifacts into git, you can script the build/copy step in a shell script (good idea for CI).

5. Build for iOS (create an XCFramework or link static lib)

Option A — recommended: produce an XCFramework using `cargo xcode` and `xcodebuild`

From rust_native run:

# cargo xcode builds universal static libs for iOS targets
cargo xcode --release

Now create an XCFramework (so it works for device + simulator):

# create headers directory (use the cbindgen-generated header or write a small header)
mkdir -p include
cbindgen --output include/mylib.h

# create the xcframework bundling device + simulator libs (if you have separate .a files for each, pass them)
xcodebuild -create-xcframework \
  -library target/aarch64-apple-ios/release/libmylib.a -headers include \
  -library target/x86_64-apple-ios/release/libmylib.a -headers include \
  -output MyRustLib.xcframework

On modern Apple Silicon macs you may need to build for aarch64-apple-ios-sim as well. If cargo-lipo does not produce all the slices you need, build the targets individually (--target) and pass both .a files to xcodebuild.

Option B — simpler (static `.a`) and link it in Xcode

If you prefer a static lib only for device (or for a single arch), you can build directly:

rustup target add aarch64-apple-ios x86_64-apple-ios
cargo build --target aarch64-apple-ios --release
cargo build --target x86_64-apple-ios --release

Then add the two libmylib.a to xcodebuild -create-xcframework ... as above.

Add the XCFramework to your Runner

Open ios/Runner.xcworkspace in Xcode.
Drag MyRustLib.xcframework into the Runner project (select the Runner target and Copy items if needed).
In the target Build Phases → Link Binary With Libraries, ensure the XCFramework is linked.
If you used a C header, set Header Search Paths (or add the header to the project) so the project knows about the header for compile-time only.

When there is a static library linked into the app binary, from Dart you can access the symbols using DynamicLibrary.process(); if you embed a dynamic framework you can DynamicLibrary.open("MyRustLib.framework/MyRustLib").

6. Dart side — calling Rust with `dart:ffi`

Add a small Dart wrapper around dart:ffi.

lib/rust_bindings.dart:

import 'dart:ffi' as ffi;
import 'dart:io' show Platform;

// Native typedefs
typedef rust_hello_native = ffi.Pointer<Utf8> Function();
typedef rust_string_free_native = ffi.Void Function(ffi.Pointer<Utf8>);
typedef rust_add_native = ffi.Int32 Function(ffi.Int32, ffi.Int32);

// Dart typedefs
typedef RustHello = ffi.Pointer<Utf8> Function();
typedef RustStringFree = void Function(ffi.Pointer<Utf8>);
typedef RustAdd = int Function(int, int);

// Binding class
class RustBindings {
  late ffi.DynamicLibrary _dylib;
  late RustAdd rustAdd;
  late RustHello hello;
  late RustStringFree free;

  RustBindings() {
    if (Platform.isAndroid) {
      _dylib = ffi.DynamicLibrary.open('libmylib.so');
    } else if (Platform.isIOS) {
      // If library is linked statically into the app:
      _dylib = ffi.DynamicLibrary.process();
      // If you embedded a dynamic framework, use:
      // _dylib = ffi.DynamicLibrary.open('MyRustLib.framework/MyRustLib');
    } else {
      _dylib = ffi.DynamicLibrary.open('libmylib.dylib'); // macOS
    }

    rustAdd = _dylib
        .lookup<ffi.NativeFunction<rust_add_native>>('rust_add')
        .asFunction();
    hello = _dylib
        .lookupFunction<rust_hello_native, RustHello>('rust_hello');
    free = _dylib
        .lookupFunction<rust_string_free_native, RustStringFree>('rust_string_free');

  }
}

7. Use in Flutter App

import 'package:flutter/material.dart';
import 'rust_bindings.dart';

void main() {
  final rust = RustBindings();
  runApp(MyApp(rust: rust));
}

class MyApp extends StatelessWidget {
  final RustBindings rust;
  const MyApp({Key? key, required this.rust}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    int result = rust.rustAdd(2, 3);
    print('2 + 3 = $result');

    final rustMessage = rust.hello();
    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(title: Text("Rust + Flutter FFI")),
        body: Center(
          child: Text(rustMessage, style: TextStyle(fontSize: 24)),
        ),
      ),
    );
  }
}

Important: Always provide a free function on the Rust side if Rust allocated the memory (to avoid mismatched allocators).

8. Flutter build & run

Android

flutter run or flutter build apk should package the .so files from android/app/src/main/jniLibs/* automatically.
If your binary isn't found at runtime check adb logcat for UnsatisfiedLinkError and double-check the path & ABI.

iOS

flutter build ios then open ios/Runner.xcworkspace and run from Xcode (select a device or simulator). Pod install will run when needed.
If the app crashes or the symbol isn't found, check Xcode's Linker errors and ensure the XCFramework or .a is added & linked.

9. Common pitfalls & troubleshooting

Symbol not found at runtime: name mismatch (#[no_mangle]) or wrong function signature. Use nm (mac/linux) or readelf -s to inspect exported symbols.
Architecture mismatch: Ensure you built the library for the ABI the device expects. Use file or lipo -info on built binaries.
iOS simulator on Apple Silicon: you may need to produce aarch64 slices for the simulator. cargo-lipo + building aarch64-apple-ios-sim can help.
Dart FFI type mismatch: Ensure C types map to the correct Dart FFI types (e.g., int32 ↔ Int32).
Memory ownership: If Rust returns allocated memory, ensure you expose a free function and always call it from Dart.

10. Advanced: async, callbacks and threading

Dart dart:ffi cannot call back into Dart from arbitrary native threads. If you need callbacks, either:
- Use platform channels to send messages (bridged by the Flutter engine), or
- Use NativePort/Dart_PostCObject from the native side (advanced), or
- Use flutter_rust_bridge or uniffi which provide patterns for callbacks and async.
For long-running tasks, run native work on native threads and expose a future-like API to Dart (e.g. start job → poll result or use a callback mechanism).

This guide shows the simplest way to use Rust inside a Flutter app using the official flutter_rust_bridge tooling. It uses the new generate + integrate commands (replacing the old --watch flag).

Conclusion:

The manual integration approach is best suited for developers who need fine-grained control over build artifacts, or those integrating Rust into an existing Flutter project. While it requires more setup (NDK paths, Rust targets, iOS frameworks), it ensures you fully understand how Flutter and Rust communicate, making debugging and customization easier in the long run.

Approach 2 — Quickstart with FRB create Command (Easiest)

This approach uses the FRB-provided scaffold tool to generate a new project where Flutter and Rust are already wired together.

1. Install prerequisites

Make sure you have installed:

Flutter SDK
Rust (rustup, cargo)
Android Studio (for Android builds) / Xcode (for iOS builds)

Then install the FRB codegen tool (only once):

cargo install flutter_rust_bridge_codegen

2. Create a new Flutter + Rust project

Run the FRB helper to scaffold a full project:

flutter_rust_bridge_codegen create my_app

This generates a project with both Flutter and Rust already wired together:

my_app/
├─ lib/   # Flutter project
├─ rust/      # Rust crate
└─ rust_builder/    # Glue + generated bindings

3. Run the project

Move into the Flutter directory and run it like any Flutter app:

cd my_app/flutter
flutter run

You should see the sample Flutter UI calling a Rust function.

4. Modify Rust code

Open my_app/rust/src/api.rs and edit or add Rust functions. For example:

pub fn rust_add(a: i32, b: i32) -> i32 {
    a + b
}

5. Regenerate bindings (new workflow)

Whenever you change your Rust API, run:

flutter_rust_bridge_codegen generate
flutter_rust_bridge_codegen integrate

generate → scans api.rs and produces new Dart + Rust glue code
integrate → updates the Flutter project with the generated bindings

Then re-run Flutter:

flutter run

6. Dart side usage

FRB generates <project_name>_generated.dart with ready-to-use bindings. Example usage in your Flutter code:

import 'src/rust/<project_name>_generated.dart';
import 'src/rust/api/simple.dart';

Future<void> main() async {
  await RustLib.init();
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(title: const Text('flutter_rust_bridge quickstart')),
        body: Center(
          // `greet` is a function inside `simple.dart`' -> open rust folder and find the `simple.rs` to modify it
          child: Text(
              'Action: Call Rust `greet("Tom")`\nResult: `${greet(name: "Tom")}`'),
        ),
      ),
    );
  }
}

Conclusion:

The quickstart approach is perfect for new projects or rapid prototyping. It avoids manual setup and provides a working scaffold out of the box. You simply add Rust code, regenerate bindings, and run Flutter. This makes it the best choice for quickly validating ideas, creating demos, or writing tutorials without worrying about low-level build details.

Getting Started with HTTP/3 in Golang: A Practical Guide

abibeh — Fri, 12 Sep 2025 16:37:55 +0000

Introduction

HTTP/3 is the latest major revision of the Hypertext Transfer Protocol, built on top of QUIC (a UDP-based transport protocol) and designed to make web communication faster, more secure, and more resilient to network changes. It eliminates the TCP bottlenecks of previous versions, supports multiplexed streams without head-of-line blocking, and integrates TLS 1.3 by default.

This article series focuses on implementing HTTP/3 using the Golang programming language. Instead of diving into a long theoretical explanation here, I’ll refer you to some excellent resources that explain the protocol’s background, benefits, and evolution:

Speeding Through the Web: Understanding HTTP 1.1, HTTP/2, and HTTP/3 — A clear comparison of all three major HTTP versions.
Web Is Becoming HTTP/3, and Here’s What You Should Know About — A concise, beginner-friendly introduction to HTTP/3.
HTTP/3: Your Guide to the Next Internet — A more technical explanation of why HTTP/3 exists and how QUIC changes the game.

📜 Official Specifications & Technical References

RFC 9114: HTTP/3 — The official IETF specification for HTTP/3.
RFC 9000: QUIC Transport Protocol — The base transport protocol for HTTP/3.
RFC 9001: Using TLS to Secure QUIC — How TLS 1.3 is integrated into QUIC.
W3C HTTP Working Group — Maintains and evolves HTTP specifications, including HTTP/3.

In this first step, we’ll set up the foundation for working with HTTP/3 in Go — preparing our environment, choosing the right packages, and running a minimal server that speaks the new protocol.

Setting Up Your First HTTP/3 Server in Go

Before we write any code, let’s understand the key points of our setup:

Golang version — Go 1.19+ is recommended (I’ll use Go 1.22 in examples).
HTTP/3 library — We’ll use github.com/quic-go/quic-go/http3, the maintained HTTP/3 implementation for Go.
TLS requirement — QUIC (and therefore HTTP/3) always uses TLS 1.3, so we must have a certificate, even for local development.
UDP — HTTP/3 runs over UDP instead of TCP, so your firewall must allow UDP traffic on the chosen port.

— — — — — — — — — — — —

Step 1 — Install Go and Create a Project

Make sure Go is installed:

go version

If you don’t have it, download and install Go.

Create a new project:

mkdir h3-demo && cd h3-demo
go mod init example.com/h3demo

Step 2 — Install HTTP/3 package

go get github.com/quic-go/quic-go/http3

Step 3 — Create a Self-Signed Certificate

For local testing, you can generate a certificate with OpenSSL:

mkdir cert
openssl req -x509 -newkey rsa:2048 -nodes \
  -subj "/CN=localhost" \
  -keyout cert/key.pem -out cert/cert.pem -days 365

Step 4 — Minimal HTTP/3 Server in Go

Create main.go:

package main
import (
 "fmt"
 "log"
 "net/http"
 "github.com/quic-go/quic-go/http3"
)
func main() {
 mux := http.NewServeMux()
 mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
  fmt.Fprintf(w, "Hello from HTTP/3! You requested %s via %s\n", r.URL.Path, r.Proto)
 })
 addr := ":4433"
 log.Printf("Starting HTTP/3 server at https://localhost%v", addr)
 if err := http3.ListenAndServeTLS(addr, "cert/cert.pem", "cert/key.pem", mux); err != nil {
  log.Fatal(err)
 }
}

Run it:

go run .

You should see output similar to:

2025/08/15 14:42:51 Starting HTTP/3 server at https://localhost:4433

Step 5 — Test with curl (macOS)

macOS’s built-in curl may not support HTTP/3. Install the Homebrew version:

brew install curl

After successful installation, you should update the PATH environment, too:

export PATH="/usr/local/opt/curl/bin:$PATH"

Check:

curl --version | grep -i http3

Request:

curl --http3-only -k https://localhost:4433/

Expected output:

Hello from HTTP/3! You requested / via HTTP/3

✅ You now have a working HTTP/3 server in Go using the modern quic-go package, running locally over QUIC and TLS 1.3.

Let’s add a tiny HTTP/3 Go client that your readers can run from the terminal and see end-to-end traffic hit the server you built.

Building an HTTP/3 Client in Go

Step 1 — Add the dependency

(You already have this from the server section; listed again for completeness.)

go get github.com/quic-go/quic-go

Step 2 — Create client.go

package main
import (
 "crypto/tls"
 "fmt"
 "io"
 "log"
 "net/http"
 "time"
 "github.com/quic-go/quic-go/http3"
)
func main() {
 // URL of the HTTP/3 server
 url := "https://localhost:4433/"
 // Create an HTTP/3 transport (QUIC)
 transport := &http3.RoundTripper{
  TLSClientConfig: &tls.Config{
   InsecureSkipVerify: true, // For local dev/self-signed certs
   MinVersion:         tls.VersionTLS13,
  },
 }
 defer transport.Close()
 // Create HTTP client using the HTTP/3 transport
 client := &http.Client{
  Transport: transport,
  Timeout:   10 * time.Second,
 }
 // Send a GET request
 start := time.Now()
 resp, err := client.Get(url)
 if err != nil {
  log.Fatal(err)
 }
 defer resp.Body.Close()
 // Read response body
 body, err := io.ReadAll(resp.Body)
 if err != nil {
  log.Fatal(err)
 }
 elapsed := time.Since(start)
 // Output results
 fmt.Printf("Status   : %s\n", resp.Status)
 fmt.Printf("Protocol : %s\n", resp.Proto) // Should be "HTTP/3"
 fmt.Printf("Elapsed  : %v\n", elapsed)
 fmt.Println("--------- Body ---------")
 fmt.Print(string(body))
}

Step 3 — Run it

If you used the simple server on :4433: (in one terminal)

go run .    # from your server project (serving on :4433)

In another terminal:

go run client.go

Example Output:

Status   : 200 OK
Protocol : HTTP/3
Elapsed  : 6.3ms
--------- Body ---------
Hello from HTTP/3!

Notes & nice extras

resp.Proto confirming HTTP/3 is the quickest sanity check that QUIC was used.
Want to demo multiplexing? Launch multiple clients concurrently (e.g., xargs -P 10 -I{} sh -c 'go run client.go -url https://localhost:4433/ -k >/dev/null' <<< "$(yes | head -n 50)") and watch your server’s logs handle parallel streams smoothly.

In the next step, we’ll extend this setup to also serve HTTP/1.1 and HTTP/2 in parallel, so you can compare protocols in one run.

🎁 Bonus: Serving HTTP/1.1, HTTP/2, and HTTP/3 Together in Go

In many real-world deployments, HTTP/3 is introduced alongside HTTP/1.1 and HTTP/2 to ensure compatibility with clients and networks that don’t yet support QUIC.
We can run a single Go app that serves:

TCP (TLS) → HTTP/1.1 & HTTP/2
UDP (QUIC) → HTTP/3

Step 1— Update the Server Code

Update main.go:

package main
import (
 "crypto/tls"
 "fmt"
 "log"
 "net"
 "net/http"
 "github.com/quic-go/quic-go/http3" // HTTP/3 server implementation using QUIC
)
func main() {
 // Create a multiplexer to handle HTTP routes
 mux := http.NewServeMux()
 // Simple handler: returns a message including the HTTP protocol used
 mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
  fmt.Fprintf(w, "Hello from %s!\n", r.Proto) // r.Proto: HTTP/1.1, HTTP/2, or HTTP/3
 })
 // Paths to your TLS certificate and key files
 certFile := "cert/cert.pem"
 keyFile := "cert/key.pem"
 // ----- HTTP/1.1 & HTTP/2 over TCP -----
 // Go's standard library automatically supports HTTP/1.1 and HTTP/2 over TLS
 tcpSrv := &http.Server{
  Addr:    ":4433",   // TCP port for HTTPS
  Handler: mux,      // Use the multiplexer defined above
  TLSConfig: &tls.Config{
   MinVersion: tls.VersionTLS13, // HTTP/3 requires TLS 1.3; use same for parity
  },
 }
 // Run TCP server in a goroutine to allow HTTP/3 server to run concurrently
 go func() {
  log.Println("Serving HTTP/1.1 and HTTP/2 on https://localhost:443")
  if err := tcpSrv.ListenAndServeTLS(certFile, keyFile); err != nil {
   log.Fatal(err)
  }
 }()
 // ----- HTTP/3 over QUIC/UDP -----
 // Resolve UDP address for QUIC (HTTP/3) server
 udpAddr, err := net.ResolveUDPAddr("udp", ":4433") // HTTP/3 uses UDP
 if err != nil {
  log.Fatal(err)
 }
 // Listen on UDP port
 udpConn, err := net.ListenUDP("udp", udpAddr)
 if err != nil {
  log.Fatal(err)
 }
 // Create HTTP/3 server using the same mux
 h3Srv := http3.Server{
  Addr:      ":4433",                     // Port for QUIC
  Handler:   mux,                        // Same handler for HTTP/1.1, HTTP/2, HTTP/3
  TLSConfig: &tls.Config{Certificates: loadCert(certFile, keyFile)}, // TLS for QUIC
 }
 // Start HTTP/3 server
 log.Println("Serving HTTP/3 on https://localhost:4433")
 if err := h3Srv.Serve(udpConn); err != nil {
  log.Fatal(err)
 }
}
// loadCert loads TLS certificate and key from files
// Returns a slice of tls.Certificate required by http3.Server
func loadCert(certFile, keyFile string) []tls.Certificate {
 cert, err := tls.LoadX509KeyPair(certFile, keyFile)
 if err != nil {
  log.Fatal(err)
 }
 return []tls.Certificate{cert}
}

Step 2 — Run the Server

go run .

Step 3 — Test All Protocols

curl --http3-only -k https://localhost:4433/
curl --http2 -k https://localhost:4433/
curl --http1.1 -k https://localhost:4433/

✅ Now you have a multi-protocol Go server that can handle clients across HTTP/1.1, HTTP/2, and HTTP/3 simultaneously — a realistic deployment scenario.

Conclusion

In this article, we explored HTTP/3, the latest evolution of the web’s core protocol, and learned why it matters: faster page loads, improved reliability, and better handling of modern network conditions thanks to QUIC over UDP.

We also walked through a practical example of setting up an HTTP/3 server in Go, demonstrating how to serve requests over HTTP/1.1, HTTP/2, and HTTP/3 simultaneously. By understanding both the conceptual background and hands-on implementation, you now have a solid foundation to experiment with HTTP/3 in your projects.

Getting Started with HTTP/3 in Python

abibeh — Wed, 10 Sep 2025 10:09:01 +0000

Does Python support HTTP/3?

Yes, but not yet natively in the standard library. Python’s http.client and common WSGI frameworks (Flask, Django) are built around HTTP/1.1 or HTTP/2 (sometimes via reverse proxies).

HTTP/3 requires QUIC (QUIC is not TCP, so it’s a big jump). Support in Python is mainly experimental and comes from third-party libraries.

Libraries to Work with HTTP/3 in Python

aioquic → A QUIC and HTTP/3 implementation in Python. You can build both clients and servers with it.
hypercorn → ASGI server supporting HTTP/1.1, HTTP/2, and experimental HTTP/3 via aioquic.
httpx → HTTP client for Python. Officially supports HTTP/1.1 and HTTP/2, but HTTP/3 is experimental with aioquic.

Perfect 🚀 Let’s sketch out a Python HTTP/3 tutorial outline that mirrors what we did with Go.
For the Golang tutorial 👉 Getting Started with HTTP/3 in Golang: A Practical Guide

‘aioquic’ library Explanation:

**aioquic** is a pure-Python QUIC and HTTP/3 library, based on the “bring your own I/O” (sans-I/O) design. It supports QUIC (RFC 9000 & 9369), HTTP/3 (RFC 9114), TLS 1.3, server push, WebSocket, and WebTransport.

The library ships with an example HTTP/3 server (and client) under examples/http3_server.py — They run an ASGI app, serve static files, WebSocket, echo endpoints, and handle HTTP/3 features like server push.

You can refer to the HTTP/3 API docs to understand the low-level classes: H3Connection, send_headers, send_data, etc.

Read the documentation for more information on this library.

Server-side Implementation

What you’ll build: a minimalist HTTP/3 server that replies “hello” to GET / and echoes JSON for POST /echo. We’ll cover why each class/argument exists, and how to grow this into something bigger.

Step 0: Prerequisites

Python: aioquic currently targets modern Python (3.8+ in recent releases)
TLS: HTTP/3 runs over QUIC + TLS 1.3, so you need a certificate & key (self-signed is fine for local dev). aioquic’s configuration handles loading them.
Install:

pip install aioquic

Step 1: Mental model: where the pieces fit

QUIC transport: managed by QuicConnection and the asyncio helper serve() for UDP I/O. We don’t touch raw sockets—serve() does that.
HTTP/3 layer: H3Connection sits on top of QUIC. You feed it QUIC events, and it gives you HTTP/3 events (headers, data, etc.). You respond with send_headers() / send_data().
Protocol glue: subclass QuicConnectionProtocol and override quic_event_received() to route events into H3Connection .

Step 2: Create a self-signed cert (dev only)

openssl req -x509 -newkey rsa:2048 -nodes -days 365 \
  -keyout key.pem -out cert.pem -subj "/CN=localhost"

In production, use a real certificate and proper hostname. QUIC requires TLS 1.3; _aioquic_ will present your certificate via its _QuicConfiguration_.

Step 3: Pick the right ALPN

HTTP/3 is negotiated via ALPN. aioquic exposes H3_ALPN (the right tokens for HTTP/3). So you don’t have to guess the strings yourself. We pass that into QuicConfiguration(alpn_protocols=H3_ALPN).

Step 4: The minimal but “real” server

Create server.py:

import argparse
import asyncio
import json
import logging
from typing import Dict, Optional
from aioquic.asyncio import QuicConnectionProtocol, serve  # asyncio helpers
from aioquic.h3.connection import H3_ALPN, H3Connection     # HTTP/3 core
from aioquic.h3.events import DataReceived, HeadersReceived, H3Event
from aioquic.quic.configuration import QuicConfiguration
LOG = logging.getLogger("h3server")
class Http3ServerProtocol(QuicConnectionProtocol):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self._http: Optional[H3Connection] = None
        # Streams we expect a body for (POST/PUT/PATCH). Value = body buffer.
        self._bodies: Dict[int, bytearray] = {}
        # Remember method/path per stream so DataReceived can route correctly.
        self._req_meta: Dict[int, tuple[str, str]] = {}
    def handle_h3_event(self, event: H3Event) -> None:
        if isinstance(event, HeadersReceived):
            headers = {k.lower(): v for k, v in event.headers}
            method = headers.get(b":method", b"").decode()
            path = headers.get(b":path", b"/").decode()
            sid = event.stream_id
            LOG.info("Headers on stream %d: %s %s", sid, method, path)
            self._req_meta[sid] = (method, path)
            if method in ("POST", "PUT", "PATCH"):
                # We expect a request body.
                self._bodies[sid] = bytearray()
                if event.stream_ended:
                    # Rare case: headers said there's a body, but FIN already set.
                    payload = bytes(self._bodies.pop(sid))
                    self._respond(sid, method, path, payload)
                    self._req_meta.pop(sid, None)
            else:
                # No body expected → respond immediately.
                self._respond(sid, method, path, body=b"")
                # Leave _bodies empty for this stream so DataReceived (empty FIN)
                # gets ignored later.
                self._req_meta.pop(sid, None)
        elif isinstance(event, DataReceived):
            sid = event.stream_id
            # If we never created a body buffer for this stream, we are NOT expecting
            # a body (e.g., GET). Ignore any data/FIN that arrives.
            if sid not in self._bodies:
                return
            # Accumulate body for methods that expect it.
            self._bodies[sid].extend(event.data)
            if event.stream_ended:
                method, path = self._req_meta.get(sid, ("", "/"))
                payload = bytes(self._bodies.pop(sid, bytearray()))
                self._respond(sid, method, path, payload)
                self._req_meta.pop(sid, None)
    # Build and send an HTTP/3 response on a stream
    def _respond(self, stream_id: int, method: Optional[str], path: Optional[str], body: bytes) -> None:
        status = b"200"
        content_type = b"text/plain"
        if method == "GET" and path == "/":
            payload = b"hello from aioquic h3 \n"
        elif method == "POST" and path == "/echo":
            try:
                obj = json.loads(body.decode() or "{}")
                payload = (json.dumps(obj, indent=2) + "\n").encode()
                content_type = b"application/json"
            except Exception:
                payload = body or b"(empty)\n"
                content_type = b"application/octet-stream"
        else:
            payload = b"ok\n"
        headers = [            (b":status", status),
            (b"server", b"aioquic-tutorial"),
            (b"content-type", content_type),
            (b"alt-svc", b'h3=":4433"; ma=3600'),
        ]
        self._http.send_headers(stream_id, headers)
        self._http.send_data(stream_id, payload, end_stream=True)
        LOG.info("Responded on stream %d (%s bytes)", stream_id, len(payload))
async def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("--host", default="::1")
    parser.add_argument("--port", type=int, default=4433)
    parser.add_argument("--certificate", default="cert.pem")
    parser.add_argument("--private-key", dest="private_key", default="key.pem")
    args = parser.parse_args()
    logging.basicConfig(level=logging.INFO)
    # QUIC/TLS configuration
    config = QuicConfiguration(
        is_client=False,
        alpn_protocols=H3_ALPN,
    )
    config.load_cert_chain(args.certificate, args.private_key)
    # 🚀 Start server
    server = await serve(
        host=args.host,
        port=args.port,
        configuration=config,
        create_protocol=Http3ServerProtocol,
    )
    logging.info("HTTP/3 server listening on %s:%d", args.host, args.port)
    # Keep running until cancelled
    try:
        await asyncio.Future()  # run forever
    except KeyboardInterrupt:
        pass
    finally:
        server.close()
if __name__ == "__main__":
    try:
        asyncio.run(main())
    except KeyboardInterrupt:
        pass

Why this structure?

QuicConnectionProtocol gives you the hook quic_event_received()—the right place to turn QUIC events into HTTP/3 events.
H3Connection is the low-level HTTP/3 engine: you call handle_event() with QUIC events, and it emits HeadersReceived, DataReceived, etc. You respond via send_headers() and send_data().
QuicConfiguration bundles transport + TLS knobs (ALPN, TLS certs, flow-control, qlog, etc.). We pass H3_ALPN, so the TLS handshake negotiates HTTP/3.
serve() is the asyncio helper that binds the UDP socket and spins protocol instances per connection.

Step 5: Run & test

Start the server:

python server.py --host ::1 --port 4433 --certificate cert.pem --private-key key.pem

After running the above command, you’ll see something like this in the console:

INFO:root:HTTP/3 server listening on ::1:4433

Hit it with curl (local, skip cert verification):

curl -v --http3 -k https://localhost:4433/
curl -v --http3 -k https://localhost:4433/echo -d '{"hello": "world"}' \
     -H 'content-type: application/json'

Note: -k ignores TLS validation since we’re using self-signed certs.

After executing the first command at the console, you’ll see in the output on the server side:

INFO:root:HTTP/3 server listening on ::1:4433
INFO:quic:[609d9451c3c3ccab] Negotiated protocol version 0x00000001 (VERSION_1)
INFO:quic:[609d9451c3c3ccab] ALPN negotiated protocol h3
INFO:h3server:Handshake complete. ALPN=h3
INFO:h3server:Headers on stream 0: GET /
INFO:h3server:Responded on stream 0 (23 bytes)
INFO:quic:[609d9451c3c3ccab] Connection close received (code 0x0, reason )

And this is on the client side when you call ‘curl’:

hello from aioquic h3

Tip: you can add _--qlog qlog.json --secrets secrets.txt_ and then open the QLOG in a viewer, or decrypt PCAPs in Wireshark with TLS secrets. _QuicLogger.to_dict()_ lets you dump traces to JSON.

Step 6: Understanding the event flow (so you can extend it)

Handshake → you get HandshakeCompleted(alpn_protocol=...). If ALPN is one of H3_ALPN, create H3Connection(self._quic).
Requests → HeadersReceived (method/path in pseudo-headers), then optional DataReceived chunks until stream_ended=True.
Responses → call send_headers() then send_data(..., end_stream=True).
Flush → call self.transmit() to actually push datagrams out (the asyncio helper handles the details).

Step 7: Common gotchas (and why)

Headers must be bytes (names and values). That’s by design in H3Connection.send_headers(...).
Respond per stream: HTTP/3 is multiplexed; always keep stream_id with your request/response state.
End the stream: set end_stream=True when you’re done sending data; otherwise, clients wait forever.
ALPN matters: If your ALPN list doesn’t include HTTP/3 (“h3”), clients won’t negotiate it. Use H3_ALPN.

Tipe: How to grow this server

a) Routing & middleware

Build a tiny router (dict of path → handler) and parse the :method/:path from HeadersReceived.
Add logging, request IDs, and exception handling around your handler dispatch.

b) Static files & content types

Look at :path, map to file system, set content-type accordingly, stream file chunks with multiple send_data() calls before end_stream=True.

c) Observability & debugging

QLOG traces: set config.quic_logger = QuicLogger(); dump to_dict() to JSON to inspect handshakes, streams, congestion, etc.
TLS secrets: set config.secrets_log_file to decrypt captures in Wireshark.

d) Performance/transport tuning

Flow control: max_data, max_stream_data in QuicConfiguration.
DATAGRAM support (for things like WebTransport): set max_datagram_frame_size in QuicConfiguration and handle DatagramReceived on the H3 side.

e) WebTransport (upgrade path)

Create H3Connection(self._quic, enable_webtransport=True) to receive WebTransport events (unidirectional/bidirectional streams, datagrams). This lets you do low-latency messaging on top of HTTP/3.

f) Production hardening

Real certificates (ACME/Let’s Encrypt), correct SNI/hostname.
Run behind a UDP-friendly firewall/load balancer.
Use a separate H1/H2 server to advertise HTTP/3 via Alt-Svc so that browsers discover your H3 endpoint.
Consider graceful shutdown: track open streams and close with application errors where appropriate.

Client side Implementation

Like the server, the client works in layers:

QUIC transport: handled by QuicConnection inside QuicConnectionProtocol.
HTTP/3: H3Connection encodes your requests and parses responses.
Asyncio helper: instead of serve(), we use connect() to initiate a QUIC connection to a server.

Step 1: Mental Model

Create QUIC config: QuicConfiguration(is_client=True, alpn_protocols=H3_ALPN).
Open QUIC connection: async with connect(...) returns a protocol object.
Build request: call h3.send_headers(stream_id, headers) and optionally send_data().
Read response events: loop over handle_event(event) until you see the full response.

Step 2: Minimal Client Code

Create client.py:

# client_fixed.py
import argparse
import asyncio
import logging
import json
from typing import Optional
from aioquic.asyncio import connect
from aioquic.asyncio.protocol import QuicConnectionProtocol
from aioquic.h3.connection import H3_ALPN, H3Connection
from aioquic.h3.events import HeadersReceived, DataReceived
from aioquic.quic.configuration import QuicConfiguration
from aioquic.quic.events import QuicEvent
LOG = logging.getLogger("h3client")
class H3ClientProtocol(QuicConnectionProtocol):
    """
    QUIC protocol subclass that also manages an H3Connection.
    Important:
      - Accept *args/**kwargs in __init__ because aioquic.connect() will call
        the factory with signature: create_protocol(connection, stream_handler=...)
      - Call super().__init__(*args, **kwargs) so the base class sets up self._quic.
    """
    def __init__(self, *args, **kwargs):
        # accept arbitrary args (connection, stream_handler=...) from connect()
        super().__init__(*args, **kwargs)
        # H3 layer bound to the underlying QUIC connection
        self._http = H3Connection(self._quic)
        # per-request state (this minimal example supports one outstanding request)
        self._stream_id: Optional[int] = None
        self._response_headers = None
        self._response_body = bytearray()
        self._done = asyncio.Event()
    def request(self, method: str, path: str, body: bytes = b""):
        """
        Build and send a simple request on a new bidirectional stream.
        """
        # get a client-initiated bidirectional stream id
        self._stream_id = self._quic.get_next_available_stream_id()
        headers = [            (b":method", method.encode()),
            (b":scheme", b"https"),
            (b":authority", b"localhost"),
            (b":path", path.encode()),
        ]
        # send headers then body; end_stream=True to finish the request
        self._http.send_headers(self._stream_id, headers)
        self._http.send_data(self._stream_id, body or b"", end_stream=True)
        # make sure bytes get pushed out
        self.transmit()
    def quic_event_received(self, event: QuicEvent):
        """
        Called by aioquic when QUIC-level events arrive.
        Hand them to H3Connection, and handle resulting H3 events.
        """
        for h3_event in self._http.handle_event(event):
            if isinstance(h3_event, HeadersReceived):
                self._response_headers = h3_event.headers
            elif isinstance(h3_event, DataReceived):
                self._response_body.extend(h3_event.data)
                if h3_event.stream_ended:
                    self._done.set()
    async def wait_response(self):
        """Wait for response completion (stream ended) and return headers+body."""
        await self._done.wait()
        return self._response_headers, bytes(self._response_body)
async def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("--host", default="localhost")
    parser.add_argument("--port", type=int, default=4433)
    parser.add_argument("--path", default="/")
    parser.add_argument("--insecure", action="store_true", default=True)
    args = parser.parse_args()
    logging.basicConfig(level=logging.INFO)
    config = QuicConfiguration(is_client=True, alpn_protocols=H3_ALPN)
    if args.insecure:
        # Only for dev/testing
        config.verify_mode = False
    # Use create_protocol=H3ClientProtocol (aioquic will call it as factory)
    async with connect(
        args.host,
        args.port,
        configuration=config,
        create_protocol=H3ClientProtocol,
    ) as protocol:
        # 'protocol' is an instance of H3ClientProtocol (the factory's return)
        protocol.request("GET", args.path)
        headers, body = await protocol.wait_response()
        LOG.info("Response headers: %s", headers)
        LOG.info("Response body:\n%s", body.decode(errors="ignore"))
if __name__ == "__main__":
    asyncio.run(main())

🔍 Breaking down **H3ClientProtocol**

class H3ClientProtocol(QuicConnectionProtocol):
    """
    QUIC protocol subclass that also manages an H3Connection.
    Important:
      - Accept *args/**kwargs in __init__ because aioquic.connect() will call
        the factory with signature: create_protocol(connection, stream_handler=...)
      - Call super().__init__(*args, **kwargs) so the base class sets up self._quic.
    """

This is a thin wrapper around two moving parts:

QUIC connection (self._quic) → the transport.
H3Connection (self._http) → the HTTP/3 layer that speaks in requests/responses.

The job of this class is:

Encode an HTTP/3 request (method, path, headers, body).
Feed QUIC events into H3Connection.
Collect HTTP/3 response headers and body.
Expose a nice wait_response() method to the caller.

**__init__**

def __init__(self, *args, **kwargs):
        # accept arbitrary args (connection, stream_handler=...) from connect()
        super().__init__(*args, **kwargs)
        # H3 layer bound to the underlying QUIC connection
        self._http = H3Connection(self._quic)
        # per-request state (this minimal example supports one outstanding request)
        self._stream_id: Optional[int] = None
        self._response_headers = None
        self._response_body = bytearray()
        self._done = asyncio.Event()

self._quic → reference to the live QUIC connection from aioquic.connect().
self._http = H3Connection(self._quic) → attaches an HTTP/3 session on top of QUIC.
self._stream_id → stores the ID of the request stream (each request lives on one bidirectional stream).
self._response_headers → will hold the [(b':status', b'200'), ...] list when the server replies.
self._response_body → a bytearray buffer where we accumulate DataReceived chunks.
self._done → an asyncio.Event we use to signal “the full response is here.”

👉 Why? HTTP/3 is multiplexed: you may have multiple streams in flight, so you need per-stream tracking. This class only handles one stream at a time (a minimal example).

**request()**

    def request(self, method: str, path: str, body: bytes = b""):
        """
        Build and send a simple request on a new bidirectional stream.
        """
        # get a client-initiated bidirectional stream id
        self._stream_id = self._quic.get_next_available_stream_id()
        headers = [            (b":method", method.encode()),
            (b":scheme", b"https"),
            (b":authority", b"localhost"),
            (b":path", path.encode()),
        ]
        # send headers then body; end_stream=True to finish the request
        self._http.send_headers(self._stream_id, headers)
        self._http.send_data(self._stream_id, body or b"", end_stream=True)
        # make sure bytes get pushed out
        self.transmit()

First, we open a new stream: get_next_available_stream_id() asks QUIC for the next free stream number.
Then, we build the mandatory HTTP/3 pseudo-headers:
- :method = GET/POST/etc.
- :scheme = https (QUIC always uses TLS).
- :authority = host/port (like Host: in HTTP/1.1).
- :path = request path (e.g. /echo).
Send the headers into the HTTP/3 engine with send_headers().
Send a body (if any) with send_data(..., end_stream=True) to mark the request finished.

👉 Why? HTTP/3 requires the pseudo-headers exactly like HTTP/2, otherwise the request is invalid. Ending the stream (end_stream=True) is important; otherwise, the server keeps waiting for more data.

**quic_event_received()**

    def quic_event_received(self, event: QuicEvent):
        """
        Called by aioquic when QUIC-level events arrive.
        Hand them to H3Connection, and handle the resulting H3 events.
        """
        for h3_event in self._http.handle_event(event):
            if isinstance(h3_event, HeadersReceived):
                self._response_headers = h3_event.headers
            elif isinstance(h3_event, DataReceived):
                self._response_body.extend(h3_event.data)
                if h3_event.stream_ended:
                    self._done.set()

This method connects the layers:

QUIC emits events (like “data came in on stream X”).
We feed them into self._http.handle_event(event).
That yields HTTP/3 events such as:
- HeadersReceived: first part of the response → save headers.
- DataReceived: chunk of the response body → append to buffer.
If event.stream_ended is true, it means the server finished sending → we set the asyncio.Event so wait_response() unblocks.

👉 Why? HTTP/3 is an event-driven protocol. We must translate raw QUIC events into meaningful HTTP/3 objects and handle them incrementally.

**wait_response()**

async def wait_response(self):
    await self._done.wait()
    return self._response_headers, bytes(self._response_body)

This is a synchronization point for the application.
The caller awaits here until the _done event is set (when the stream ended).
Then we return the headers + the full body (as immutable bytes).

👉 Why? In real HTTP/3 clients, you might want streaming (process chunks as they arrive), but here we keep it simple: collect everything, then return.

🔑 Why do we need this class at all?

We could interact with H3Connection directly in the main loop, but wrapping it in a class gives us:

Encapsulation: request(), wait_response() are nicer than juggling stream_ids and events manually.
State tracking: keeps stream_id, buffers, and headers together.
Extensibility: later, we can add:
- support for multiple streams at once,
- timeouts,
- custom error handling,
- QLOG logging,
- streaming request/response APIs.

Step 3: Test it

Run your server:

python h3_server.py --host :: --port 4433 --certificate cert.pem --private-key key.pem

Run the client:

python h3_client.py --host localhost --port 4433 --path /

You should see logs like:

INFO:quic:[110acafccf372968] Negotiated protocol version 0x00000001 (VERSION_1)
INFO:quic:[110acafccf372968] ALPN negotiated protocol h3
INFO:h3client:Response headers: [(b':status', b'200'), (b'server', b'aioquic-tutorial'), (b'content-type', b'text/plain'), (b'alt-svc', b'h3=":4433"; ma=3600')]
INFO:h3client:Response body:
hello from aioquic h3 
INFO:quic:[110acafccf372968] Connection close sent (code 0x0, reason )

Step 4: Improvements

Add POST with --data flag to send a body.
Support multiple requests (reuse connection, open multiple streams).
Validate certs (skip --insecure in production).
Collect timing info (request start/end).
Dump QLOG on the client side for debugging.

DEV Community: abibeh

Introduction to Gonyx

What is Gonyx?

Key Features

Getting Started

Installation

Prerequisites

Creating a New Gonyx Project

Project Structure

Understanding Your New Project

Controllers

Running Your Application

Configuration Modes

Next Steps

[Boost]

Getting Started with HTTP/3 in Python

[Boost]

Getting Started with HTTP/3 in Golang: A Practical Guide

Rust + Flutter: How to Build Fast, Safe, Cross-Platform Mobile Apps

Benefits of Using Rust in Flutter Apps

🚀 High Performance

📱 Cross-Platform Core Logic

🛡️ Memory Safety

⚡ Concurrency and Async

📦 Rich Ecosystem

🔧 Maintainability

Real-World Applications Using Embedded Native Code

🔹 Telegram

🔹 Signal

🔹 Discord

🔹 Brave Browser (Mobile)

TL;DR

Assumptions / prerequisites

High-level approaches — pick one

Approach 1 — Manual Integration (Full Control)

Project layout suggested

1. Create the Rust library crate

2. (Optional) Generate a C header with cbindgen

3. Install Android NDK

4. Build for Android (recommended: use cargo-ndk)

Copy .so to your Flutter Android project

5. Build for iOS (create an XCFramework or link static lib)

Option A — recommended: produce an XCFramework using cargo xcode and xcodebuild

Option B — simpler (static .a) and link it in Xcode

Add the XCFramework to your Runner

6. Dart side — calling Rust with dart:ffi

7. Use in Flutter App

8. Flutter build & run

Android

iOS

9. Common pitfalls & troubleshooting

10. Advanced: async, callbacks and threading

Conclusion:

Approach 2 — Quickstart with FRB create Command (Easiest)

1. Install prerequisites

2. Create a new Flutter + Rust project

3. Run the project

4. Modify Rust code

5. Regenerate bindings (new workflow)

6. Dart side usage

Conclusion:

Getting Started with HTTP/3 in Golang: A Practical Guide

Introduction

📜 Official Specifications & Technical References

Setting Up Your First HTTP/3 Server in Go

Building an HTTP/3 Client in Go

🎁 Bonus: Serving HTTP/1.1, HTTP/2, and HTTP/3 Together in Go

Conclusion

Getting Started with HTTP/3 in Python

Does Python support HTTP/3?

Libraries to Work with HTTP/3 in Python

‘aioquic’ library Explanation:

Server-side Implementation

Client side Implementation

🔑 Why do we need this class at all?

2. (Optional) Generate a C header with `cbindgen`

4. Build for Android (recommended: use `cargo-ndk`)

Copy `.so` to your Flutter Android project

Option A — recommended: produce an XCFramework using `cargo xcode` and `xcodebuild`

Option B — simpler (static `.a`) and link it in Xcode

6. Dart side — calling Rust with `dart:ffi`