Forem: Rogério Araújo

🚀 Vetis: a very tiny, very fast HTTP server in Rust

Rogério Araújo — Fri, 23 Jan 2026 21:36:32 +0000

If you like small, fast, no-magic tools, you’re going to enjoy Vetis.

Vetis is a minimalist HTTP server written in Rust, created by ararog. It focuses on performance, simplicity, and modern HTTP support, without trying to be a full web framework.

👉 Repo: https://github.com/ararog/vetis

🤔 What is Vetis?

Vetis (short for Very Tiny Server) is an async HTTP server designed to do one thing really well:

Serve HTTP efficiently, with as little overhead as possible.

Instead of providing routing DSLs, middleware stacks, or heavy abstractions, Vetis gives you a clean and explicit server core that you can shape to your needs.

It’s a great fit for:

Lightweight APIs
Microservices
High-performance networking tools
Learning how modern Rust HTTP servers work

✨ Why Vetis exists

The Rust ecosystem has amazing web frameworks (Axum, Actix, Warp…), but sometimes you don’t want everything.

Vetis is for when you want:

🧠 Full control
⚡ Minimal overhead
🦀 Idiomatic async Rust
🌐 Modern HTTP protocols

No surprises. No hidden macros. Just Rust.

🔥 Key Features

⚡ Performance-first design

Vetis keeps the API surface small and avoids unnecessary abstractions. That means less overhead and more predictable performance — especially useful for latency-sensitive workloads.

🌐 Modern HTTP support

Via feature flags, Vetis supports:

HTTP/1
HTTP/2
HTTP/3 (QUIC)

🔌 Runtime flexibility

Vetis doesn’t lock you into a single async runtime. You can run it on:

Tokio
Smol

🧪 Small and readable API

Vetis favors explicit code over clever abstractions. If you enjoy reading and understanding your server code, you’ll feel at home here.

🧪 A minimal Vetis server

use bytes::Bytes;
use clap::Parser;
use http_body_util::Full;
use hyper::Response;
use vetis::{server::config::ServerConfig, Vetis};

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let args = Args::parse();

    let config = ServerConfig::builder()
        .interface(args.interface)
        .port(args.port)
        .build();

    let mut server = Vetis::new(config);

    server
        .run(|_| async move {
            Ok(Response::new(Full::new(Bytes::from("Hello World"))))
        })
        .await?;

    server.stop().await?;
    Ok(())
}

📦 Getting started

vetis = { version = "0.1.0", features = ["tokio-rt", "http2", "tokio-rust-tls"] }

🛠 Open source & contributions

Vetis is released under the MIT License.

👉 https://github.com/ararog/vetis

🌟 Final thoughts

Vetis is perfect when you want speed, control, and simplicity — nothing more, nothing less.

Happy hacking 🦀

Real-time Communication with WebSockets using deboa-extras

Rogério Araújo — Wed, 03 Dec 2025 14:10:31 +0000

WebSockets provide a powerful way to enable real-time, bidirectional communication between clients and servers. In this article, we'll explore how to implement WebSocket clients using the deboa-extras crate, a lightweight and flexible HTTP client library for Rust.

Introduction to deboa-extras WebSocket Support

The deboa-extras crate extends the core deboa HTTP client with WebSocket capabilities, making it easy to establish WebSocket connections and exchange messages in real-time. It's built on top of the hyper library and provides an ergonomic API for WebSocket communication.

Setting Up Your Project

First, add the necessary dependencies to your Cargo.toml:

[dependencies]
deboa = "0.0.9"
deboa-extras = { version = "0.0.5", features = ["websockets"] }
tokio = { version = "1.0", features = ["full"] }

Establishing a WebSocket Connection

To create a WebSocket connection, you'll use the WebsocketRequestBuilder trait:

use deboa::{Deboa, Result, request::DeboaRequestBuilder};
use deboa_extras::ws::{
    io::socket::DeboaWebSocket,
    protocol::Message,
    request::WebsocketRequestBuilder,
    response::IntoWebSocket,
};

#[tokio::main]
async fn main() -> Result<()> {
    let mut client = Deboa::new();

    // Create a WebSocket connection
    let mut websocket = DeboaRequestBuilder::websocket("wss://echo.websocket.org")?
        .send_with(&mut client)
        .await?
        .into_websocket()
        .await?;

    // Now you can send and receive messages
    websocket.send_text("Hello, WebSocket!").await?;

    if let Some(message) = websocket.read_message().await? {
        match message {
            Message::Text(text) => println!("Received: {}", text),
            Message::Binary(data) => println!("Received binary data: {:?}", data),
            Message::Close(code, reason) => println!("Connection closed: {} - {}", code, reason),
            _ => {} // Handle other message types if needed
        }
    }

    Ok(())
}

