Forem: Ivan Yurov

State Machines for business

Ivan Yurov — Mon, 31 Aug 2020 09:54:59 +0000

TL;DR In this article we will take a look at state machines and how they are applied to model business processes, and a particular library implementing that for Elixir and Ecto.

Let's think about vending machine. Its operation defined by some set of constraints. Can you get a Coke when there are no bills in? No. Would it change if you put a dollar in there, while the beverage price is $2? Still no, duh. All of these properties combined constitute a State. Think of a State as a slice of the space-time continuum in the microcosm of this particular vending machine.

In this case, there is nothing but current balance accounted in the state, but in reality there is gonna be a whole lot more of variables there. Is supply of cokes and cookies unlimited? Unlikely! Should we consider the process of dispensing a state? Probably, since it's not momentary and we don't want any events to be allowed until the machine reports that the dispensing is over. But let's focus on money for now, it is gonna get whole lot more complicated when we start accepting coins. Watch what happens should we just add quarters:

See? Modeling a real life business process with pure finite state automata would be insanely complicated. Instead we can reduce the notion of state to a tag, a conventional name of a group of states. Are we collecting bills or coins, let’s call it collecting. Are we dispensing merchandize? Well, you see where this is going. We will still maintain internal variables that can be arbitrarily complicated, but now rather consider a mode of operation of the machine as a state, and not every possible combination of those variables.

This allows us to reduce this state machine to only two states including dispensing. Let's generalize the diagram and introduce the language:

Circles are States, as you might have guessed already. Arrows and everything that happens along the way are Transitions. Rectangles are Callbacks or actions that mutate variables of the inner state at some moments in life cycle. The rhombus is a Guard, a condition that has to be met to proceed with transition. Finally, an Event — an external signal accompanied with an optional value that triggers the transition. This diagram is a bit verbose, but when it's written using DSL or plain english, it's very simple:

When in collecting on put X, add X to balance, then move to collecting
When in collecting on get ITEM, if balance >= ITEM.price, then move to dispensing
When in dispensing on done, subtract item.price from balance, then move to collecting

So far, we have defined the following:

Two states collecting and dispensing
Three events put X, get ITEM, done
One guard on get ITEM event: balance >= ITEM.price
Two callbacks: balance + X on put X, and balance - ITEM.price on done

The internal state consists of 2 variables: balance and item; the latter is set on moving to dispensing and cleared afterwards. Actually, these are also callbacks, but they're missing in the diagram above. Well, modeling is not easy and we normally revisit the schema many times afterwards.

State Machine in Elixir

Modeling the same State Machine in Elixir with state_machine is straightforward. I added one extra event to be able to fulfill the merchandize and omitted the implementation of callbacks and guards for now:

defmodule VendingMachine do
  alias VendingMachine, as: VM
  use StateMachine

  defstruct state: :collecting,
            balance: 0,
            merch: %{},
            dispensing: nil

  defmachine field: :state do
    state :collecting
    state :dispensing

    event :deposit, after: &VM.deposit/2 do
      transition from: :collecting, to: :collecting
    end

    event :buy, if: &VM.can_sell?/2, after: &VM.reserve/2 do
      transition from: :collecting, to: :dispensing
    end

    event :done, after: &VM.charge/1 do
      transition from: :dispensing, to: :collecting
    end

    event :fulfill, after: &VM.fulfill/2 do
      transition from: :collecting, to: :collecting
    end
  end
end

A cool feature here is that if you mistype the state name in transition, it'll be caught at compile time. The definition is getting verified. It might seem useless when we have just two states, but in larger state machines it can be life saving.

Now let's take a look at callbacks:

def deposit(%{balance: balance} = model, %{payload: x})
  when is_integer(x) and x > 0
do
  {:ok, %{model | balance: balance + x}}
end

def deposit(_, _) do
  {:error, "Expecting some positive amount of money to be deposited"}
end

Callbacks can be of arity 0, 1 and 2. Zero arity callback would just produce some side effects independent of the state. The first argument passed into callback is the model itself. The second is the context, a structure containing the metadata supporting the current transition. This includes event payload, info about transition, such as old and new states, and a link to the state machine definition.

Return value of each callback is structurally analyzed on runtime in order to determine the appropriate action. You can return {:error, error}, and this will disrupt the transition and return {:error, {callsite, error}} in the very end. Here the callsite is pretty much the moment when the callback is triggered (after_event, for example).

