Porting a Node.js Service to Rust

18 min read

Migrating a working Node.js service to Rust is not a rewrite-from-the-spec exercise — it is a careful translation where the observable behavior stays identical while the implementation changes underneath. This page walks one Express endpoint over to Axum, byte-for-byte on the wire, so you can see exactly what changes and what does not.

Quick Overview

The goal of a service migration is that clients cannot tell the difference: the same routes return the same JSON bodies, the same status codes, and the same headers. Rust changes how you write the handler — explicit types, ownership, Result-based errors instead of thrown exceptions — but the contract your existing TypeScript/JavaScript callers depend on must not move. This walkthrough takes a small Express user service and reproduces it in Axum, verifying the responses match at every step.

The current stable toolchain is Rust 1.96.0 on the 2024 edition; cargo new selects it automatically. The examples here use Axum 0.8, Tokio 1.52, and Serde 1.

TypeScript/JavaScript Example

Here is a realistic Express service: a couple of read endpoints over an in-memory user store, with a query parameter and a not-found case.

1
// server.ts — Express 4, the service we are migrating
2
import express from "express";
3

4
interface User {
5
  id: number;
6
  name: string;
7
  email: string;
8
}
9

10
const users = new Map<number, User>([
11
  [1, { id: 1, name: "Ada", email: "ada@example.com" }],
12
  [2, { id: 2, name: "Linus", email: "linus@example.com" }],
13
]);
14

15
const app = express();
16

17
// GET /users?limit=10
18
app.get("/users", (req, res) => {
19
  const limit = Number(req.query.limit ?? 10);
20
  const list = [...users.values()]
21
    .sort((a, b) => a.id - b.id)
22
    .slice(0, limit);
23
  res.json(list);
24
});
25

26
// GET /users/:id
27
app.get("/users/:id", (req, res) => {
28
  const id = Number(req.params.id);
29
  const user = users.get(id);
30
  if (!user) {
31
    return res.status(404).json({ error: "User not found" });
32
  }
33
  res.json(user);
34
});
35

36
app.listen(3001, () => console.log("listening on 3001"));

Running it against curl (Express 4.22, Node v22) gives the baseline we must reproduce:

1
GET /users/1        -> 200 {"id":1,"name":"Ada","email":"ada@example.com"}
2
GET /users/99       -> 404 {"error":"User not found"}
3
GET /users?limit=1  -> 200 [{"id":1,"name":"Ada","email":"ada@example.com"}]
4
GET /users/abc      -> 404 {"error":"User not found"}

That last line is important and easy to miss: Number("abc") is NaN, users.get(NaN) is undefined, so Express falls through to the 404 branch. Keep that case in mind — it is where the naive Rust port will diverge.

Rust Equivalent

The same service in Axum. Add the dependencies first:

1
cargo add axum
2
cargo add tokio --features full
3
cargo add serde --features derive
4
cargo add serde_json

1
use std::collections::HashMap;
2
use std::sync::Arc;
3

4
use axum::{
5
    Json, Router,
6
    extract::{Path, Query, State},
7
    http::StatusCode,
8
    response::{IntoResponse, Response},
9
    routing::get,
10
};
11
use serde::{Deserialize, Serialize};
12
use serde_json::json;
13

14
#[derive(Clone, Serialize)]
15
struct User {
16
    id: u32,
17
    name: String,
18
    email: String,
19
}
20

21
#[derive(Clone)]
22
struct AppState {
23
    users: Arc<HashMap<u32, User>>,
24
}
25

26
#[derive(Deserialize)]
27
struct ListParams {
28
    limit: Option<usize>,
29
}
30

31
// GET /users?limit=10
32
async fn list_users(
33
    State(state): State<AppState>,
34
    Query(params): Query<ListParams>,
35
) -> Json<Vec<User>> {
36
    let limit = params.limit.unwrap_or(10);
37
    let mut users: Vec<User> = state.users.values().cloned().collect();
38
    users.sort_by_key(|u| u.id);
39
    users.truncate(limit);
40
    Json(users)
41
}
42