Sending and Receiving Messages

The DeboaWebSocket trait provides several methods for different types of messages:

// Send a text message
websocket.send_text("Hello, WebSocket!").await?;

// Send binary data
websocket.send_binary(&[0x01, 0x02, 0x03]).await?;

// Send a ping
websocket.send_ping(b"ping").await?;

// Close the connection
websocket.send_close(1000, "Normal closure").await?;

Handling Incoming Messages

To handle incoming messages, you'll typically use a loop:

loop {
    match websocket.read_message().await? {
        Some(Message::Text(text)) => {
            println!("Received text: {}", text);
            // Echo back the message
            websocket.send_text(format!("You said: {}", text)).await?;
        }
        Some(Message::Binary(data)) => {
            println!("Received binary data: {:?}", data);
        }
        Some(Message::Ping(data)) => {
            println!("Received ping, sending pong");
            websocket.send_pong(data).await?;
        }
        Some(Message::Close(code, reason)) => {
            println!("Connection closed: {} - {}", code, reason);
            break;
        }
        None => {
            println!("Connection closed by server");
            break;
        }
        _ => {} // Handle other message types
    }
}

Error Handling

The WebSocket implementation in deboa-extras provides detailed error handling:

match websocket.read_message().await {
    Ok(Some(message)) => {
        // Handle message
    }
    Err(e) => match e {
        DeboaExtrasError::WebSocket(WebSocketError::SendMessage { message }) => {
            eprintln!("Failed to send message: {}", message);
        }
        DeboaExtrasError::WebSocket(WebSocketError::ReceiveMessage { message }) => {
            eprintln!("Failed to receive message: {}", message);
        }
        _ => eprintln!("Unexpected error: {:?}", e),
    },
    _ => {} // Handle other cases
}

Building a Simple Chat Application

Let's create a simple chat client that connects to a WebSocket server and echoes messages:

use deboa::{Deboa, Result, request::DeboaRequestBuilder};
use deboa_extras::ws::{
    io::socket::DeboaWebSocket,
    protocol::Message,
    request::WebsocketRequestBuilder,
    response::IntoWebSocket,
};
use tokio::io::{self, AsyncBufReadExt};

#[tokio::main]
async fn main() -> Result<()> {
    println!("Connecting to WebSocket server...");

    let mut client = Deboa::new();
    let mut websocket = DeboaRequestBuilder::websocket("wss://echo.websocket.org")?
        .send_with(&mut client)
        .await?
        .into_websocket()
        .await?;

    println!("Connected! Type a message and press Enter to send. Type 'exit' to quit.");

    let stdin = io::stdin();
    let mut reader = io::BufReader::new(stdin).lines();

    loop {
        tokio::select! {
            // Read from stdin
            Ok(Some(line)) = reader.next_line() => {
                if line.trim() == "exit" {
                    websocket.send_close(1000, "User requested close").await?;
                    break;
                }
                if !line.trim().is_empty() {
                    websocket.send_text(&line).await?;
                }
            }

            // Read from WebSocket
            result = websocket.read_message() => {
                match result {
                    Ok(Some(Message::Text(text))) => {
                        println!("Server: {}", text);
                    }
                    Ok(Some(Message::Close(code, reason))) => {
                        println!("Server closed connection: {} - {}", code, reason);
                        break;
                    }
                    Ok(None) => {
                        println!("Connection closed by server");
                        break;
                    }
                    Err(e) => {
                        eprintln!("Error reading message: {}", e);
                        break;
                    }
                    _ => {} // Ignore other message types
                }
            }
        }
    }

    println!("Disconnected");
    Ok(())
}

Best Practices

Error Handling: Always handle potential errors when sending and receiving messages.
Connection Management: Implement proper connection handling with reconnection logic.
Message Framing: Be aware of message size limits and implement fragmentation if needed.
Resource Cleanup: Always close the WebSocket connection properly when done.
Concurrency: Use tokio::select! to handle multiple asynchronous operations concurrently.

Conclusion