If you return {:ok, updated_context}, it will update the current context. This is hardcore, but you can do that. More often you might want to update the model only. To do that, return {:ok, updated_model} and it'll be replaced in the context.

One important caveat is that currently only fully qualified function captures (&Module.fun/arity) are supported in callbacks. In future versions it will support lambdas and possibly local functions and atoms.

Next is a Guard can_sell?:

def can_sell?(model, %{payload: item}) do
  model.merch[item]
  && model.merch[item][:available] > 0
  && model.merch[item][:price] <= model.balance
end

First we make sure that the item is present in the inventory as a class, then we check if it is currently available, finally we make sure that balance is enough. There's one important point to note. Due to the mechanics of state_machine, guards do not leave any trace; they run sequentially while it's trying to find matching transition, as there can be many possible paths. In other words, for the user it will appear as if the event was impossible, and by using introspection tools you can find that out in advance, by checking allowed_events for a particular model.

The rest of callbacks should look trivial:

def reserve(model, %{payload: item}) do
  {:ok, %{model | dispensing: item}}
end

def charge(%{balance: balance, dispensing: item, merch: merch} = model) do
  {:ok, %{model |
    balance: balance - merch[item][:price],
    merch: put_in(merch[item][:available], merch[item][:available] - 1),
    dispensing: nil
  }}
end

def fulfill(%{merch: merch} = model, %{payload: additions})
  when is_map(additions)
do
  {:ok, %{model |
    merch: Map.merge(merch, additions, fn _, existing, new ->
      %{new | available: new.available + existing.available}
    end)
  }}
end

It's time to play with it. I created a little repo for this sample project so everybody could clone and try it locally. However I'll just post the test sequence here, it should be self explanatory:

alias VendingMachine, as: VM
vm = %VM{}

# Let's try to load it with some coke and cookies
assert {:ok, vm} = VM.trigger(vm, :fulfill, %{
  coke: %{price: 2, available: 1},
  cookie: %{price: 1, available: 5}
})

# And one more coke to ensure correct merging
assert {:ok, vm} = VM.trigger(vm, :fulfill, %{
  coke: %{price: 2, available: 1},
})

assert vm.merch.coke.price == 2
assert vm.merch.coke.available == 2
assert vm.merch.cookie.price == 1
assert vm.merch.cookie.available == 5

# Now let's grab a coke
assert {:error, {:transition, _}} = VM.trigger(vm, :buy, :coke)

# But wait, we could actually tell that before even trying:
refute :buy in VM.allowed_events(vm)

# Oh right, no money in there yet
assert {:ok, vm} = VM.trigger(vm, :deposit, 1)
assert {:ok, vm} = VM.trigger(vm, :deposit, 1)
assert vm.balance == 2

# Huh, hacking much? Note how error carries the callsite where it occurred
assert {:error, {:after_event, error}} = VM.trigger(vm, :deposit, -10)
assert error == "Expecting some positive amount of money to be deposited"

# Gimme my coke already
assert {:ok, vm} = VM.trigger(vm, :buy, :coke)
assert vm.state == :dispensing

# While it's busy, can I maybe ask for a cookie, since the balance is still there?
assert {:error, {:transition, "Couldn't resolve transition"}} = VM.trigger(vm, :buy, :cookie)

# Okay, the can is rolling into the tray, crosses the optical sensor, and it reports to VM...
assert {:ok, vm} = VM.trigger(vm, :done)
assert vm.state == :collecting
assert vm.balance == 0
assert vm.merch.coke.available == 1

When we use defmachine macro in the VendingMachine module, it creates some auxiliary functions. The most important one is trigger(model, event, payload); when it is called, it attempts to run an event. This function returns {:ok, updated_model} if the transition worked or {:error, {callsite, error}} if it didn't. By checking callsite, you can find out where it was rejected.

StateMachine supports Ecto out of the box, by wrapping triggers in transactions and calling Repo.update() on the state field, but it requires a bit of configuration. It can also work as a process by automatically generating GenStatem definition. More on that in the next posts.

Links:

A case study for property based testing in Elixir

Ivan Yurov — Mon, 13 Jul 2020 11:07:11 +0000