43
// GET /users/{id}
44
async fn get_user(State(state): State<AppState>, Path(id): Path<u32>) -> Response {
45
    match state.users.get(&id) {
46
        Some(user) => Json(user.clone()).into_response(),
47
        None => (
48
            StatusCode::NOT_FOUND,
49
            Json(json!({ "error": "User not found" })),
50
        )
51
            .into_response(),
52
    }
53
}
54

55
fn seed() -> HashMap<u32, User> {
56
    let mut m = HashMap::new();
57
    m.insert(1, User { id: 1, name: "Ada".into(), email: "ada@example.com".into() });
58
    m.insert(2, User { id: 2, name: "Linus".into(), email: "linus@example.com".into() });
59
    m
60
}
61

62
fn app() -> Router {
63
    let state = AppState { users: Arc::new(seed()) };
64
    Router::new()
65
        .route("/users", get(list_users))
66
        .route("/users/{id}", get(get_user))
67
        .with_state(state)
68
}
69

70
#[tokio::main]
71
async fn main() {
72
    let listener = tokio::net::TcpListener::bind("127.0.0.1:3000")
73
        .await
74
        .unwrap();
75
    println!("listening on {}", listener.local_addr().unwrap());
76
    axum::serve(listener, app()).await.unwrap();
77
}

Running the same probes against this server produces:

1
GET /users/1        -> 200 {"id":1,"name":"Ada","email":"ada@example.com"}
2
GET /users/99       -> 404 {"error":"User not found"}
3
GET /users?limit=1  -> 200 [{"id":1,"name":"Ada","email":"ada@example.com"}]
4
GET /users/abc      -> 400 Invalid URL: Cannot parse `abc` to a `u32`

Three of the four match exactly. The fourth does not — and that gap is the whole lesson of a careful port. We will fix it in Detailed Explanation.

Detailed Explanation

Walking the Rust version line by line and contrasting with the Express original:

State instead of a module-level const. In Express, users is a Map captured by the route closures via JavaScript’s lexical scope — a shared mutable global that “just works” because Node runs your handlers on a single thread. Rust has no implicit shared global. State is threaded explicitly through Router::with_state and pulled into each handler with the State extractor. The store is wrapped in Arc (an atomically reference-counted pointer) so every concurrent request can share one read-only copy cheaply. This is not bureaucracy: Axum runs handlers across a multi-threaded Tokio runtime, and the Arc is what makes that sound. See state management and reference counting.

The query parameter is a typed struct, not req.query. Express hands you req.query.limit as string | undefined and you coerce it with Number(...). Axum’s Query<ListParams> extractor deserializes the query string into a typed struct via Serde. limit: Option<usize> models “may be absent” exactly like ??; params.limit.unwrap_or(10) is the direct analogue of req.query.limit ?? 10. See extractors.

Returning data is Json(value), not res.json(value). Express mutates a response object imperatively (res.status(404).json(...)). Axum handlers return a value that implements IntoResponse. Json(users) serializes the Vec<User> to a JSON array with content-type: application/json — the same wire output as res.json([...]). Returning a tuple (StatusCode, Json(...)) sets the status and body together. See JSON APIs.

No thrown exceptions; errors are values. The not-found path returns a 404 response value rather than throwing. Rust handlers can return Result, and the error type’s IntoResponse decides the status — there is no throw that unwinds to a framework error handler. This is the single biggest mental shift; see error handling and web error handling.

The route path uses {id}, not :id. Axum 0.8 changed path syntax from the colon form to braces. A route written /users/:id will not match the way you expect on current Axum — use /users/{id}. See routing.

Closing the behavior gap on `/users/abc`

The naive port returns 400 for /users/abc because Path<u32> tries to parse the segment into a u32 before your handler runs, and a non-numeric segment fails extraction. Express, by contrast, accepts any string segment and only later turns it into NaN, landing on 404.