The deboa-extras crate provides a simple yet powerful way to work with WebSockets in Rust. With its intuitive API and support for different message types, you can easily build real-time applications that require bidirectional communication.

Whether you're building a chat application, a real-time dashboard, or any other application that requires real-time updates, deboa-extras has you covered with its WebSocket support.

Next Steps

Explore more advanced features like message compression
Implement custom serialization for complex message types
Add authentication to your WebSocket connections
Handle network interruptions and implement reconnection logic

Happy coding with WebSockets and deboa-extras!

⚡ JSON vs. Apache Fory: Choosing Your Data Serialization Powerhouse

Rogério Araújo — Sun, 30 Nov 2025 16:58:20 +0000

In today's interconnected world, efficiently moving data between services and systems is crucial. Two major players in the data serialization game are JSON (JavaScript Object Notation) and the high-performance contender, Apache Fory (formerly known as Apache Fury). While JSON dominates the web and APIs due to its simplicity and readability, Apache Fory steps in where speed, size, and advanced features are paramount.

Which one is right for your project? Let's break down the key differences.

📝 JSON: The Readable, Universal Standard

JSON is a text-based data format that has become the de-facto standard for data exchange on the web.

Key Characteristics of JSON

Human-Readable: JSON's text format, using clear key-value pairs and common symbols (like {}, [], and ""), makes it easy for developers to read, write, and debug data without special tools.
Widespread Adoption: Virtually every programming language, system, and framework has built-in support for parsing and generating JSON. This makes it incredibly language-agnostic and easy to integrate.
Flexibility (Schema-less): JSON doesn't strictly enforce a pre-defined schema, allowing for quick changes and flexibility in data structure, which is great for fast development or systems where the data structure evolves frequently.
Performance Trade-offs: Being a text-based format means it has overhead. Serialization and deserialization can be slower than binary formats, and the resulting file size is typically larger (more bandwidth and storage consumed).

🚀 Apache Fory: The Blazing-Fast, Feature-Rich Binary Format

Apache Fory is a blazingly-fast, multi-language serialization framework designed for high-performance and distributed systems. It’s a modern binary format focused on optimizing serialization for speed and size.

Key Characteristics of Apache Fory

Binary and Compact: Fory serializes data into a compact binary protocol, resulting in significantly smaller data sizes (often leading to a 50% or more reduction compared to JSON) and faster network transfer.
Ultra-Fast Performance: Leveraging Just-In-Time (JIT) compilation and zero-copy techniques, Fory offers a massive performance boost, with benchmarks often showing 10x to 20x faster serialization/deserialization speeds than JSON or even other binary formats like Protocol Buffers in specific scenarios.
Advanced Features: Fory supports complex object-oriented features that are difficult or impossible to handle cleanly in JSON, such as:
- Polymorphism: Serializing objects with their actual runtime types.
- Reference Preservation: Correctly handling shared and circular references within an object graph.
Cross-Language without IDL: Fory simplifies cross-language communication by automatically deriving schema information from your class/struct definitions, eliminating the need to manually write and compile a Domain-Specific Language (DSL) or Interface Definition Language (IDL) file like you would with some other binary formats.
Schema Evolution: Fory supports both "Schema Consistent" mode for maximum performance and a "Compatible Mode" that allows for independent schema evolution (adding/removing fields) across different languages without coordinated upgrades.
Not Human-Readable: The serialized data is a compressed binary stream, making it unusable for direct human reading or debugging without a deserializer.

📊 Direct Comparison: JSON vs. Apache Fory

Feature	JSON (JavaScript Object Notation)	Apache Fory
Data Format	Text-based (human-readable)	Binary (compact, not human-readable)
Performance	Slower serialization/deserialization	Ultra-fast (JIT, Zero-Copy)
Data Size	Larger (due to text overhead)	Significantly smaller (compact binary)
Primary Use Case	Web APIs, Configuration, Simple Data Exchange, Debugging	High-Performance Microservices, Distributed Caching, High-Volume Data Pipelines
Schema	Schema-less (flexible)	Supports schema evolution and strong type mapping
Cross-Language	Universal (supported everywhere)	Multi-language (Java, Python, Rust, Go, etc.) without requiring IDL
Complex Objects	Limited support for polymorphism or object references	Excellent support for polymorphism and circular references

🎯 When to Choose Which

The choice between JSON and Apache Fory boils down to your project's priorities.

✅ Choose JSON when:

Human Readability is a requirement: You need developers or users to easily inspect, debug, or edit the data directly.
Interoperability is paramount: You are building a public-facing API (REST), or exchanging data with a very diverse set of external, general-purpose clients.
Data size and speed are not the primary bottleneck: The performance hit of text serialization is acceptable for your traffic volume.

✅ Choose Apache Fory when:

Performance is critical: You need the absolute fastest serialization/deserialization speed for low-latency communication (e.g., RPC calls between microservices).
Data size matters: You need to minimize network bandwidth or storage costs (e.g., caching or storing large object graphs).
You deal with complex object structures: You need native support for features like polymorphism or shared/circular references across languages.
You have controlled endpoints: Both the sender and receiver are internal, controlled systems that can implement the Fory framework.

In many modern architectures, you might even use both: JSON for public-facing web APIs and human-consumption data, and Apache Fory for high-speed, high-volume internal service-to-service communication.

A Deep Dive into `ararog/uget`: The Modern Command-Line HTTP Client

Rogério Araújo — Fri, 28 Nov 2025 20:34:07 +0000

For developers and command-line enthusiasts, tools like curl and wget are staples for making HTTP requests and downloading files. However, a new player has emerged, offering a streamlined, modern, and Rust-powered alternative: uget by developer ararog.

This post focuses specifically on the project found at https://github.com/ararog/uget, a minimalist command-line HTTP utility.

What is `ararog/uget`?

ararog/uget is defined as a modern and straightforward HTTP client for the command line. It is a minimal CLI tool designed to simplify interactions with web services, downloads, and data transmission, built entirely using the Rust programming language.

It is crucial to note that this project is distinct from the long-standing, cross-platform uGet Download Manager (which often has a graphical user interface and is hosted under the ugetdm organization). The ararog/uget project is focused purely on lightweight, developer-centric command-line functionality.

Key Features for the Modern Developer

uget strips away complexity while retaining essential functionality, making it an excellent choice for scripting, debugging APIs, and simple file transfers. Its feature set is purpose-built for efficiency:

1. Simplified HTTP Interaction

uget makes common HTTP methods clean and easy to execute. It's built to handle basic GET requests, JSON payloads, and form submissions with minimal boilerplate.

2. File Download and Upload Support

As a robust HTTP client, uget excels at file operations. It allows you to:

Download files and show a progress bar during the transfer.
Resume a download from where it previously left off.
Upload files using multipart form fields.

3. Comprehensive Request Configuration

It provides simple flags for setting up complex requests:

Easily set custom headers (--header "Content-Type: application/json").
Specify request method (-m POST, -m PUT).
Handle various request bodies, including JSON (via stdin) and standard form fields (--field).

4. Robust Authentication and Security

uget simplifies the common task of securing API calls:

Bearer Auth: Easily pass a token for modern API authentication (--bearer <token>).
Basic Auth: Supports standard username and password credentials (--basic <username>:<password>).
Mutual TLS: Allows the use of client certificates and private keys for mutual authentication.
Custom CA: Supports custom CA certificates for verification, critical when dealing with enterprise or self-signed certificates.

Basic Usage Examples

The tool's command structure is designed for intuitive use, typically following the format: uget <url> <body> [OPTIONS].

Action	Command Example	Explanation
Simple GET	`uget https://api.example.com/status`	Downloads the resource and prints the response body to `stdout`.
JSON POST	`uget https://api.example.com/data "{'data': 'new'}"`	Pipes a JSON payload into `uget`, which automatically defaults to a `POST` request.
Form POST	`uget https://forms.example.com/submit --field "user=alice" --field "pass=secret"`	Submits data as a standard URL-encoded form.
Bearer Auth	`uget https://api.example.com/profile -m GET --bearer <YOUR_TOKEN>`	Performs a secure GET request using a Bearer token.
Download	`uget https://cdn.example.com/file.zip > file.zip`	Downloads the file and redirects the output to save it locally.

Why Choose `ararog/uget`?

Rust Performance: Being built in Rust, uget offers the benefits of memory safety and high performance, often outperforming utilities written in interpreted languages.
Modern Syntax: Its flags and usage patterns are streamlined for today's API-centric development workflows, making it a highly readable and easy-to-script tool.
Minimalist Focus: It does one thing—handle HTTP—and does it well, avoiding bloat and unnecessary complexity.

If you are looking for a fast, simple, and reliable CLI tool to manage your HTTP requests, ararog/uget is definitely a repository worth starring and integrating into your workflow.