It's been a while since I learned about property based testing, yet I never had a chance to apply it in my work. Property based testing is a stochastic process, in which your code is being bombarded with multiple combinations of examples, and output is checked for compliance to some condition that is supposed to hold on all inputs. The idea of describing and checking higher level properties of some code is just as beautiful as impractical in many areas of programming. In particular, in web development, where logic is usually intertwined with the database layer. Running hundreds of instances of the same test would introduce prohibitive overhead. This explains why I have not even attempted to adopt it before.

Let's take for example this little function:

def add(a, b) do
  a + b
end

Suppose I meant it to be used with positive integers and I want to make sure that the result is always equal or greater than either operand. Kinda silly, but this is just an example. Let's describe this assumption then:

property "result of addition always >= of each operand" do
  check all a <- integer(),
            b <- integer()
  do
    s = add(a, b)
    assert s >= a && s >= b
  end
end

This fails (expectedly):

Failed with generated values (after 1 successful run):

  * Clause:    a <- integer()
    Generated: -1

  * Clause:    b <- integer()
    Generated: 0

Right! We forgot about negative ints. In order to make fix comprehensive, we need to both add a guard to the function itself and bound the input stream. Whenever we do var <- integer(), it means instantiation of a particular value out of the stream of integers. Since we don't want just any integer, we should be able to apply a filter somehow. Even though the library provides specified positive_integer() generator, it does not suit our needs, because it filters out zeroes as well. Instead we apply filter to the stream:

def add(a, b) when a >= 0 and b >= 0 do
  a + b
end

property "result of addition always >= of each operand" do
  check all a <- filter(integer(), &(&1 >= 0)),
            b <- filter(integer(), &(&1 >= 0))
  do
    s = add(a, b)
    assert s >= a && s >= b
  end
end

Now test passes. We could go on with improvements by creating a custom generator, but instead I wanted to move to the first useful and successful use of property based testing in my practice. Meanwhile feel free to dig deeper into StreamData docs to learn more about API of the library that was almost included into Elixir itself.

Real life example

Recently, while working on a poll feature for a social app, I ran into the issue of distributing percents. There are multiple options with the poll, each option has an integral number of votes greater or equal than zero, there is a total number of votes as well. What I needed is to hide the absolute numbers of voters and convert these numbers into percents, while making sure they add up to 100% or 0% if there were no votes whatsoever. The main issue I expected was rounding errors. Simple example:

4.5 + 5.5 == 10.0
round(4.5) + round(5.5) == 11

With different distributions of votes, rounding can introduce overflows as well as underflows.

While 146% of votes might be okay for Russian politics, I wanted to avoid that. And the original approach was to maintain some accumulator initialized at 100 and return it at the last option.

@doc """
Computing percent for all options using total_votes
and option_votes in Poll and Option respectively.
This function makes sure that integral percents
sum up properly to 100%.
"""
@spec distrib_votes(%Poll{}, [%Option{}]) :: [%Option{}]
def distrib_votes(poll, options, acc \\ 100)

def distrib_votes(%Poll{total_votes: 0}, options, _) do
  options
end

def distrib_votes(_, options, percent)
  when options == [] or percent <= 0
do
  options
end

def distrib_votes(_, [option], percent) do
  [%{option | percent: percent}]
end

def distrib_votes(poll, [option | options], percent) do
  p = round(100 * option.option_votes / poll.total_votes)
  option = %{option | percent: min(p, percent)}
  [option | distrib_votes(poll, options, percent - p)]
end

When I tried to come up with meaningful and comprehensive test cases, I realized that it slips out of my control and I recalled property based testing. Really, this little function does not need the database, and the assertion is extremely easy to formulate: the sum of the percents should either equal to 100% or 0% if there is no votes:

property "distrib_votes always sums to either 100 or 0" do
  check all votes <- list_of(filter(integer(), & &1 >= 0)) do
    options = Enum.map(votes, & %Option{option_votes: &1})
    total_votes = Enum.sum(votes)
    poll = %Poll{total_votes: total_votes}
    total_percents = Feed.distrib_votes(poll, options)
    |> Enum.map(&(&1.percent))
    |> Enum.sum()
    assert total_votes > 0  && total_percents == 100
        || total_votes == 0 && total_percents == 0
  end
end