If your clients (or your contract tests) depend on the 404 behavior, extract the segment as a String and parse it yourself, falling through to the same not-found branch:

1
use std::collections::HashMap;
2
use std::sync::Arc;
3

4
use axum::{
5
    Json,
6
    extract::{Path, State},
7
    http::StatusCode,
8
    response::{IntoResponse, Response},
9
};
10
use serde::Serialize;
11
use serde_json::json;
12

13
#[derive(Clone, Serialize)]
14
struct User { id: u32, name: String, email: String }
15

16
#[derive(Clone)]
17
struct AppState { users: Arc<HashMap<u32, User>> }
18

19
// Path<String>: a non-numeric id won't 400 at the extractor.
20
// We parse it ourselves and fall through to 404, matching Express.
21
async fn get_user(State(state): State<AppState>, Path(id): Path<String>) -> Response {
22
    let user = id.parse::<u32>().ok().and_then(|n| state.users.get(&n));
23
    match user {
24
        Some(u) => Json(u.clone()).into_response(),
25
        None => (
26
            StatusCode::NOT_FOUND,
27
            Json(json!({ "error": "User not found" })),
28
        )
29
            .into_response(),
30
    }
31
}

With this handler the probe now matches the Node baseline exactly:

1
GET /users/abc -> 404 {"error":"User not found"}
2
GET /users/1   -> 200 {"id":1,"name":"Ada","email":"ada@example.com"}

Note: Whether 400 or 404 is “more correct” is a real design question — a 400 is arguably better. But during a migration, correctness is defined by the existing contract, not by your taste. Change behavior in a separate, deliberate release, never silently as a side effect of the port. Matching shapes, codes, and headers is covered in depth in api-compatibility.md.

Key Differences

Concern	Express (Node v22)	Axum 0.8 (Rust)
Shared state	Lexically-captured global `Map`	`Arc<...>` in `State`, threaded explicitly
Handler shape	Mutate `res`, no return value	Return a value implementing `IntoResponse`
Path param	`req.params.id` is always a `string`	`Path<u32>` parses + 400s on failure; `Path<String>` to opt out
Query param	`req.query.x`, `string \| undefined`	`Query<T>` deserialized via Serde, typed
Errors	`throw` / `res.status(...).json(...)`	`Result<T, E>` where `E: IntoResponse`
JSON keys	Whatever you name the object fields	Struct field names; `#[serde(rename_all = ...)]` to remap
Concurrency model	Single-threaded event loop	Multi-threaded runtime; sharing must be `Send + Sync`
Route syntax	`/users/:id`	`/users/{id}`
Startup	`app.listen(port)`	`axum::serve(TcpListener, app)`

The deepest difference is the concurrency model. Node’s single-threaded event loop means your handler code never runs truly in parallel, so a plain shared Map is safe by accident. Axum spreads handlers across OS threads, so the compiler requires that shared state be safe to touch from many threads at once (Send + Sync). The Arc (and, when you need writes, an RwLock or Mutex inside it) is the price — and the guarantee — of that parallelism. This is “fearless concurrency”: parallel by opt-in, with data races rejected at compile time rather than discovered in production.

Warning: Do not describe Rust as “multi-threaded by default” to yourself as a Node dev — the distinction is that Rust lets you be parallel safely. Your Axum service is parallel because the Tokio runtime is, and the type system makes that safe.

Common Pitfalls

Pitfall 1: Mismatched response types across `match` arms

In JavaScript a handler can res.json(...) an object on one branch and a different object on another with no ceremony — there is no static return type. In Rust every branch of a match must produce the same type. This trips up new arrivals constantly:

1
use axum::{Json, http::StatusCode, response::Response};
2
use serde_json::json;
3

