this

Alternatives to this-rs

Honest comparison: When to use this-rs vs other solutions

This document provides an honest comparison of this-rs with alternative approaches. We believe in helping you choose the right tool for your specific use case, even if that means recommending something else.

🎯 Quick Decision Tree

How many entities in your API?
├─ 1-3 entities
│  └─ Few/no relationships → ✅ Use Axum + utoipa directly
│
├─ 3-5 entities
│  ├─ Few relationships → ⚠️ Probably use Axum directly
│  └─ Many relationships → 🤔 Consider this-rs
│
└─ 5+ entities
   ├─ Few relationships → ⚠️ Consider this-rs (marginal benefit)
   └─ Many relationships → ✅✅ this-rs is a great fit

🔄 Alternative Solutions

Best for: Simple CRUD APIs with < 5 entities, learning Rust web development

// Pure Axum example
use axum::{Router, routing::{get, post}};

let app = Router::new()
    .route("/users", get(list_users).post(create_user))
    .route("/users/:id", get(get_user).put(update_user))
    .with_state(state);

Pros:

Cons:

When to choose: < 5 entities, simple relationships, or learning Rust/Axum

2. Axum + utoipa (Recommended for REST APIs)

Best for: REST APIs with OpenAPI documentation needs

use utoipa::OpenApi;
use utoipa_axum::{router::OpenApiRouter, routes};

#[derive(OpenApi)]
#[openapi(paths(list_users, create_user))]
struct ApiDoc;

let (router, api) = OpenApiRouter::with_openapi(ApiDoc::openapi())
    .routes(routes!(list_users))
    .routes(routes!(create_user))
    .split_for_parts();

Pros:

Cons:

When to choose: REST-only API, need OpenAPI docs, < 10 entities

Best for: GraphQL-first APIs with known types at compile-time

use async_graphql::{Object, Schema};

struct QueryRoot;

#[Object]
impl QueryRoot {
    async fn user(&self, id: ID) -> User {
        // Implementation
    }
}

let schema = Schema::new(QueryRoot, MutationRoot, SubscriptionRoot);

Pros:

Cons:

When to choose: GraphQL-only, types known at compile-time

vs this-rs: this-rs generates GraphQL schema dynamically from entity definitions, allowing runtime schema changes. Use async-graphql if you prefer compile-time types and don’t need REST.

4. Poem + poem-openapi (Alternative to Axum)

Best for: OpenAPI-first development with automatic route generation

use poem_openapi::{OpenApi, payload::Json};

struct Api;

#[OpenApi]
impl Api {
    #[oai(path = "/users", method = "get")]
    async fn list_users(&self) -> Json<Vec<User>> {
        // Implementation
    }
}

Pros:

Cons:

When to choose: OpenAPI-first development, REST-only

5. SeaORM / Diesel (Database-focused)

Best for: Database-centric applications with complex queries

use sea_orm::*;

let users = Users::find()
    .find_with_related(Cars)
    .all(&db)
    .await?;

Pros:

Cons:

When to choose: Database-heavy application, complex SQL queries

vs this-rs: this-rs focuses on API layer (routing, links, multi-protocol). You can combine SeaORM with this-rs: use SeaORM for data access, this-rs for API exposure.

📊 Feature Comparison Matrix

Feature this-rs Pure Axum Axum + utoipa async-graphql Poem-openapi SeaORM
REST API ✅ Auto ✍️ Manual ✍️ Manual ❌ ✅ Auto ❌
GraphQL API ✅ Auto ❌ ❌ ✅ Manual ❌ ❌
Multi-protocol ✅ ❌ ❌ ❌ ❌ ❌
Auto-routing ✅ ❌ ⚠️ Partial ⚠️ Partial ✅ ❌
Link management ✅ ❌ ❌ ❌ ❌ ✅ (DB)
Link enrichment ✅ ❌ ❌ ❌ ❌ ⚠️ Eager load
Bidirectional nav ✅ ❌ ❌ ❌ ❌ ⚠️ Relations
Dynamic schema ✅ ❌ ⚠️ OpenAPI ❌ ⚠️ OpenAPI ❌
OpenAPI docs ⚠️ Possible ⚠️ Manual ✅ Auto ❌ ✅ Auto ❌
Learning curve Medium Low Low-Med Medium Medium Medium-High
Ecosystem size Small Large Large Medium Small Large
Explicitness Medium High High Medium Medium High
Best for entities 5+ Any Any Any Any Any