These were the final versions of the test and function definition. Initially I failed to define correct assertion by setting a naive condition total_percents == 100 || total_percents == 0 and of course it would allow for a buggy behavior, where no votes poll would show 100% at the last option. Using implicative form (precondition) fixed that and proved that the test is just as good or as bad, as the logic behind it.

Hassle-free cursor pagination for Ecto — part 1

Ivan Yurov — Wed, 01 Jul 2020 11:28:35 +0000

TLDR; Cursor-based pagination is tricky. The distinct ordering of the query is necessary to make it deterministic, and the potential arbitrary complexity of order by clause makes it hard to provide a universal solution. Existing libraries for Ecto do not support complex expressions and rarely even work with joined tables. EctoCursor does all of that out of the box and without any configuration. You don’t even need to declare what fields would be used for the cursor, it is just derived from the ordering.

This is the first part of two articles, providing the motivation behind the implementation of EctoCursor. More specifically we talk about why this should work in general case without any configuration. In the next part we will talk about interesting parts of implementation: mostly digging in the internals of Ecto queries and manipulating them.

If you don't want to wait for the next part, feel free to take a look at the source code and test cases right away :)

Why cursor?

Offset-based pagination is slow. Query execution time grows proportionally to the number of rows you need to skip, because database engines scan those sequentially. Keyset- or cursor-based pagination, on the contrary, relies on concrete values in columns which unlocks the power of indexing. As a result, 1000th page loads as quickly as the first.

This approach works especially good for feeds and so called infinite scroll. Yet it does not work for explicit pagination, because it would impose prohibitive overhead on generating cursors for every page-link.

Why is it tricky?

First important constraint is making sure that order is distinct. Imagine a table like this:

id	name	timestamp
1	Post 1	1
2	Post 2	1
3	Post 3	2

Suppose we decided to order by timestamp without considering that it is not impossible that more than one row can have the same value (think of bulk loading, for example). Now if we request for the first page consisting of one row for simplicity, we get this tuple back:

[{1, "Post 1", 1}]

How we encode the cursor for subsequent queries? We just take that last value in the list and assume that the starting value in the next frame will have to be strictly larger, so:

timestamp > 1

And now we have a problem. Next row will be skipped because of this condition, and second page we receive will be:

[{3, "Post 3", 2}]

This is easy to fix though. We can just add a column that is guaranteed to be unique to disambiguate the query, like so:

SELECT * FROM posts ORDER BY timestamp, id;

Now the cursor that comes with the first page, will be composed of two values timestamp = 1 and id = 1. And the condition in the next query will have to tackle the case of equality:

SELECT * FROM posts
  WHERE timestamp > cursor_1
    OR timestamp = cursor_1 AND id > cursor_2
  ORDER BY timestamp, id;

Cursor components here are denoted with _N, obviously we need to make sure somehow that number of components and their types correspond to the ORDER BY clauses in query. We will talk about it later.

The case discussed above was extremely simple, in real life we deal with arbitrary complex expressions in ORDER BY clauses as well as multiple tables joins and groupings. I'm going to propose a solution of unknown degree of completeness, and I'm certainly open for corrections, additions or any other contributions that would help to prove or disprove completeness.

Dissecting the Query

This is a basic syntax of SQL Select query. We need to apply some transformations in order to be able to generate next cursor and apply existing cursor.

SELECT {select_exprs}
  FROM {source_tables}
  WHERE {where_exprs}
  GROUP BY {grouping_exprs}
  HAVING {having_exprs}
  ORDER BY {ordering_exprs}

Theoretically it is possible to do it in one request, but for the sake of simplicity we are going to separate these tasks, because expressions (fields, aggregates) used in ordering condition will not necessarily appear in select_exprs. So we should start from separating the task into two subtasks.

Applying current cursor
Generating next cursor

Applying cursor condition

This is relatively easy to do in the general case. Suppose we have N subexpressions in order by, we will call them ord_N for brevity. Then the cursor must have N components — cur_N respectively. Now all we need to do is to extend where_exprs blindly reusing parts of ordering_exprs and ignoring direction for now:

SELECT {select_exprs}
  FROM {source_tables}
  WHERE {
    where_exprs
    AND (
      ord_1 > cur_1
      OR ord_1 = cur_1 AND ord_2 > cur_2
      OR ord_1 = cur_1 AND ord_2 = cursor_2 AND ord_3 > cur_3
      ...etc
    )
  }
  -- GROUP BY {grouping_exprs}
  -- HAVING {having_exprs AND the above extensions}
  ORDER BY {ord_1 DIR, ord_2 DIR, ord_3 DIR, ...}
  LIMIT lim