🦀 Reqwest vs. Deboa: Which Rust HTTP Client is Right for Your Project?

Rogério Araújo — Fri, 28 Nov 2025 19:55:22 +0000

When building modern applications in Rust, an efficient and reliable HTTP client is essential. Two popular choices in the Rust ecosystem are reqwest and deboa. While reqwest is the long-standing, feature-rich powerhouse, deboa is emerging as a compelling, lightweight alternative.

This post dives into their key differences, with a focus on performance and suitability for different use cases.

🏗️ Core Philosophy and Design

Reqwest: The Feature-Rich Standard

reqwest is often considered the de-facto standard for asynchronous HTTP requests in Rust. It's built on top of the powerful hyper library, which provides the underlying HTTP implementation.

Key Design: A high-level, easy-to-use API that provides both blocking and asynchronous modes. It's designed for completeness, offering extensive features like JSON serialization/deserialization, redirects, cookie handling, and support for both native-tls and rustls for TLS connections.
Dependency Footprint: Due to its broad feature set and the use of hyper and an asynchronous runtime like tokio (or async-std), reqwest can have a larger dependency tree and a greater compiled binary size.

Deboa: The Lightweight and Flexible Contender

deboa is a more recent and developer-centric HTTP client. The name, which means "I'm ok" in Portuguese, suggests its focus on straightforward usability and efficiency.

Key Design: A straightforward, non-opinionated, and highly flexible client, also built on hyper. It aims to provide essential modern features—including flexible authentication, serialization (JSON, XML, MsgPack), and middleware support—while maintaining simplicity and a lighter touch.
Dependency Footprint: deboa positions itself as a more lightweight alternative. It's especially suited for projects where smaller binary size or a more focused feature set is a priority. It offers compatibility with various runtimes (tokio, smol) and pluggable features.

⚡ Performance and Binary Size Comparison

Direct, head-to-head performance benchmarks between reqwest and deboa are difficult to find, as performance is often heavily influenced by configuration and workload. However, we can analyze the common trade-offs.

📊 Performance Factors

Feature	`reqwest`	`deboa`	Implication for Performance
Foundation	`hyper`	`hyper`	Both utilize the high-performance `hyper` core.
TLS Backend	`native-tls` (default) or `rustls`	`rustls` is common	Configuration matters greatly. `reqwest`'s default `native-tls` can sometimes be slower for client creation than `rustls` (especially without client reuse), but a properly configured `reqwest` with `rustls-tls` can be very fast.
Client Reuse	Critical for performance.	Critical for performance.	Both clients should be instantiated once and reused to avoid the overhead of setting up TLS and connection pooling.
Runtime	Heavily integrated with `tokio` (though configurable).	Supports multiple runtimes (`tokio`, `smol`).	`deboa`'s flexibility could be beneficial in environments where a specific runtime other than `tokio` is preferred or provides an edge.

📉 Binary Size

One of the most notable distinctions is in size. reqwest is generally heavier due to its extensive feature set and dependencies. For projects where binary size is a critical constraint (e.g., small embedded systems or environments with strict deployment limits), deboa or other specialized, minimalistic clients are often the preferred choice.

⚠️ Caveat on Performance Benchmarks

It's important to note that many reports on reqwest performance issues (such as inconsistencies or slowness compared to other tools) often trace back to:

Not reusing the reqwest::Client: Creating a new client for every request incurs high overhead, especially for TLS handshakes.
Using default features: The default native-tls can be slower than the rustls-tls feature for client creation time in some contexts.

When used correctly, both clients provide high performance, leveraging the efficiency of the hyper HTTP stack.

🎯 Which Should You Choose?

Choose `reqwest` if:

You need a complete solution: You want a well-established, battle-tested client with a high-level API for nearly every common HTTP use case (forms, redirects, advanced authentication, etc.).
You are new to Rust networking: Its excellent documentation and large community make it easier to get help and find examples.
Binary size is not a primary concern: You're building a standard backend service or application where the small size penalty is acceptable for the feature completeness.

Choose `deboa` if:

You prioritize a lightweight binary: You want an efficient client with a smaller dependency footprint.
You need runtime flexibility: You are building an application that needs to be compatible with a runtime other than the default tokio ecosystem, like smol.
You prefer a focused API: You want a modern, less-opinionated client that provides core features like pluggable serialization and middleware without the bloat of more niche utilities.

