Rust/Axum/SeaORM codebase containing real world examples (CRUD, auth, advanced patterns, etc) that adheres to the RealWorld spec and API.
This codebase was created to demonstrate a fully fledged backend application built with Rust and axum including CRUD operations, authentication, routing, pagination, and more.
This project is a fork of RealWorld Tide with:
This project attempts to achieve a clear separation between web, domain and persistence logic -
loosely along the lines of the ports and adapters architecture.
These three concerns live in separate crates - web, domain and db.
axum is used in the web crate while diesel is the main character of the db crate.
The fourth crate, application, glues the other three together and provides the runnable binary.
Each sub-crate has its own set of tests, with integration tests taking place in the web crate.
You can also exercise the application using Realworld's Postman collection: here.
For more information on how this works with other frontends/backends, head over to the RealWorld repo.
If you want to get a taste of what it feels like to build a Realworld's implementation using another
Rust's web framework, you can reuse the domain and db sub-crate.
You just need to provide an alternative implementation of the web crate leveraging your framework of choice.
- Rust 1.56 (see here for instructions)
- Docker/DockerCompose (see here for instructions)
- Make (see here for instructions)
- Launch a local Postgres instance with docker-compose
docker-compose up -d- Run SQL migrations
make dbYou are ready to go!
Run tests, including DB integration tests
make testRun the app
make runIf you want to run the "realworld" Postman tests, just execute
git clone https://github.com/gothinkster/realworld
cd realworld/api
APIURL=http://localhost:5000/api ./run-api-tests.shAll configuration files are in the configuration folder.
The default settings are stored in configuration/base.yml.
Environment-specific configuration files can be used to override or supply additional values on top the
default settings (see development.yml or test.yml).
In a production environment, you could introduce a production.yml to store production-specific configuration values.
Configuration files can also be overriden using environment variables, prefixed with APP:
the value of APP_APPLICATION_PORT will have higher priority then application.port in base.yml or development.yml.
All configurable parameters are listed in configuration.rs.
