A flexible web framework that promotes stability, safety, security and speed.


The Gotham web framework

A flexible web framework that promotes stability, safety, security and speed.

Join the chat at https://gitter.im/gotham-rs/gotham GitHub actions Dependency status


  1. Stability focused. All releases target stable Rust. This will never change. To ensure future compatibility, we also run automated builds against Rust beta and nightly releases.
  2. Statically typed. The Gotham web framework is statically typed ensuring your application is correctly expressed at compile time.
  3. Async everything. By leveraging the Tokio project, all Gotham web framework types are async out of the box. Our async story is further enhanced by Hyper, a fast server that provides an elegant layer over stringly typed HTTP.
  4. Blazingly fast. Measure completed requests, including the 99th percentile, in µs.


Licensed under your option of:


The following policies guide participation in our project and our community:


The following resources are available to assist you learning the Gotham web framework:

Projects Using Gotham


We hope you'll find the Gotham web framework is flexible enough to meet the needs of any web application you might like to build. Please have a chat with us or create an issue if you find this isn't the case, perhaps there is something the Gotham web framework can offer that will help you achieve your goals.

We do acknowledge that sometimes the choices we've made for the Gotham web framework may not suit the needs of all projects. If that is the case for your project there are alternative Rust web frameworks you might like to consider:

  1. Actix-Web
  2. Conduit
  3. Nickel
  4. Rocket
  5. Rouille