Ultimately, both reqwest and deboa are excellent choices in the Rust ecosystem. Your decision should be based on your project's specific needs for features, binary size, and required ecosystem integration.

This video gives a good overview of how to set up reqwest and use it for basic monitoring tasks. Monitoring URLs with Tokio and Reqwest | Rust HTTP Monitor Part 1

Exploring deboa-macros: Ergonomic HTTP Client Macros for Rust

Rogério Araújo — Fri, 28 Nov 2025 16:52:41 +0000

What is `deboa-macros`?

deboa-macros is a procedural-macro crate for Rust that builds on top of the core HTTP client deboa. Its goal is to simplify common HTTP request patterns using expressive macros---turning verbose boilerplate into concise, type-safe code.

Where deboa provides low-level HTTP capabilities (HTTP/1 + HTTP/2, async runtimes like Tokio or Smol, etc.), deboa-macros layers ergonomic syntax on top so you can focus on logic instead of
request-building ceremony.

Why Macros? --- The Case for `deboa-macros`

Rust's procedural macros allow developers to run code at compile time to generate boilerplate, enforce patterns, and create domain-specific syntax.

For HTTP requests, much of the code is repetitive:

building the request
serializing bodies
deserializing responses
handling errors

deboa-macros addresses these pain points with:

Shorthand macros for common HTTP methods (get!, post!, put!, patch!, delete!, fetch!)
Compile-time type safety for request/response bodies (via Serde)
Async/await support
Declarative API client definitions using the #[bora] attribute macro

The result is a more pleasant, readable workflow---without sacrificing control or safety.

Update

Starting from deboa-macros 0.0.7, bora macro won’t be available on this crate anymore. It has been moved to vamo-macros crate.

Key Features & API Overview

✔ Function-like Macros

deboa-macros provides macros corresponding to HTTP verbs:

get!
post!
put!
patch!
delete!
fetch! (generic method caller)

Each macro expands into an async HTTP call using deboa, with optional body and response type handling.

✔ `#[bora]` Attribute Macro

The bora macro lets you define a high-level API client declaratively.

You describe:

the endpoints
their HTTP methods
input parameters
response bodies
serialization format

The macro generates a fully-typed client struct with async methods.

✔ Serialization Formats Supported

JSON
XML
MessagePack

All wired through Serde.

Example: GET Request Using `get!`

use deboa::Deboa;
use deboa_extras::http::serde::json::JsonBody;

#[derive(serde::Deserialize)]
struct Post {
    id: u32,
    title: String,
    body: String,
    userId: u32,
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let mut client = Deboa::new();
    let post: Post = get!(
        "https://jsonplaceholder.typicode.com/posts/1",
        &mut client,
        JsonBody,
        Post
    );

    println!("Post title: {}", post.title);
    Ok(())
}

Example: Declarative API Client with `#[bora]`

use deboa::errors::DeboaError;
use deboa_macros::bora;
use vamo::Vamo;

#[derive(Deserialize, Debug)]
pub struct Post {
    pub id: u32,
    pub title: String,
}

#[bora(
    api(
        get(name="get_by_id", path="/posts/<id:i32>", res_body=Post, format="json")
    )
)]
pub struct PostService;

#[tokio::main]
async fn main() -> Result<(), DeboaError> {
    let client = Vamo::new("https://jsonplaceholder.typicode.com");
    let mut service = PostService::new(client);

    let post = service.get_by_id(1).await?;
    println!("id: {}", post.id);
    println!("title: {}", post.title);

    Ok(())
}

When to Use `deboa-macros`

Great Fit When:

You want concise, readable HTTP calls.
You prefer declarative API client definitions.
You care about type-safe request/response handling.
You're working with async Rust.

Consider Using Raw `deboa` When:

You need very fine-grained control over request lifecycle.
You need complex middleware or streaming.
You prefer explicit, hand-written code over macro-generated abstractions.

Ecosystem Fit

deboa-macros sits on top of a trio of crates:

deboa --- core HTTP client
deboa-extras --- additional serialization/compression helpers, websockets, sse and custom middleware (catchers).
deboa-macros --- ergonomic macros and declarative API definitions

This combination forms a flexible stack for building REST clients in Rust with minimal boilerplate.

My Take

As a developer, libraries that reduce boilerplate without hiding
important details are always welcome. deboa-macros hits that sweet spot:

It speeds up API client creation
It preserves strong typing
It works seamlessly with Rust async and Serde
You can still drop down to raw deboa for advanced behavior