4
// does not compile (error[E0308]: mismatched types)
5
async fn get_user(found: bool) -> Response {
6
    match found {
7
        true => Json(json!({ "id": 1 })),
8
        false => (StatusCode::NOT_FOUND, Json(json!({ "error": "nope" }))),
9
    }
10
}
11

12
fn main() {}

The real compiler error:

1
error[E0308]: mismatched types
2
 --> src/bin/pitfall.rs:7:17
3
  |
4
5 | async fn get_user(found: bool) -> Response {
5
  |                                   -------- expected `Response<Body>` because of return type
6
6 |     match found {
7
7 |         true => Json(json!({ "id": 1 })),
8
  |                 ^^^^^^^^^^^^^^^^^^^^^^^^ expected `Response<Body>`, found `Json<Value>`
9
  |
10
  = note: expected struct `Response<Body>`
11
             found struct `Json<Value>`

The fix is to call .into_response() on every arm so each yields a Response, exactly as the worked example does. The type system is enforcing what an Express handler only hopes for: that both branches actually produce a valid HTTP response.

Pitfall 2: JSON key casing changes silently

JavaScript objects carry whatever keys you wrote, typically camelCase. Rust structs are conventionally snake_case, and Serde serializes field names verbatim by default — so the JSON shape moves the moment you port a fullName field to full_name. This is a contract break that no test catches unless you check the actual bytes:

1
use serde::Serialize;
2

3
#[derive(Serialize)]
4
struct UserSnake {
5
    id: u32,
6
    full_name: String,
7
    created_at: String,
8
}
9

10
#[derive(Serialize)]
11
#[serde(rename_all = "camelCase")]
12
struct UserCamel {
13
    id: u32,
14
    full_name: String,
15
    created_at: String,
16
}
17

18
fn main() {
19
    let snake = UserSnake { id: 1, full_name: "Ada".into(), created_at: "2026-06-02".into() };
20
    let camel = UserCamel { id: 1, full_name: "Ada".into(), created_at: "2026-06-02".into() };
21
    println!("default:  {}", serde_json::to_string(&snake).unwrap());
22
    println!("camelCase: {}", serde_json::to_string(&camel).unwrap());
23
}

Real output:

1
default:  {"id":1,"full_name":"Ada","created_at":"2026-06-02"}
2
camelCase: {"id":1,"fullName":"Ada","createdAt":"2026-06-02"}

If your Node service emitted fullName, add #[serde(rename_all = "camelCase")] to keep the wire shape. This and other shape-matching details live in api-compatibility.md and serde attributes.

Pitfall 3: Assuming the extractor never rejects

Path<u32>, Query<T>, and Json<T> all reject malformed input before your code runs, returning a 400 with a plain-text body that almost certainly differs from what your Node service returned. A malformed JSON POST body, for example, yields:

1
Failed to parse the request body as JSON: key must be a string at line 1 column 2

That is not the {"error": "..."} envelope your clients expect. If you need a custom error body for malformed input, use a custom rejection or a validation extractor — covered in validation and web error handling. The point during migration: enumerate the failure modes your Node service produced, then verify each one against the Rust service, not just the happy path.

Pitfall 4: Forgetting that futures are lazy

A JavaScript Promise starts running the moment it is created. A Rust async fn returns a future that does nothing until it is awaited by a runtime — the opposite of an eager Promise. Calling an async helper and discarding the future runs no code at all. Inside an Axum handler the runtime drives your future for you, but when you write helper functions, remember to .await them. See promises vs futures.

Best Practices

Pin the contract with tests before you port. Capture the Node service’s real responses (status, body, key casing, headers) for representative requests and turn them into assertions. Run them against the Rust service until green. The migration is “done” when those byte-level tests pass, not when the code compiles.
Port one endpoint at a time, behind the existing service. Stand the Rust service up next to Node and route a single path to it (a reverse-proxy split, or the strangler-fig pattern). Verify, then move the next path. The mechanics are in incremental.md.
Make the error envelope a single type. Define one ApiError enum that implements IntoResponse and maps each variant to the exact status + JSON your clients expect. Every handler returns Result<T, ApiError>, so the response shape is centralized and impossible to drift.
Use #[serde(rename_all = "camelCase")] proactively on any DTO whose JSON crosses the wire to existing clients, so a snake_case Rust field never changes a key.
Keep handlers thin; share read-only state via Arc. Reach for Arc<RwLock<T>> or a real database only where you genuinely mutate; an Arc<T> is enough for read-only config and caches.
Diff the headers, not just the body. content-type, caching headers, and CORS are part of the contract. See CORS and api-compatibility.md.

Real-World Example

A fuller slice of a production service: a read endpoint and a POST that validates input, allocates an id, and returns 201 Created — all funneling errors through one ApiError type so every response matches the Node envelope. The store uses Arc<RwLock<...>> because this version mutates.

1
use std::collections::HashMap;
2
use std::sync::{Arc, RwLock};
3

4
use axum::{
5
    Json, Router,
6
    extract::{Path, State},
7
    http::StatusCode,
8
    response::{IntoResponse, Response},
9
    routing::get,
10
};
11
use serde::{Deserialize, Serialize};
12
use serde_json::json;
13

14
#[derive(Clone, Serialize)]
15
struct User {
16
    id: u32,
17
    name: String,
18
    email: String,
19
}
20

21
#[derive(Deserialize)]
22
struct CreateUser {
23
    name: String,
24
    email: String,
25
}
26

27
#[derive(Clone)]
28
struct AppState {
29
    users: Arc<RwLock<HashMap<u32, User>>>,
30
    next_id: Arc<RwLock<u32>>,
31
}
32

33
// One error type, mapped to the same JSON envelope the Node service returned.
34
enum ApiError {
35
    NotFound,
36
    Validation(String),
37
}
38

39
impl IntoResponse for ApiError {
40
    fn into_response(self) -> Response {
41
        let (status, msg) = match self {
42
            ApiError::NotFound => (StatusCode::NOT_FOUND, "User not found".to_string()),
43
            ApiError::Validation(m) => (StatusCode::BAD_REQUEST, m),
44
        };
45
        (status, Json(json!({ "error": msg }))).into_response()
46
    }
47
}
48

49
async fn get_user(
50
    State(state): State<AppState>,
51
    Path(id): Path<u32>,
52
) -> Result<Json<User>, ApiError> {
53
    state
54
        .users
55
        .read()
56
        .unwrap()
57
        .get(&id)
58
        .cloned()
59
        .map(Json)
60
        .ok_or(ApiError::NotFound)
61
}
62

63
async fn create_user(
64
    State(state): State<AppState>,
65
    Json(body): Json<CreateUser>,
66
) -> Result<(StatusCode, Json<User>), ApiError> {
67
    if body.name.trim().is_empty() {
68
        return Err(ApiError::Validation("name is required".into()));
69
    }
70
    if !body.email.contains('@') {
71
        return Err(ApiError::Validation("email is invalid".into()));
72
    }
73
    let mut id_guard = state.next_id.write().unwrap();
74
    let id = *id_guard;
75
    *id_guard += 1;
76
    let user = User { id, name: body.name, email: body.email };
77
    state.users.write().unwrap().insert(id, user.clone());
78
    Ok((StatusCode::CREATED, Json(user)))
79
}
80

81
#[tokio::main]
82
async fn main() {
83
    let state = AppState {
84
        users: Arc::new(RwLock::new(HashMap::new())),
85
        next_id: Arc::new(RwLock::new(1)),
86
    };
87
    let app = Router::new()
88
        .route("/users", get(|| async { "ok" }).post(create_user))
89
        .route("/users/{id}", get(get_user))
90
        .with_state(state);
91
    let listener = tokio::net::TcpListener::bind("127.0.0.1:3003")
92
        .await
93
        .unwrap();
94
    axum::serve(listener, app).await.unwrap();
95
}

Probing it confirms the validation, the 201, and the error envelope:

1
POST /users {"name":"Grace","email":"grace@example.com"} -> 201 {"id":1,"name":"Grace","email":"grace@example.com"}
2
POST /users {"name":"Grace","email":"nope"}              -> 400 {"error":"email is invalid"}
3
GET  /users/1                                            -> 200 {"id":1,"name":"Grace","email":"grace@example.com"}
4
POST /users {bad}                                        -> 400 Failed to parse the request body as JSON: ...

Note the last line: malformed JSON is rejected by the Json extractor before create_user runs, so it bypasses your ApiError envelope. If your contract requires a JSON error body for malformed input too, wrap the body in a custom extractor — see validation. In real services this state would be a database pool rather than an in-memory map; see connection pooling and sqlx, and data-migration.md for moving the data itself.

Exercises

Exercise 1: Add a `DELETE` endpoint that matches Node

Difficulty: Beginner

Objective: Reproduce an idempotent delete that returns 204 No Content whether or not the user existed — the behavior of a typical Express res.status(204).end() handler.

Instructions: Starting from the real-world example, add DELETE /users/{id}. Remove the user from the store if present, and return 204 in both cases (present and absent). Verify with curl -i that the status is 204 and the body is empty for an existing id, a missing id, and a repeated delete.

Solution

1
use std::collections::HashMap;
2
use std::sync::{Arc, RwLock};
3

4
use axum::{
5
    Router,
6
    extract::{Path, State},
7
    http::StatusCode,
8
    routing::delete,
9
};
10
use serde::Serialize;
11

12
#[derive(Clone, Serialize)]
13
struct User { id: u32, name: String, email: String }
14

15
#[derive(Clone)]
16
struct AppState { users: Arc<RwLock<HashMap<u32, User>>> }
17

18
// Idempotent: 204 whether or not the user was there, like res.status(204).end().
19
async fn delete_user(State(state): State<AppState>, Path(id): Path<u32>) -> StatusCode {
20
    state.users.write().unwrap().remove(&id);
21
    StatusCode::NO_CONTENT
22
}
23

24
fn seed() -> HashMap<u32, User> {
25
    let mut m = HashMap::new();
26
    m.insert(1, User { id: 1, name: "Ada".into(), email: "ada@example.com".into() });
27
    m
28
}
29

30
#[tokio::main]
31
async fn main() {
32
    let state = AppState { users: Arc::new(RwLock::new(seed())) };
33
    let app = Router::new()
34
        .route("/users/{id}", delete(delete_user))
35
        .with_state(state);
36
    let listener = tokio::net::TcpListener::bind("127.0.0.1:3004").await.unwrap();
37
    axum::serve(listener, app).await.unwrap();
38
}

Returning a bare StatusCode produces an empty body, which is what 204 requires. curl -i on an existing id, a missing id, and a repeated delete all show HTTP/1.1 204 No Content with no body.

Exercise 2: Match Express’s lenient `:id` parsing

Difficulty: Intermediate

Objective: Make GET /users/{id} return 404 (not 400) for a non-numeric id, reproducing the Node behavior, without losing the 200/404 paths for valid numeric ids.

Instructions: Change the handler so a request to /users/abc yields 404 {"error":"User not found"} while /users/1 and /users/99 keep returning 200 and 404 respectively. Explain in a comment why Path<u32> could not do this.

Solution

1
use std::collections::HashMap;
2
use std::sync::Arc;
3

4
use axum::{
5
    Json, Router,
6
    extract::{Path, State},
7
    http::StatusCode,
8
    response::{IntoResponse, Response},
9
    routing::get,
10
};
11
use serde::Serialize;
12
use serde_json::json;
13

14
#[derive(Clone, Serialize)]
15
struct User { id: u32, name: String, email: String }
16

17
#[derive(Clone)]
18
struct AppState { users: Arc<HashMap<u32, User>> }
19

20
// Path<u32> would reject "abc" with a 400 *before this runs*. Taking the
21
// segment as a String lets us parse it ourselves and fall through to 404,
22
// exactly like Number("abc") -> NaN -> Map.get(NaN) -> undefined in Express.
23
async fn get_user(State(state): State<AppState>, Path(id): Path<String>) -> Response {
24
    let user = id.parse::<u32>().ok().and_then(|n| state.users.get(&n));
25
    match user {
26
        Some(u) => Json(u.clone()).into_response(),
27
        None => (
28
            StatusCode::NOT_FOUND,
29
            Json(json!({ "error": "User not found" })),
30
        )
31
            .into_response(),
32
    }
33
}
34

35
fn seed() -> HashMap<u32, User> {
36
    let mut m = HashMap::new();
37
    m.insert(1, User { id: 1, name: "Ada".into(), email: "ada@example.com".into() });
38
    m
39
}
40

41
#[tokio::main]
42
async fn main() {
43
    let state = AppState { users: Arc::new(seed()) };
44
    let app = Router::new()
45
        .route("/users/{id}", get(get_user))
46
        .with_state(state);
47
    let listener = tokio::net::TcpListener::bind("127.0.0.1:3005").await.unwrap();
48
    axum::serve(listener, app).await.unwrap();
49
}

/users/abc now returns 404 {"error":"User not found"}; /users/1 returns 200; /users/99 returns 404. The key insight: typed extractors reject bad input at the boundary, so to opt into lenient parsing you must extract the raw String and parse inside the handler.

Exercise 3: Centralize the error envelope and reject mismatched casing in a test

Difficulty: Advanced

Objective: Prove the migrated service preserves the JSON contract by asserting on the exact serialized bytes, and catch a casing regression.

Instructions: Suppose the Node service emitted {"id":1,"fullName":"Ada","createdAt":"..."}. Define a User DTO whose Rust fields are id, full_name, created_at, serialize it, and write a #[test] (or a main with assert_eq!) that fails unless the output keys are camelCase. Then make it pass with the right Serde attribute.

Solution

1
use serde::Serialize;
2

3
#[derive(Serialize)]
4
#[serde(rename_all = "camelCase")]
5
struct User {
6
    id: u32,
7
    full_name: String,
8
    created_at: String,
9
}
10

11
fn main() {
12
    let user = User {
13
        id: 1,
14
        full_name: "Ada".into(),
15
        created_at: "2026-06-02".into(),
16
    };
17
    let json = serde_json::to_string(&user).unwrap();
18
    // The contract from the Node service uses camelCase keys.
19
    assert_eq!(json, r#"{"id":1,"fullName":"Ada","createdAt":"2026-06-02"}"#);
20
    println!("contract held: {json}");
21
}

Output:

1
contract held: {"id":1,"fullName":"Ada","createdAt":"2026-06-02"}

Remove the #[serde(rename_all = "camelCase")] line and the same assert_eq! fails, because Serde would emit full_name/created_at. Byte-level assertions like this are what turn “looks the same” into “is provably the same” during a migration. For richer field control, see serde attributes and custom serialization.

Porting a Node.js Service to Rust

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

Closing the behavior gap on /users/abc

Key Differences

Common Pitfalls

Pitfall 1: Mismatched response types across match arms

Pitfall 2: JSON key casing changes silently

Pitfall 3: Assuming the extractor never rejects

Pitfall 4: Forgetting that futures are lazy

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: Add a DELETE endpoint that matches Node

Exercise 2: Match Express’s lenient :id parsing

Exercise 3: Centralize the error envelope and reject mismatched casing in a test

Closing the behavior gap on `/users/abc`

Pitfall 1: Mismatched response types across `match` arms

Exercise 1: Add a `DELETE` endpoint that matches Node

Exercise 2: Match Express’s lenient `:id` parsing