Legend:

🎯 When to Use this-rs

✅ this-rs is the Best Choice

  1. Many entities with complex relationships
    • 10+ entities with many-to-many relationships
    • Need bidirectional navigation
    • Example: CMS, ERP, e-commerce platform
  2. Multi-protocol requirements
    • Need both REST and GraphQL
    • Same entities exposed via both protocols
    • Example: Public API (REST) + admin dashboard (GraphQL)
  3. Rapidly evolving domain
    • Adding entities frequently
    • Need consistency across entities
    • Example: Startup with changing requirements
  4. Microservices with shared patterns
    • Multiple microservices with similar structure
    • Want consistent routing across services
    • Example: Microservices architecture with entity-based services

⚠️ this-rs Might Be Overkill

  1. Simple CRUD API
    • 1-5 entities with basic operations
    • Few/no relationships
    • Use Axum or Axum + utoipa
  2. GraphQL-only with static types
    • Don’t need REST
    • Types known at compile-time
    • Use async-graphql
  3. Database-centric with complex queries
    • Heavy SQL/query logic
    • Less focus on API routing
    • Use SeaORM/Diesel + minimal Axum
  4. Learning Rust web development
    • First Rust web project
    • Want to understand fundamentals
    • Start with pure Axum, add this-rs later if needed

💰 Cost-Benefit Analysis

For a 3-Entity API (e.g., User, Post, Comment)

Approach Lines of Code Dev Time Maintenance Learning
Pure Axum ~300 lines 2-3 hours Easy Low
this-rs ~350 lines 4-5 hours Medium Medium

Verdict: Pure Axum wins for small APIs

For a 10-Entity API with 15 Relationships

Approach Lines of Code Dev Time Maintenance Learning
Pure Axum ~2000 lines 20 hours Hard (repetitive) Low
this-rs ~400 lines 10 hours Easy (consistent) Medium

Verdict: this-rs provides significant value

For a 20-Entity Microservices Architecture

Approach Lines of Code Dev Time Maintenance Learning
Pure Axum ~5000 lines 50+ hours Very hard Low
this-rs ~800 lines 20 hours Easy Medium

Verdict: this-rs is highly recommended

🔄 Migration Paths

Starting Simple → Scaling Later

Recommended approach:

  1. Start with pure Axum (1-3 entities)
    • Learn Rust web fundamentals
    • Understand your domain
  2. Add helpers as needed (3-5 entities)
    • Create your own macros for repetitive code
    • Add utoipa for OpenAPI docs
  3. Consider this-rs (5+ entities)
    • When relationships become complex
    • When boilerplate becomes painful
    • When you need multi-protocol support

Migrating TO this-rs

this-rs is designed to complement existing code:

You don’t need to rewrite everything!

Migrating FROM this-rs

If this-rs isn’t working for you:

🎓 Real-World Recommendations

Scenario 1: Simple Blog API

Scenario 2: E-commerce Platform

Scenario 3: Social Network

Scenario 4: GraphQL-only Admin Dashboard

Scenario 5: Reporting/Analytics API

🏆 Final Recommendations

Use this-rs if:

Use Pure Axum if:

Use Axum + utoipa if:

Use async-graphql if:

Use SeaORM if:

💬 Questions to Ask Yourself

Before choosing this-rs, ask:

  1. How many entities will I have?
    • < 5 → Consider alternatives
    • 5-10 → this-rs could help
    • 10+ → this-rs highly recommended
  2. How many relationships?
    • Few/simple → Consider alternatives
    • Many/complex → this-rs helps a lot
  3. Do I need both REST and GraphQL?
    • Yes → this-rs is great
    • No → Consider specialized tools
  4. Am I learning Rust?
    • Yes → Start with Axum
    • No → this-rs is fine
  5. Is my domain rapidly changing?
    • Yes → this-rs consistency helps
    • No → Less critical

📞 Still Not Sure?

We’re happy to help you choose the right tool, even if it’s not this-rs! 🎯

Made with ❤️ and honesty by the this-rs community

This site is open source. Improve this page.