Explore even more suggestions at Are we web yet?.

  • Async static file serving

    Async static file serving

    On your blog, you say that some important features are on the roadmap, including async static file serving. Is there any work on that for the moment ?

    feature documentation help wanted 
    opened by tforgione 62
  • Async Request Handlers by customizing error response

    Async Request Handlers by customizing error response

    /// # customize response for HandlerError /// ## Why do we need it? /// We might want to customize different response for different error, eg: /// * for authorized-user-resource, we might return 403(Forbidden) for an un-logged-in user; /// * or when some file user requesting is not found, we might return 404; /// * ... /// Or we just want to send with content-type: application/json when request is application/json. /// (In the old, we just send 500 with plain/text for any request if error happens)

    opened by darkdarkfruit 16
  • state: move instantiation into State::from_request

    state: move instantiation into State::from_request

    This refactors the service implementation a little bit to instantiate the State via a dedicated method. The underlying goal is to allow users to use Gotham without having to use its handler.

    The motivation for this is to let users inject more things into their state and call their handler directly instead of having to go through a Hyper service. In our case, we use this for:

    • Integrating in a Hyper service for a sub-route.
    • Injecting data about TLS client certificates that were used by the client
    feature discussion non-breaking-change 
    opened by krallin 16
  • Migrate Gotham to std Futures to support Async/Await

    Migrate Gotham to std Futures to support Async/Await

    With the anticipated release of async-await in stable rust this week, I took an effort to migrate Gotham to run on std futures using the pre-release versions of the dependencies (tokio, hyper, etc).

    NOTE: This doesn't attempt to introduce await or async fn into the codebase (there was a single unavoidable case due to an tokio::File::metadata API change). That is designed as a future activity.

    This migration involved a few key efforts:

    1. Convert from Futures 0.1 to Futures-preview 0.3 (mostly Future<Item=> to Future<Output=Result<>>).
    2. Update dependencies to pre-release versions (tokio-0.2 and hyper-0.13). There's still other dependencies that are outstanding and blocking the full release.
    3. Migrate Handler trait to a pinned box HandlerFuture.

    This is a work-in-progress with a few blockers before this would be ready:

    Gotham Dependencies:

    • [x] Update Futures from futures-preview to futures = 0.3 when the other dependencies (hyper, tokio, etc) update in concert.
    • [x] Update Tokio to 0.2 from alpha pre-releases
    • [x] Update Hyper to 0.13 from alpha pre-releases
    • [x] Update Tower-Service to 0.3 from alpha pre-releases. Hyper is migrating many of its traits to tower-service::Service and so is now a direct dependency.
    • [x] Released version of futures_rustls which is currently a branch of tokio-rustls ported to Futures-preview
    • [x] Released version of futures-tokio-compat or suggested tokio::compat library for bridging futures::AsyncRead and tokio::AsyncRead. See https://github.com/tokio-rs/tokio/issues/1297 and https://github.com/async-rs/async-std/issues/54

    Middleware Dependencies:

    • [x] Diesel - Requires updated release of tokio-threadpool
    • [ ] JWT - Requires updated release of jsonwebtoken since it's dependency ring conflicts withs futures-rustls.

    The following examples were not updated (and thus commented out in Cargo.toml) due to incompatible dependencies:

    • [x] hello_world_until is dependent on a compatible version of tokio-signal
    • [x] diesel is dependent on the Diesel middleware
    • [ ] openssl is dependent on tokio-openssl
    • [ ] websocket is dependent on tokio-tungstenite
    opened by kevinastone 15
  • Add experimental Router builder API

    Add experimental Router builder API

    This is a first attempt at building the Router creation API that will be used by all Gotham applications.

    The primary goal of this branch is to get as far as we can without introducing any macros. Keeping in line with idiomatic Rust, I opted to write a "builder" API for the router. An simple example router with this API looks like:

    fn router() -> Router {
        // Note: Pipeline API isn't part of this PR
        let pipelines = new_pipeline_set();
        let (pipelines, default) =
        let pipelines = finalize_pipeline_set(pipelines);
        let default_pipeline_chain = (default, ());
        // Router builder starts here
        build_router(default_pipeline_chain, pipelines, |route| {
            route.scope("/api", |route| {

    More in-depth examples:

    This is an experimental API which will likely see some breaking changes before we're totally happy with it, ~~and so it will ship behind a Cargo feature ("experimental-router") to communicate that fact to app developers who might otherwise expect some stability in the API.~~

    As a future concern, once this API is bedded in and we know more about what we can't do with a builder API, we can look at adding macros. That's out of scope for this PR.

    Comments/questions/feedback/review welcome from anybody who's interested in doing so.

    feature discussion 
    opened by smangelsdorf 15
  • Implement IntoResponse for more type combinations

    Implement IntoResponse for more type combinations

    This fixes #277, kinda.

    This PR will introduce some new constructs for returning responses, namely:

    (Mime, Into<Body>)
    (StatusCode, Mime, Into<Body>)

    There are a few things to note:

    • We can't actually implement for Into<Body> due to clashes with Response<Body>, so they're manually derived for the meantime (somewhat annoying, but not the end of the world).
    • The default mime type is TEXT_PLAIN; not sure if it should be something else?
    • The default status code is OK.

    Each implementation just passes through to the next, and the actual response is built using the create_response function in the helper - to keep things consistent. I adjusted the signature there to align with the new types as well.

    The idea is that create_response is now only needed when you need to do something to the response itself manually; such as changing headers, and so on. If you only care about status/mime/body, you can just return a Tuple (which should theoretically work for a lot of cases).

    In doing all of this, the generic type B was removed from IntoResponse - which isn't breaking as it was introduced between 0.2.1 and now anyway. I think aligning on Body for the response body type makes sense at least for the time being.

    Finally I removed construct_response in favour of making create_empty_response the base response creator. I doubt there's much overhead to doing it this way, and even so it makes the code more readable so likely a non-issue.

    A few remaining questions I'd like opinions on:

    1. Given that the point of this is to discourage create_response directly, should I update all examples to use these new formats?
    2. Should create_response simply become a function that accepts State, IntoResponse? It can then just attach any default headers (etc.) onto the returned response.
    3. Is TEXT_PLAIN an appropriate default mime type?
    opened by whitfin 14
  • Add workers middleware and reengineer diesel middleware to make use of it

    Add workers middleware and reengineer diesel middleware to make use of it

    The best (read: laziest) way to describe this PR is by pointing at the documentation for the "workers" and "diesel" middleware as written for this PR (mostly the rustdoc).

    Ref #210

    opened by smangelsdorf 12
  • Add top-level function for starting a server with a provided Handle

    Add top-level function for starting a server with a provided Handle

    I would like to run two tokio-based servers in parallel in my application, one of which is a Gotham HTTP server. As far as my understanding of tokio goes, it ought to be possible to create one event loop and register both services onto it.

    Is there a way to start a Gotham server using a provided tokio Handle, rather than letting it create its own event loop? If not, and you feel that its a reasonable feature to implement, I'm happy to work on adding this behaviour.

    feature help wanted question 
    opened by kierdavis 12
  • Allow ? in routes

    Allow ? in routes

    Hi, I want to write code like this:

    fn homepage(state: State) -> search::Result<(State, Response<Body>)> {
        let a = expr()?
        return (state, a);
    fn make_router() -> search::Result<Router> {
        let state = IndexState::new()?;
        let middleware = StateMiddleware::new(state);
        let pipeline = single_middleware(middleware);
        let (chain, pipelines) = single_pipeline(pipeline);
        Ok(build_router(chain, pipelines, |route| {
            route.get("/").to(homepage); // FIXME! doesnt work!

    But the IntoHandlerFuture trait does not get auto-impld for homepage. Therefore, I cant use ? in my function body.

    I tried adding the following into gotham:

    impl<T: IntoHandlerFuture, E: IntoHandlerFuture> IntoHandlerFuture for std::result::Result<T, E> {
        fn into_handler_future(self) -> Pin<Box<HandlerFuture>> {
            match self {
                Ok(hf) => hf.into_handler_future(),
                Err(hf) => hf.into_handler_future(),

    But I cant impl IntoHandlerFuture for my Error type:

    impl IntoHandlerFuture for Error {
        fn into_handler_future(self) -> Pin<Box<HandlerFuture>> {
            future::ok((NO_STATE_AVAILABLE_HERE, response)).boxed()

    But there was no way to get the state to return in into_handler_future.

    So I ask, can the API be changed to allow such code? Thank you.

    specification discussion 
    opened by sinistersnare 11
  • Async Diesel middleware and example

    Async Diesel middleware and example

    The current "under development" Diesel middleware provides a "blocking" api to use Diesel. Some previous work was done (and abandoned) to provide a worker CpuPool middleware to allow not blocking request handling when using diesel.

    I have been experimenting with continuing this, but with a different approach. Although Diesel doesn't directly support async, we can still build an async application around it using tokio_threadpool::blocking. This removes the need to explicitly manage a separate CpuPool, and looks like it will be a simpler implementation and api.

    I'm opening this issue to solicit discussion around this approach and coordinate efforts in pushing Diesel support forward. The new experimental api so far provides a repo abstraction that handles the DB connection pool and wraps tokio_threadpool::blocking. Usage looks something like:

        let repo = Repo::borrow_from(&state);
        let user = .....;
        // Returns a future able to be chained into a `HandlerFuture`
        repo.run(move |conn| {

    Previous work this would supersede includes: https://github.com/gotham-rs/gotham/pull/227 https://github.com/gotham-rs/gotham/issues/77 https://github.com/gotham-rs/gotham/pull/126

    opened by colinbankier 11
  • Update rand 0.5 to 0.6

    Update rand 0.5 to 0.6

    The rand crate recently split code pertaining to the ChaCha implementation into its own crate. This PR changes Gotham to include that new dependency, and updates the core rand crate to version 0.6.

    opened by noisefloors 11
  • Add examples about how to use `status_mut()` to change the status code of a response

    Add examples about how to use `status_mut()` to change the status code of a response

    The problem

    I was looking for a way to change the status code of my response and it has been hard to find to me, I based on the next example to create a CORS middleware, but the response status code was always 200 code, instead of 401 (unauthorized), so I had to change the status code manually, but I don't find any way to change it properly.


    I also tried to base on this documentation to change the status code, but that doesn't work with my problem, since this example instead of modifying an existing response is creating a new empty response.


    Then I noticed the status_mut function in the response struct, but it doesn't have any documentation about how to use it. So I couldn't use it anyway. Later I checked and found this block of code in this GitHub repository and I based on it to change the response status code, and that worked properly. But I think it could be included in the examples, for example, the first one that I mentioned could include this part about how to change the status code


    The request

    I suggest to add examples about how to use status_mut() to the middleware examples or to another example where it was visible so beginners can easily change the status_mut of a response

    opened by victor-heliomar 2
  • Redirect URLs to their canonical equivalent

    Redirect URLs to their canonical equivalent

    URLs with and without trailing slashes are considered to be different. Serving the same content behind a URL with and without a trailing slash may be considered duplicate content by search engines.

    There should be a way to redirect all URLs (via 301 Moved Permanently) to their canonical equivalent. That includes removing empty segments as well as redirecting to the variant with or without trailing slash (that should be selectable – I prefer trailing slashes, because I can then easily add subpages later).

    EDIT: Trailing slashes should not be added if a file is accessed, so this seems to be more complicated after all. One can also consider interpreting . and .., this might even be necessary if HTML pages use relative URLs (like <img src="../images/1.jpg">), but I don’t know to what extent browsers are already required to resolve this before sending the request.

    opened by gralpli 2
  • Update cookie requirement from 0.15 to 0.16

    Update cookie requirement from 0.15 to 0.16

    Updates the requirements on cookie to permit the latest version.


    Sourced from cookie's changelog.

    Version 0.16.0 (Dec 28, 2021)

    Breaking Changes

    • The MSRV is now 1.53, up from 1.41 in 0.15.
    • time has been updated to 0.3 and is reexported from the crate root.

    General Changes

    • rust-crypto dependencies were updated to their latest versions.

    Version 0.15

    Version 0.15.1 (Jul 14, 2021)

    Changes and Fixes

    • A panic that could result from non-char boundary indexing was fixed.
    • Stale doc references to version 0.14 were updated.

    Version 0.15.0 (Feb 25, 2021)

    Breaking Changes

    • Cookie::force_remove() takes &Cookie instead of Cookie.
    • Child jar methods split into immutable and mutable versions (Cookie::{private{_mut}, signed{_mut}}).
    • Cookie::encoded() returns a new Display struct.
    • Dates with year <= 99 are handled like Chrome: range 0..=68 maps to 2000..=2068, 69..=99 to 1969..=1999.
    • Cookie::{set_}expires() operates on a new Expiration enum.

    New Features

    • Added Cookie::make_removal() to manually create expired cookies.
    • Added Cookie::stripped() display variant to print only the name and value of a cookie.
    • Key implements a constant-time PartialEq.
    • Added Key::master() to retrieve the full 512-bit master key.
    • Added PrivateJar::decrypt() to manually decrypt an encrypted Cookie.
    • Added SignedJar::verify() to manually verify a signed Cookie.
    • Cookie::expires() returns an Option<Expiration> to allow distinguishing between unset and None expirations.
    • Added Cookie::expires_datetime() to retrieve the expiration as an OffsetDateTime.
    • Added Cookie::unset_expires() to unset expirations.

    General Changes and Fixes

    • MSRV is 1.41.

    ... (truncated)

    • da6a5be New version: 0.16.0.
    • 27d0684 Update RustCrypto dependencies.
    • 6af6e6f New release candidate version: 0.16.0-rc.1.
    • cbd84ff Reexport 'time' from crate root.
    • 5e616c3 Fix 'time' 0.3 update.
    • 0a7453c Initial update to 'time' 0.3.
    • 0d10202 Use the latest release version in README.
    • 9dc4b86 Update CHANGELOG for 0.15.1.
    • 5c560de Move to 0.16-dev on master.
    • 13511f3 Check if index is a char boundary before split.
    • Additional commits viewable in compare view

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies breaking-change 
    opened by dependabot[bot] 1
  • Use futures::lock::Mutex for sharing state between requests

    Use futures::lock::Mutex for sharing state between requests

    Hi! I'm working with futures (i.e my handlers are async)

    Ofter I need to protect my Service around Arc<Mutex<_>> where Arc and Mutex came from std. But when you are working with futures, it's better to use futures::lock::Mutex in order to avoid dead lock (see for example https://users.rust-lang.org/t/std-mutex-vs-futures-mutex-vs-futures-lock-mutex-for-async/41710/2) So,

    use futures::lock::Mutex;
    use std::sync::{Arc};
    #[derive(Clone, StateData)]
    pub struct ChatServiceWrapper {
        pub inner: Arc<Mutex<ChatService>>,
        let chat_service = ChatServiceWrapper {
            inner: Arc::new(Mutex::new(ChatService::new())),
        let pipeline = new_pipeline()
            .add(StateMiddleware::new(chat_service)) // <--- this goes to error

    the error is

    the type `std::cell::UnsafeCell<chat_service::ChatService>` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary
    `std::cell::UnsafeCell<chat_service::ChatService>` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary
    help: within `rest_api::ChatServiceWrapper`, the trait `std::panic::RefUnwindSafe` is not implemented for `std::cell::UnsafeCell<chat_service::ChatService>`

    How can I fix this error??

    Thanks a lot

    opened by allevo 10
  • HandlerError with body data

    HandlerError with body data

    Maybe this should be done different, but I would assume that I can additionally to modify the status_code of the HandlerError also add body data. My use-case would be e.g.: parsing JSON data from the request and if there is a syntax error return the error message from serde(as body) with an UNPROCESSABLE_ENTITY status code.

    opened by rp- 2
  • Deconstruct State for handler functions

    Deconstruct State for handler functions

    Currently, all handler functions take either State or &State as their only parameter, and need to retrieve all information they need in user code. It would be more convenient if we allowed for syntax like this:

    route.get("/").to(|(headers, body): (HeaderMap, Body)| { /* create response */ })

    This was first suggested by @tanriol in the Gitter chat.

    proposal discussion 
    opened by msrd0 0
  • gotham_middleware_jwt-0.8.0(Nov 6, 2022)


    • gotham_middleware_jwt 0.8.0


    • Update jsonwebtoken requirement from 7.0 to 8.0 (https://github.com/gotham-rs/gotham/pull/586)
    Source code(tar.gz)
    Source code(zip)
  • gotham_middleware_diesel-0.5.0(Nov 6, 2022)

  • gotham-0.7.1(Nov 18, 2021)

  • gotham-0.7.0(Nov 12, 2021)


    • gotham 0.7.0
    • gotham_derive 0.7.0
    • gotham_middleware_jwt 0.7.0
    • gotham_middleware_diesel 0.4.0

    Starting with this version, directly importing the derive macros from the gotham_derive crate is deprecated. Use gotham::prelude::* instead.


    • Send state to the session backend and allow it to return futures (#468)
    • Re-export the mime crate and all gotham_derive macros
    • Add AsyncTestServer (#552, #553, #555)
    • Introduce new features session, http2 and testing (all enabled by default)
    • Remove rustls feature from the default features
    • Start functions now return a result (#568, #571)
    • Allow access to the inner error of a HandlerError (#575)
    • Add a prelude module that re-exports traits and derive macros (#567)
    Source code(tar.gz)
    Source code(zip)
  • gotham-0.6.1(Jul 12, 2021)


    • gotham_middleware_jwt 0.6.1
    • gotham_middleware_diesel 0.3.1


    • Rename JWTMiddleware to JwtMiddleware
    • Update outdated documentation
    Source code(tar.gz)
    Source code(zip)
  • gotham-0.6.0(Mar 20, 2021)


    • gotham 0.6.0
    • gotham_derive 0.6.0
    • gotham_middleware_jwt 0.6.0
    • gotham_middleware_diesel 0.3.0


    • Update hyper to 0.14 and tokio to 1.0
    • Update cookie to 0.15
    • Implement Into<Response> for TestResponse
    • Add downcast_cause_ref and downcast_cause_mut for HandlerError
    • Add add_route_matcher to DelegateRouteBuilder
    • Add State::from_request to allow using gotham with a custom hyper service
    • Fix spurious Not Connected errors (#461)
    • Remove PathExtractor and QueryStringExtractor derive macros, they've been replaced by StateData and StaticResponseExtender a few releases ago
    Source code(tar.gz)
    Source code(zip)
  • borrow-bag-1.1.0(Mar 20, 2021)

  • 0.1.0(Aug 15, 2017)

    The initial release of the Gotham web framework.

    We wanted to get Gotham in the hands of the Rust community early with regular smaller iterations to follow.

    The Gotham 0.1 release includes the following features:

    • Handlers and Controllers
    • Advanced Routing
    • Type Safe Extractors
    • Middleware and Pipelines
    • Request State
    • Sessions
    • Request and Response helpers
    • Test helpers
    • Thoroughly documented code and the beginnings of a Gotham book
    Source code(tar.gz)
    Source code(zip)
A flexible web framework that promotes stability, safety, security and speed.
A blazingly fast static web server with routing, templating, and security in a single binary you can set up with zero code. :zap::crab:

binserve ⚡ ?? A blazingly fast static web server with routing, templating, and security in a single binary you can set up with zero code. ?? UPDATE: N

Mufeed VH 722 Dec 27, 2022
Actix Web is a powerful, pragmatic, and extremely fast web framework for Rust.

Actix Web Actix Web is a powerful, pragmatic, and extremely fast web framework for Rust Features Supports HTTP/1.x and HTTP/2 Streaming and pipelining

Actix 16.3k Jan 8, 2023
Sincere is a micro web framework for Rust(stable) based on hyper and multithreading

The project is no longer maintained! Sincere Sincere is a micro web framework for Rust(stable) based on hyper and multithreading. Style like koa. The

null 94 Oct 26, 2022
Salvo is a powerful and simplest web server framework in Rust world

Salvo is an extremely simple and powerful Rust web backend framework. Only basic Rust knowledge is required to develop backend services.

Salvo 1.2k Jan 5, 2023
A toy web framework inspired by gin-gonic/gin and expressjs/express.

Rum Framework A toy web framework inspired by gin-gonic/gin and expressjs/express. Installation Just add rum_framework to the dependencies of Cargo.to

Hidetomo Kou(YingZhi 2 Dec 20, 2022
An Extensible, Concurrent Web Framework for Rust

Iron Extensible, Concurrency Focused Web Development in Rust. Response Timer Example Note: This example works with the current iron code in this repos

null 6.1k Dec 27, 2022
An expressjs inspired web framework for Rust

nickel.rs nickel.rs is a simple and lightweight foundation for web applications written in Rust. Its API is inspired by the popular express framework

null 3k Jan 3, 2023
A web framework for Rust.

Rocket Rocket is an async web framework for Rust with a focus on usability, security, extensibility, and speed. #[macro_use] extern crate rocket; #[g

Sergio Benitez 19.5k Jan 8, 2023
A lightweight web framework built on hyper, implemented in Rust language.

Sapper Sapper, a lightweight web framework, written in Rust. Sapper focuses on ergonomic usage and rapid development. It can work with stable Rust. Sa

Daogang Tang 622 Oct 27, 2022
Web framework in Rust

Rouille, a Rust web micro-framework Rouille is a micro-web-framework library. It creates a listening socket and parses incoming HTTP requests from cli

Pierre Krieger 840 Jan 1, 2023
A fast, boilerplate free, web framework for Rust

Tower Web A web framework for Rust with a focus on removing boilerplate. API Documentation Tower Web is: Fast: Fully asynchronous, built on Tokio and

Carl Lerche 969 Dec 22, 2022
Handlebars middleware for Iron web framework

handlebars-iron Handlebars middleware for the Iron web framework. This library, together with handlebars, iron and hyper, works on both stable and nig

Ning Sun 118 Jun 28, 2022
The light web framework for Rust.

Rusty Web Rusty web is a simple to use, fully customizable lightweight web framework for rust developers. Learn rusty web Installation [dependencies]

Tej Magar 5 Feb 27, 2024
Simple and fast web server

see Overview Simple and fast web server as a single executable with no extra dependencies required. Features Built with Tokio and Hyper TLS encryption

null 174 Dec 9, 2022
A starter template for actix-web projects that feels very Django-esque. Avoid the boring stuff and move faster.

Jelly A.K.A, the actix-web starter you probably wish you had. This is provided as-is, and anyone is free to extend it or rework it as they desire - ju

SecretKeys 198 Dec 15, 2022
Add Facebook and Google authentication to your HTTP REST API in Actix-web

I created this project while learning Rust. Project shows how to handle Facebook and Google token verification in Rust using Actix-Web. Hope this help

null 37 Dec 31, 2022
Actix-extras - A collection of additional crates supporting the actix and actix-web frameworks.

actix-extras A collection of additional crates supporting the actix-web and actix frameworks. Crates by @actix Crate actix-cors Cross-origin resource

Actix 506 Dec 27, 2022
Operator is a web server. You provide a directory and Operator serves it over HTTP.

Operator Operator is a web server. You provide a directory and Operator serves it over HTTP. It serves static files the way you'd expect, but it can a

Matt Kantor 6 Jun 6, 2022
In-progress extractors and middleware for Actix Web

actix-web-lab Experimental extractors, middleware, and other extras for possible inclusion in Actix Web. Things To Know About This Crate It will never

Rob Ede 51 Dec 20, 2022