This will return the original query result after the row that is cascade-matching the cursor. One important note: whenever the query has GROUP BY clause, the extended conditions will have to be added into HAVING and not where, due to possibility of having the aggregates in ordering.

Generating next cursor

Now we need to capture the values of order expressions in the last row of the request above. Again, theoretically it can be done in one request by just extending the select_exprs, but this might become tricky to implement when we dig into Ecto. So for now we just replace original select_exprs and make appropriate adjustments in LIMIT/OFFSET:

SELECT {ord_1, ord_2, ord_3, ...}
  FROM {source_tables}
  WHERE {
    where_exprs
    AND (
      ord_1 > cur_1
      OR ord_1 = cur_1 AND ord_2 > cur_2
      OR ord_1 = cur_1 AND ord_2 = cursor_2 AND ord_3 > cur_3
      ...etc
    )
  }
  -- GROUP BY {grouping_exprs}
  -- HAVING {having_exprs AND the above extensions}
  ORDER BY {ord_1 DIR, ord_2 DIR, ord_3 DIR, ...}
  LIMIT 1
  OFFSET lim - 1

This will return the cursor itself. All we need to do afterwards is just to serialize it to make it URL-friendly.

Validation of cursor

From the modifications we proposed above, it is clear that cursor absolutely must have the same number of components as the ordering expressions, and they have to have same types respectively. What if cursor is incompatible with the query? We simply will not be able to compose properly conditioned query. One of the easy ways to make sure is to hash the original query shape without arguments and sign both cursor and the query hash using some common MAC algorithm, this will let to reject the damaged cursor early. Reporting the error or just falling back to no cursor — should be up to the application developer.

In the next part we will dig into Ecto to try and implement this proposed approach. Again if you don't want to wait for the next part, feel free to take a look at the source code and test cases right away. I will always appreciate corrections, suggestions and any input here as well as in github issues.

Ultra fast backend with Rust

Ivan Yurov — Tue, 23 Jun 2020 14:34:13 +0000

After dealing with Rust internals for a school project, I decided to give it a try in the application land, more specifically in web development. Framework benchmarks looked extremely promising and I had a small backend that could benefit from a little speedup. It was written in Elixir, which I believe is the best language for the web, but nothing can beat the native code, right? The backend I’m about to build will contain a web-server, graphql query processor, and an ORM for PostgreSQL. After a bit of research I chose actix-web, juniper and diesel respectively. Bear in mind, that this is a learn-with-me kind of article, that said it’s not gonna present any best practices, as I have no idea what practices are best yet :)

Getting started

In order to proceed, you will need to install rust toolchain, and then creating an empty Rust project is as easy as:

cargo new rust_backend

Now we need to include actix-rt and actix-web into Cargo.toml and here is our hello world example:

use actix_web::{web, App, HttpServer, Responder};

async fn hello() -> impl Responder {
    "Hello world!"
}

#[actix_rt::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new().route("/", web::get().to(hello))
    }).bind("127.0.0.1:8080")?.run().await
}

Couple of interesting things happening here. HttpServer constructor accepts a factory — a lambda function that returns a new instance of the App every time it's called, because Actix spawns a new App for every thread. The handler doesn't have any arguments in this case, but normally there will be URL-parameters, payload, etc. Now you can run it:

cargo run

And using Apache Benchmark make sure that it handles massive amount of requests in parallel (with effective rate of ~0.08 ms per request on my machine). A good surprise here is that Cowboy shows very similar levels of performance and parallelism.

GraphQL

Now it's time to start integrating GraphQL. Adding juniper to deps, and here's the simple schema:

use juniper::{GraphQLObject, FieldResult, RootNode};

#[derive(GraphQLObject)]
#[graphql(description = "An artist")]
struct Artist {
  id: String,
  name: String
}

pub struct QueryRoot;

#[juniper::object]
impl QueryRoot {
  fn artists() -> FieldResult<Vec<Artist>> {
    Ok(vec![Artist {
      id: "1".to_string(),
      name: "Ripe".to_string()
    }])
  }
}

pub struct MutationRoot;

#[juniper::object]
impl MutationRoot {
}