If you're building internal tools, microservices, or interacting with REST APIs, deboa-macros is definitely worth trying.

Conclusion

deboa-macros brings ergonomic macros, type safety, and readability to HTTP client code in Rust. It builds on deboa's solid async foundation to provide high-level, expressive syntax ideal for REST-heavy applications.

If you enjoy clean, declarative Rust with less boilerplate---and still want full control when needed---this crate is a strong choice.

Vamo, a rest api friendly client

Rogério Araújo — Wed, 26 Nov 2025 23:44:51 +0000

Continuing our series of blog posts about deboa ecosystem, we will now cover Vamo, a rest api client built on top of deboa.

Despite existing http clients written in rust, deboa comes with this friendly companion crate. Vamo is a very straightforward way to setup your client once with a base url, allowing you issue your requests after by just specifying the path of resource to be requested.

Installing

In order to start using vamo in your project, please add vamo into your project with following command:

cargo add vamo

Initializing client

Initialize vamo client is easy as initialize a deboa client, let's check out the example below.

Example

use vamo::Vamo;

let vamo = Vamo::new("https://api.example.com")?;

Sending requests

Now that we have vamo client initialized, you can start issuing your requests, don't mind to give full url anymore, just the resource path and you are done.

Example

use vamo::Vamo;

let vamo = Vamo::new("https://api.example.com")?;
let response = vamo
    .get("/users")?
    .send()
    .await?;

Request trait

Request trait is a experimental feature of vamo crate, with Request trait, you can easily turn any rust struct into a kind self contained request object to be sent over vamo.

Example

use deboa::{client::serde::RequestBody, Result};
use vamo::{Vamo, resource::{Resource, ResourceMethod}};
use deboa_extras::http::serde::json::JsonBody;
use serde::Serialize;

#[derive(Serialize)]
struct Post {
    id: u64,
    title: String,
    #[serde(skip_serializing_if = "Option::is_none")]
    body: Option<String>,
    #[serde(skip_serializing_if = "Option::is_none")]
    user_id: Option<u64>,
}

impl Resource for Post {
    fn id(&self) -> String {
        self.id.to_string()
    }

    fn name(&self) -> &str {
        "posts"
    }

    fn body_type(&self) -> impl RequestBody {
        JsonBody
    }
}

let mut vamo = Vamo::new("https://api.example.com")?;
// Assuming Post is a Resource
let mut post = Post {
     id: 1,
     title: "Some title".to_string(),
     body: "Some body".to_string(),
     user_id: 1,
};
let response = vamo.create(&mut post)?.send().await?;

Please note that you don't need to implement Resource trait manually, in order to make this happen, please check section below.

Final thoughts

As we can see, it is faily simple make requests with vamo, and to make this task even more simplier, a Request trait has been introduced to make every happen straight from your structs. I stronly invite you to also give a try on vamo-macros, which can simply generate a implementation of Request trait for your struct by just annotating your struct with #[derive(Resource)].

You can find vamo under deboa repository at https://github.com/ararog/deboa, or under creates.io at https://crates.io/crates/deboa.

A complete documentation is also available at https://docs.rs/vamo/latest/vamo/.

deboa, a simple http client for rust

Rogério Araújo — Mon, 17 Nov 2025 23:13:46 +0000

Few months ago, I started an effort on create a very simple and easy to use http client.

At first, I just tried to mimic the same approach as apisauce for NodeJS, but that didn’t sound appropriate, so I started to refactor to be more rust friendly lib.

Once I moved forward with Deboa implementation, I started to brake it down by features, then by separate crates. Nowadays, Deboa is very modular and can take minimal space on final binary size.

So far, whole Deboa ecosystem is made of following crates:

deboa
deboa-extras
deboa-macros
deboa-fory
vamo
vamo-macros

In this post, we will cover Deboa and some of its features.

Features

Right now Deboa has the following features:

tokio-rt
smol-rt
http1
http2

All the examples on this post are based on tokio-rt and http1.

Adding Deboa to your project

You can easy add Deboa to your rust project using cargo, like so:

cargo add deboa

Initializing client

Create a new client instance can be simple as call Deboa::new(), but you can also setup interceptors, protocol to use, among other things.

Example

use deboa::{Deboa, Result};

#[tokio::main]
async fn main() -> Result<()> {
    let mut client = Deboa::new();
}

Making requests

