# 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
### 1. **Pure Axum** (Recommended for simple APIs)
**Best for**: Simple CRUD APIs with < 5 entities, learning Rust web development
```rust
// 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**:
- ✅ Explicit and easy to understand
- ✅ Full control over every handler
- ✅ Minimal abstractions
- ✅ Excellent documentation and ecosystem
- ✅ Easy debugging (see exactly where errors occur)
**Cons**:
- ❌ Repetitive for many entities
- ❌ Manual route registration
- ❌ Manual relationship management
- ❌ No automatic link enrichment
**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
```rust
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**:
- ✅ Auto-generated OpenAPI/Swagger documentation
- ✅ Type-safe route handlers
- ✅ Easy to understand
- ✅ Good ecosystem integration
**Cons**:
- ❌ Still need to write route registration
- ❌ No automatic relationship management
- ❌ No GraphQL support
**When to choose**: REST-only API, need OpenAPI docs, < 10 entities
---
### 3. **async-graphql** (Recommended for GraphQL-only)
**Best for**: GraphQL-first APIs with known types at compile-time
```rust
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**:
- ✅ Native GraphQL support
- ✅ Excellent type inference
- ✅ Subscriptions support
- ✅ Good performance
**Cons**:
- ❌ No REST API
- ❌ Compile-time types only (no dynamic schema)
- ❌ More boilerplate for relationships
**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
```rust
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**:
- ✅ OpenAPI-first approach
- ✅ Automatic route generation from annotations
- ✅ Less boilerplate than pure Axum
**Cons**:
- ❌ Smaller ecosystem than Axum
- ❌ No automatic relationship management
- ❌ No GraphQL support
**When to choose**: OpenAPI-first development, REST-only
---
### 5. **SeaORM / Diesel** (Database-focused)
**Best for**: Database-centric applications with complex queries
```rust
use sea_orm::*;
let users = Users::find()
.find_with_related(Cars)
.all(&db)
.await?;
```
**Pros**:
- ✅ Native database relationships (joins, eager loading)
- ✅ Type-safe queries
- ✅ Migrations
- ✅ Excellent for complex DB operations
**Cons**:
- ❌ No API layer (just ORM)
- ❌ Tightly coupled to database schema
- ❌ No automatic REST/GraphQL generation
**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
| **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**:
- ✅ Full support
- ⚠️ Partial support
- ✍️ Manual implementation required
- ❌ Not supported
---
## 🎯 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)
| **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
| **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
| **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:
- ✅ Keep your existing handlers
- ✅ Keep your entity definitions (wrap with macros)
- ✅ Gradually migrate routes to auto-registration
- ✅ Add GraphQL incrementally
You don't need to rewrite everything!
### Migrating FROM this-rs
If this-rs isn't working for you:
- ✅ Handlers are standard Axum handlers (reusable)
- ✅ Entity types are standard Rust structs (portable)
- ✅ Just remove the framework, keep the business logic
- ⚠️ You'll need to manually implement routing
---
## 🎓 Real-World Recommendations
### Scenario 1: Simple Blog API
- **Entities**: User, Post, Comment (3 entities)
- **Relationships**: Few, simple
- **Recommendation**: **Pure Axum** or **Axum + utoipa**
- **Reasoning**: this-rs adds unnecessary complexity
### Scenario 2: E-commerce Platform
- **Entities**: Product, Category, Order, OrderItem, User, Address, Payment, Review, Cart, Wishlist (10+ entities)
- **Relationships**: Many, complex (many-to-many)
- **Recommendation**: **this-rs**
- **Reasoning**: Significant routing boilerplate, many relationships
### Scenario 3: Social Network
- **Entities**: User, Post, Comment, Like, Follow, Message, Group, Event (8+ entities)
- **Relationships**: Complex, bidirectional
- **Recommendation**: **this-rs**
- **Reasoning**: Bidirectional navigation, link enrichment valuable
### Scenario 4: GraphQL-only Admin Dashboard
- **Entities**: Known at compile-time
- **Relationships**: Simple
- **Recommendation**: **async-graphql**
- **Reasoning**: No REST needed, compile-time types preferred
### Scenario 5: Reporting/Analytics API
- **Entities**: Few, complex queries
- **Relationships**: Mainly database-level
- **Recommendation**: **SeaORM + Axum**
- **Reasoning**: Focus on DB queries, not API routing
---
## 🏆 Final Recommendations
### Use this-rs if:
- ✅ 5+ entities with CRUD
- ✅ Many relationships (especially many-to-many)
- ✅ Need bidirectional navigation
- ✅ Want both REST and GraphQL
- ✅ Microservices with similar patterns
### Use Pure Axum if:
- ✅ < 5 entities
- ✅ Few/simple relationships
- ✅ Learning Rust web development
- ✅ Need maximum control
- ✅ Performance is critical
### Use Axum + utoipa if:
- ✅ REST-only
- ✅ Need OpenAPI documentation
- ✅ Want explicit routing
### Use async-graphql if:
- ✅ GraphQL-only
- ✅ Types known at compile-time
- ✅ Need subscriptions
### Use SeaORM if:
- ✅ Database-centric
- ✅ Complex SQL queries
- ✅ Focus on data layer
---
## 💬 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?
- 📖 Read the main [README](../README.md#is-this-rs-right-for-you)
- 💬 Ask in [GitHub Discussions](https://github.com/triviere/this-rs/discussions)
- 🐛 Check [GitHub Issues](https://github.com/triviere/this-rs/issues) for common questions
- 📧 Contact maintainers
**We're happy to help you choose the right tool, even if it's not this-rs!** 🎯
---
<p align="center">
Made with ❤️ and honesty by the this-rs community
</p>