pub type Schema = RootNode<'static, QueryRoot, MutationRoot>;

pub fn create() -> Schema {
    Schema::new(QueryRoot {}, MutationRoot {})
}

What we did here is defined an Artist object and a single root query artists that always returns a singleton collection containing one artist Ripe. Before we continue, let's take a break and listen to them! :)

Everything is pretty straight forward so far, if you're already familiar with GraphQL. If not, check this beautiful manual out.

One interesting point is that Juniper defines fields as non_null by default. In our case that means [Artist!]! — non null collection of non null artists. Other GraphQL backends treat all fields and collection elements as optional by default and it's a known source of pain for frontenders using TypeScript. With all my love to monadic types, Maybe that Apollo generates for this case is absolutely useless. In other words, this is a very reasonable default that everyone should adopt.

Now we need to teach the web server to process GraphQL queries. The updated main.rs will look like this:

mod schema;

use actix_web::{App, HttpServer, HttpResponse};
use actix_web::web::{Data, Json, post, get, resource};
use juniper::http::{graphiql, GraphQLRequest};

async fn graphiql() -> HttpResponse {
  HttpResponse::Ok()
    .content_type("text/html; charset=utf-8")
    .body(graphiql::graphiql_source("/api"))
}

async fn api(
  scm: Data<schema::Schema>,
  req: Json<GraphQLRequest>
) -> HttpResponse {
  let res = req.execute(&scm, &());
  let json = serde_json::to_string(&res).unwrap();
  HttpResponse::Ok()
      .content_type("application/json")
      .body(json)
}

#[actix_rt::main]
async fn main() -> std::io::Result<()> {
  let factory = || App::new()
    .data(schema::create())
    .service(resource("/api").route(post().to(api)))
    .service(resource("/graphiql").route(get().to(graphiql)));

  HttpServer::new(factory).bind("127.0.0.1:8080")?.run().await
}

Now we got rid of the dummy handler, and added two new ones related to graphql instead. One is graphiql, a playground for your graphql endpoint, it just renders as a single page app allowing to play with actual graphql backend — run some queries, introspect the schema etc. The second handler api is where the magic happens. We get two arguments there: a schema instance and a request payload json-decoded (automatically, thanks to actix). I want to keep it dead simple for now, so we ignore potential error conditions and blocking nature of graphql executor. So we are doing these simple steps:

Execute graphql request
Encode the result as json
Send the response to client

Now it's a good time to run the app and visit /grphiql route where we can already ask the api for artists:

{
  artists {
    id
    name
  }
}

This should return that one artist we hardcoded earlier.

Hooking up the DB

So far, so good, but now we want to take the records dynamically from the database. From now on, changes are gonna pile up much faster, so bear with me.

First we define schema. Normally it's generated automatically out of migrations, but I want to use (part of) the existing database, so I just create it manually (schema.rs):

table! {
  artists (id) {
    id -> Integer,
    name -> Text,
  }
}

One caveat in case of my existing DB was that id field was defined as BigSerial, which would require defining it as a BigInt, while juniper maintainers dropped the default support of i64 type for some reasons.

Now we modify GraphQl object definitions and move it to their own module (models.rs):

#[derive(Queryable, juniper::GraphQLObject)]
#[graphql(description = "An artist")]
pub struct Artist {
    pub id: i32,
    pub name: String
}

This is very close to what we had before, we just extended it with Queryable derivation. Now we need to create a pool and inject it into the app. This is how updated main function will look like:

#[actix_rt::main]
async fn main() -> std::io::Result<()> {
  let db_url = "postgresql://USER:PASS@localhost:5432/DB_NAME";
  let manager = ConnectionManager::<PgConnection>::new(db_url);
  let pool = Pool::builder().build(manager).expect("Failed to create pool.");

  let factory = move || App::new()
    .data(graphql::create_schema())
    .data(pool.clone())
    .service(resource("/api").route(post().to(api)))
    .service(resource("/graphiql").route(get().to(graphiql)));

  HttpServer::new(factory).bind("127.0.0.1:8080")?.run().await
}

In order to consume this pool we will pass it into GraphQL executor as a Context. In reality we might want to have more sophisticated Context structure (for example to pass individual dataloaders there), but for now we just assume that the DbPool type implements juniper::Context. This is how it's done:

pub type DbPool = Pool<ConnectionManager<PgConnection>>;
#[juniper::object(Context = DbPool)]
impl QueryRoot { ... }
// And the same for MutationRoot

Checking out a connection from the pool is a blocking operation, just like a request to the DB itself. It is beneficial to offload this work off the main thread, which is done like this in the main graphql handler:

async fn api(
  scm: Data<graphql::Schema>,
  pool: Data<Pool<ConnectionManager<PgConnection>>>,
  req: Json<GraphQLRequest>
) -> Result<HttpResponse, Error> {
  let json = web::block(move || {
    let res = req.execute(&scm, &pool);
    serde_json::to_string(&res)
  }).await?;

  Ok(HttpResponse::Ok()
      .content_type("application/json")
      .body(json))
}

Finally the last step is to replace that hardcoded collection of artists with the actual database request:

fn artists(pool: &DbPool) -> FieldResult<Vec<Artist>> {
    let conn = pool.get().map_err(|_|
      FieldError::new("Could not open connection to the database", Value::null())
    )?;

    artists
      .limit(1000)
      .load::<Artist>(&conn)
      .map_err(|_|
        FieldError::new("Error loading artists", Value::null())
      )
  }

Assessing the performance

In order to assess the performance, we're gonna hit the endpoint using Apache Benchmark with the following (payload.txt):

{"query": "{artists{id name}}"}

and with the following settings:

ab -p payload.txt -T "application/json" -c 100 -n 500 http://127.0.0.1:8080/api

And this is what we get in the result:

Finished 200 requests


Server Software:        
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /api
Document Length:        34245 bytes

Concurrency Level:      50
Time taken for tests:   0.174 seconds
Complete requests:      200
Failed requests:        0
Total transferred:      6871200 bytes
Total body sent:        34000
HTML transferred:       6849000 bytes
Requests per second:    1149.91 [#/sec] (mean)
Time per request:       43.482 [ms] (mean)
Time per request:       0.870 [ms] (mean, across all concurrent requests)
Transfer rate:          38580.30 [Kbytes/sec] received
                        190.90 kb/s sent
                        38771.21 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.5      0       2
Processing:     6   37  10.1     40      57
Waiting:        3   37  10.2     40      57
Total:          6   38   9.7     40      58

Percentage of the requests served within a certain time (ms)
  50%     40
  66%     41
  75%     43
  80%     43
  90%     46
  95%     49
  98%     52
  99%     53
 100%     58 (longest request)

This is pretty impressive! Unfortunately I don't have a similar small app written in Elixir, so I'm going to take my original app which does much more than this little rust exercise, and I will just comment out all extra queries in Absinthe. This app runs on Phoenix, I didn't bother stripping down any plugs and middleware that are not related to GraphQL endpoint. Results are a bit less impressive, but expected:

Finished 200 requests


Server Software:        Cowboy
Server Hostname:        127.0.0.1
Server Port:            4000

Document Path:          /api
Document Length:        36245 bytes

Concurrency Level:      50
Time taken for tests:   1.384 seconds
Complete requests:      200
Failed requests:        0
Total transferred:      7298800 bytes
Total body sent:        34000
HTML transferred:       7249000 bytes
Requests per second:    144.50 [#/sec] (mean)
Time per request:       346.013 [ms] (mean)
Time per request:       6.920 [ms] (mean, across all concurrent requests)
Transfer rate:          5149.90 [Kbytes/sec] received
                        23.99 kb/s sent
                        5173.89 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.6      0       2
Processing:    39  310 117.2    307     690
Waiting:       36  310 117.2    307     690
Total:         40  311 117.1    308     690
WARNING: The median and mean for the initial connection time are not within a normal deviation
        These results are probably not that reliable.

Percentage of the requests served within a certain time (ms)
  50%    308
  66%    367
  75%    410
  80%    422
  90%    464
  95%    499
  98%    532
  99%    545
 100%    690 (longest request)

There is a chance that I messed up the test conditions here, otherwise Rust appears to be significantly faster. I might dig into researching how the hello world app shows much smaller performance gap, this could be either Absinthe or Ecto dragging it back. However, in my opinion the development with Elixir is much more pleasant, that this could potentially compensate for the performance disparity.

Todos:

Use dataloader when processing relations to avoid N+1 queries
Use dotenv for a proper database config