Skip to content
ESEN
Contact

Technology · APIs in Rust

APIs and backends in Rust with Axum

Axum is the framework used in Rust to build APIs and web services. Every request is turned into data of a known shape before it touches your logic; what does not fit is rejected at the door. We build new backends with Axum and move to Rust the service that is falling short today.

Tell us about your project See an example

Often combined with

Fig. 01Tower of layersACCESS · LIMIT · SHAPE · ROUTEliveSHAPELIMIT422ACCESS429401/orders/customers/stockLooping
The request comes down step by step, access, limit and shape, and only if it passes them does it reach the router that takes it to its handler. The one that does not fit leaves by the side, toward the sign with its answer.

Situations

What you can solve with an Axum backend

A Rust backend pays off when the service is critical: it gets a lot of traffic, runs on a modest machine, or an error in it costs money.

  • A service that has nothing left to give

    The API responds slowly at peaks or needs more and more servers. In Rust, the same service usually handles more requests with less machine.

  • Malformed data that gets all the way in

    A field that is missing or arrives as another type causes errors halfway through the process. Here the request is checked whole on the way in and the logic only receives valid data.

  • A server inside the application itself

    A desktop app or a machine on the shop floor that has to offer an API to other programs on the local network, without installing anything else.

  • A service that has to last for years

    Code that is rarely touched and cannot break when it is. The compiler points out every place affected by a change before it is published.

The template: a request without the expected shape does not pass

What to check before starting

  • Which requests the service receives today and which are the critical ones
  • Who consumes it: a website, an app, other systems
  • Which database and which external services it uses
  • What must stay the same for whoever already calls it

Services

What we build with Axum

Four kinds of job. The most frequent is the third: a single service that moves to Rust while the rest stays where it is.

  • Module 1 · Router

    New APIs and backends

    Routes, input and output data with a declared shape, database access and API documentation generated from the code itself.

    Examples of deliverables

    • API for an app or a portal
    • Internal service between systems
    • API documentation kept current
  • Module 2 · Layers

    Access, limits and logging

    What every request goes through before reaching the logic: who is calling, how many times they may do so, what gets recorded and what gets measured.

    Examples of deliverables

    • Access by token or by session
    • Request limit per client
    • Traces for every request
  • Module 3 · Handlers

    Moving a critical service to Rust

    The service that is in Node.js or Python today and is falling short, rewritten with the same contract so whoever calls it notices no change other than the speed.

    Examples of deliverables

    • Service with the same contract
    • Route-by-route migration
    • Comparing responses before switching
  • Module 4 · Open line

    Local server and real time

    An API embedded in a desktop app or in a shop-floor machine, and open channels to send changes to clients as they happen.

    Examples of deliverables

    • Local API of a desktop app
    • Live events over WebSocket
    • Service on a machine with no cloud

A working example

One well-formed request and four that are not

Simulated demonstration. Fill in the order and send it. Try removing the token, typing letters in the quantity or sending it many times in a row, and see at which layer each attempt stops.

Simulated demo · sample data

The request

What it goes through

  1. Access
  2. Limit
  3. Shape
  4. Handler

Requests it accepts right now3

Response (simulated)

  1. Nothing has been sent yet.

There is no server behind it: the layers and their responses are simulated in your browser and nothing you type is sent. The order of the checks is that of a real service.

Integration

How it fits with your systems

An API is the door of a system. On one side the website, the app and other programs call; on the other are your data and the services you depend on.

Where it comes from

AxumRust API with Axumchecks, decides and responds

Where it goes

Dependencies worth checking

  • What contract the API has today and who depends on it
  • Which database is used and which Rust libraries access it
  • Where it is deployed and what resources that machine has
  • Which external services can fail and what is answered then

How we work and what we deliver

How we work on an Axum job

  1. 01

    Initial review

    We look at the service that exists or the one that is needed: routes, traffic, dependencies and what fails today.

  2. 02

    Scope

    We write down the API contract, the layers every request goes through and what is left out.

  3. 03

    First release

    The main routes responding against real data, with their documentation and their measurements.

  4. 04

    Validation

    You test it with your website or your app, with malformed requests and with load.

  5. 05

    Documentation

    The contract, how it is deployed, what is measured and how to add a new route.

What you get when the job closes

  • The code of the service in your repository, with its tests
  • The API documentation, generated from the code
  • The deployment configuration
  • The list of what is left out, and why

Questions

Questions about Axum

Missing yours? Write it to info@veodar.com and we'll reply with a specific question, not a brochure.

Why an API in Rust and not in Node.js?

For most projects, Node.js is enough and quicker to develop. Rust pays off when the service gets a lot of traffic, runs on few resources or is so critical that it is worth having the compiler review every change. We usually propose it for one specific piece, not for everything.

Does the whole backend have to be rewritten?

No. You can put only the service that needs it in Rust and leave the rest where it is. The two live together behind the same address and whoever calls cannot tell which one answers.

What does it mean that requests are checked for their shape?

That each route declares which data it expects: which fields, of which type, which are required. If the request does not fit, it is rejected with a clear message before anything runs, and your logic does not have to defend itself against half-formed data.

Can a desktop app carry its own API?

Yes, and it is a frequent use: the application opens a small server on the machine so other programs on the local network can ask it for data or give it commands. With Axum that server lives inside the same executable.

Which database is used?

The one you already have, almost always. Rust has mature libraries for PostgreSQL, MySQL and SQLite, and some check the queries against the schema at compile time. What we review at the start is that a good one exists for your case.

How is it deployed?

As a single executable or a small container image, on your server or in the cloud you use. It needs no interpreter or installed environment, which simplifies updates.

Updated:

Related services

All services

Other technologies

What it is combined with

All technologies
  • Rust developmentApplications, services and modules that cannot fail or run slow. We write the core of your product in Rust, or the piece that is holding it back today.
  • Concurrent services with TokioRust services that handle many connections and devices at once without blocking, with timeouts, retries and an orderly shutdown.
  • Node.js backendAPIs, connections between systems and background processes. We automate the exchange of information between your website and your business tools.

Get started

Tell us which service is falling short.

Knowing what it does, who calls it and where it struggles is enough for a first answer.

What helps us assess it

  • What the service does and who calls it
  • Where it fails or slows down
  • Which database and dependencies it has
  • Where it is deployed
Tell us about your project info@veodar.com

Before you write, see how we price a project or our solutions by department.

Fig. 07Morse keyH · E · L · L · O