You have many ways to create a request within Deboa, the most common way is by initializing DeboaResponse.

There are several ways to create a instance of DeboaRequest:

by using get, post, delete, put and patch request module functions
by using FetchWith trait
by taking advantage of IntoRequest trait

Example

use deboa::{
    Deboa, Result, request::{DeboaRequest, FetchWith, get}
};

#[tokio::main]
async fn main() -> Result<()> {
    let mut client = Deboa::new();    
    let req = get("https://jsonplaceholder.typicode.com/posts")?;

    // process request
}

Reading responses

Once request is issued with send_with, fetch_with or Deboa::execute, you will have access to DeboaResponse. Within DeboaResponse you can check status_code, cookies, headers and read response body.

Example

use deboa::{
    Deboa, Result, request::{DeboaRequest, FetchWith, get}
};

#[tokio::main]
async fn main() -> Result<()> {
    let mut client = Deboa::new();    
    let req = get("https://jsonplaceholder.typicode.com/posts")?;
    let res = req
      .send_with(client)
      .await?
      .raw_body()
      .await?;

    // do something with bytes
}

Final thoughts

As we can see, with Deboa you can easily initialize client, customize it, create request in several different ways and read responses in a very feel steps.

I strongly recommend you to visit deboa repository, try examples, and leave your star if you like it!

Github: https://github.com/ararog/deboa

Forem: Rogério Araújo

🚀 Vetis: a very tiny, very fast HTTP server in Rust

🤔 What is Vetis?

✨ Why Vetis exists

🔥 Key Features

⚡ Performance-first design

🌐 Modern HTTP support

🔌 Runtime flexibility

🧪 Small and readable API

🧪 A minimal Vetis server

📦 Getting started

🛠 Open source & contributions

🌟 Final thoughts

Real-time Communication with WebSockets using deboa-extras

Introduction to deboa-extras WebSocket Support

Setting Up Your Project

Establishing a WebSocket Connection

Sending and Receiving Messages

Handling Incoming Messages

Error Handling

Building a Simple Chat Application

Best Practices

Conclusion

Next Steps

⚡ JSON vs. Apache Fory: Choosing Your Data Serialization Powerhouse

📝 JSON: The Readable, Universal Standard

Key Characteristics of JSON

🚀 Apache Fory: The Blazing-Fast, Feature-Rich Binary Format

Key Characteristics of Apache Fory

📊 Direct Comparison: JSON vs. Apache Fory

🎯 When to Choose Which

✅ Choose JSON when:

✅ Choose Apache Fory when:

A Deep Dive into `ararog/uget`: The Modern Command-Line HTTP Client

What is ararog/uget?

Key Features for the Modern Developer

1. Simplified HTTP Interaction

2. File Download and Upload Support

3. Comprehensive Request Configuration

4. Robust Authentication and Security

Basic Usage Examples

Why Choose ararog/uget?

🦀 Reqwest vs. Deboa: Which Rust HTTP Client is Right for Your Project?

🏗️ Core Philosophy and Design

Reqwest: The Feature-Rich Standard

Deboa: The Lightweight and Flexible Contender

⚡ Performance and Binary Size Comparison

📊 Performance Factors

📉 Binary Size

⚠️ Caveat on Performance Benchmarks

🎯 Which Should You Choose?

Choose reqwest if:

Choose deboa if:

Exploring deboa-macros: Ergonomic HTTP Client Macros for Rust

What is deboa-macros?

Why Macros? --- The Case for deboa-macros

Key Features & API Overview

✔ Function-like Macros

✔ #[bora] Attribute Macro

✔ Serialization Formats Supported

Example: GET Request Using get!

Example: Declarative API Client with #[bora]

When to Use deboa-macros

Great Fit When:

Consider Using Raw deboa When:

Ecosystem Fit

My Take

Conclusion

Vamo, a rest api friendly client

Installing

Initializing client

Example

Sending requests

Example

Request trait

Example

Final thoughts

deboa, a simple http client for rust

Features

Adding Deboa to your project

What is `ararog/uget`?

Why Choose `ararog/uget`?

Choose `reqwest` if:

Choose `deboa` if:

What is `deboa-macros`?

Why Macros? --- The Case for `deboa-macros`

✔ `#[bora]` Attribute Macro

Example: GET Request Using `get!`

Example: Declarative API Client with `#[bora]`

When to Use `deboa-macros`

Consider Using Raw `deboa` When: