DEV Community: Sapan Diwakar

Find and Fix N+1 Queries Using AppSignal for a Phoenix App in Elixir

Sapan Diwakar — Tue, 05 Nov 2024 10:00:45 +0000

N+1 queries are a frequent issue in complex applications built with Elixir and Phoenix. These queries can silently degrade application performance, often going unnoticed until they've compounded into a significant problem.

They can substantially increase web page load times, as each additional query adds overhead to a database, consuming more time and resources. That's why it's crucial to detect and resolve N+1 queries to optimize production systems. It's not just about maintaining a seamless user experience; it's also about ensuring you maintain your Elixir application's scalability and efficiency.

Using AppSignal, you can identify N+1 queries in Phoenix applications, alongside a comprehensive suite of tools to monitor, diagnose, and rectify performance bottlenecks in Elixir projects.

Let's explore how N+1 queries happen, their impact on performance, and some strategies to detect and fix them in your Elixir application.

Understanding And Fixing N+1 Queries in Phoenix for Elixir

N+1 queries occur when an application retrieves a single database record, followed by an additional query for each related record.
In Phoenix applications, N+1 queries often emerge in the context of complex relationships and Ecto associations.

Even small mistakes in Ecto queries can lead to cascading N+1 issues, resulting in multiple round trips to a database, each fetching only a small amount of data.

Some common examples include:

Using Repo.all without a proper preload clause (this will not fetch associated records in the same query).
In GraphQL, when using Absinthe with Elixir, N+1 query issues can arise when resolving fields that require data from associated records.

Check out Avoiding N+1 Queries for Absinthe for an overview of this topic.

A Simple Example Using Ecto

For instance, consider a blog application where each post has many comments. A naive Ecto query might retrieve all posts and then run a separate query for each post's comments. This results in one query for the posts (N) and one query for each post's comments (+1), which is highly inefficient.

# Fetching posts without preloading comments
posts = Repo.all(Post)

# This will cause N+1 queries, as for each post, comments are fetched separately
posts |> Enum.each(fn post ->
  comments = Repo.all(from c in Comment, where: c.post_id == ^post.id)
  IO.inspect(comments)
end)

The above might sound like a contrived example — experienced developers are quite unlikely to do this. But it is meant to serve as a simplified scenario of how N+1 queries can creep into systems: any query inside a loop is a suspect. N+1 queries are usually hidden in plain sight, for example, behind a context function like Blog.list_comments(post_id: post.id) inside the loop.

Next, let's discuss a complex scenario.

Complex Situations Leading to N+1 Queries

Imagine a blog application displaying a feed of all recent posts and the count of comments (or likes) for each post.

A sample implementation could look like this:

# Load posts from subscribed authors
posts = Repo.all(Post)

# Load comments count per post
for post <- posts do
  comments_count = Repo.one(from c in Comment, where: c.post_id == ^post.id, select: count(c.id))
  render("post.html", post: post, comments_count: comments_count)
end

Here, the comments_count query causes an N+1 problem because we fetch each individual post's count. One might argue that we can just add comments to the preloads and be done with it. While that solves the N+1 query, it loads too much unnecessary data (we don't need all the comments yet, only the total number of comments) and might actually hurt loading times.

A better solution is to join the tables and use select to load the comments count within the posts query:

posts_with_counts =
  from(p in Post,
    left_join: c in Comment, on: c.post_id == p.id,
    group_by: [p.id],
    select: %{p | comments_count: count(c.id)}
  )
  |> Repo.all()

for post <- posts_with_counts do
  render("post.html", post: post, comments_count: post.comments_count)
end

To avoid and detect N+1 queries, developers must be vigilant when writing Ecto queries and templates.
Using preload correctly to fetch all necessary records in a single database query is essential.

Detecting N+1 Queries By Their Impact

Understanding the data access patterns of your application can help you anticipate and prevent N+1 issues before they arise.
One way to identify N+1 queries is to observe and analyze common bottlenecks in your app, including:

Increased Load Times: Each query takes time to execute, and when hundreds or thousands of them run sequentially, the cumulative effect leads to noticeable delays in content rendering.
Database Strain: Databases are designed to handle multiple queries efficiently, but an influx of unnecessary queries can strain the system, leading to slower response times for all users.
Server Resource Drain: A server's resources are finite, and handling a multitude of queries consumes more CPU and memory, potentially affecting other operations and leading to resource exhaustion.
Scalability Issues: As a user base grows, inefficient N+1 queries can prevent an application from scaling smoothly, requiring more hardware resources to handle the same workload.
Cost Implications: Increased server load and database usage can lead to higher operational costs, especially in cloud-based environments where resources are metered.

However, it is difficult to spot small differences in performance and then pinpoint the parts of your application that have caused such degradation.

The next sections will show how AppSignal can help you detect and fix N+1 queries, ensuring your application runs smoothly and efficiently.

Detecting N+1 Queries in Phoenix for Elixir Using AppSignal

Before detecting N+1 queries, we need to set up AppSignal in your Phoenix application. You can sign up for a free 30-day trial of AppSignal.

AppSignal provides an Elixir package that integrates seamlessly with Phoenix applications. The AppSignal for Elixir setup process involves adding the Elixir package to your project's dependencies and configuring it with your AppSignal Push API key. Once installed, AppSignal starts monitoring your application's performance, including database query patterns.

Analyzing Elixir Data with AppSignal

AppSignal's instrumentation for Phoenix and Ecto is designed to provide detailed insights into your application's database interactions. It automatically tracks database query times, helping you spot inefficiencies. With AppSignal's instrumentation in place, detecting N+1 queries becomes a matter of analyzing the collected data.

Use Slow Queries to Find N+1 Queries

AppSignal's Slow Queries dashboard breaks down web requests, showing the slowest queries and potential bottlenecks. A series of similar queries within a single web request is a strong indicator of an N+1 query problem.

For example, if you see repeated queries fetching comments for different posts while a blog page is being rendered, you've likely encountered an N+1 issue. AppSignal provides context, including specific database calls, making it easier to pinpoint the exact location in your code where the issue originated.

We can see that the first query had almost 95% impact on all our queries executed through Ecto.
In a real-world app, this number might be lower, as there can be hundreds of unique queries. However, any outlier that's highlighted here is a great candidate for analysis.

💡 Note: The "impact" of a query on an application is based on its usage compared to other queries.

Another metric to consider here is the high throughput of 720.
Throughput is the total number of queries that were executed in a specified time window.

Let's check out the full details of the query:

SELECT c0."id", c0."body", c0."post_id", c0."user_id", c0."inserted_at", c0."updated_at", c0."post_id" FROM "comments" AS c0 WHERE (c0."post_id" = $1) ORDER BY c0."post_id"

Since the query is targeting a single post, it is quite likely an N+1 query.

Trace N+1 Queries with the Event Timeline

AppSignal's Event Timeline is also particularly useful for finding and tracing N+1 queries.
It visualizes a sequence of database calls during a web request, allowing you to identify the hallmark successive database queries that characterize N+1 issues.

Here's an example event timeline for a page that has an N+1 query issue:

We can see that many quick queries are being performed.
Hovering over query.ecto also shows the exact query that was performed to help us pinpoint which query is the culprit.

Another good indication of a possible issue is when the ecto time of an event is abnormally high.
For example, in this case, we can see that Ecto was the major time-hog:

Addressing Detected N+1 Queries

Once you've identified an N+1 query with AppSignal, the next step is to address it.
This typically involves optimizing your Ecto queries to preload associated records.

AppSignal's detailed metrics allow you to compare performance before and after the changes, giving you concrete feedback on the impact of your optimizations.

And that's it!

Wrapping Up

Whether you're a seasoned developer or new to Phoenix, understanding the nuances of N+1 queries and leveraging AppSignal's capabilities will empower you to build faster, more reliable applications.

Remember, the key to maintaining a performant application is not just fixing issues as they arise, but continuously monitoring and improving your codebase with the help of powerful tools like AppSignal.

Happy coding!

P.S. If you'd like to read Elixir Alchemy posts as soon as they get off the press, subscribe to our Elixir Alchemy newsletter and never miss a single post!

Scaling Your Phoenix App in Elixir with FLAME

Sapan Diwakar — Wed, 18 Sep 2024 09:18:38 +0000

When you build an app, you'll often find that certain tasks do not require user interaction and are better performed in the background. Elixir provides excellent primitives, such as Task.async, to offload these tasks from the main user pipeline. Additionally, libraries like Oban offer more control over background tasks when needed.

There's also FLAME, which the core Phoenix team is developing to offer a scalable solution for offloading intensive tasks to remote machines.

We will compare these methods and see how FLAME stands out.

But first, let's delve into how FLAME works and how it can help you scale your Phoenix application.

Understanding FLAME for Phoenix

FLAME stands for Fleeting Lambda Application for Modular Execution. It is similar to Task.async, allowing you to run any block of code, but with the added benefit of executing it on a separate node. Depending on your configuration, FLAME can automatically manage infrastructure, spawning or scaling down nodes as needed.

To illustrate how FLAME works, let's consider an example where we need to find the SHA-256 hash of a file stored on Amazon S3. Calculating the hash for a large file can prove slow due to file size or network latency. By offloading this task to a background worker with FLAME, we can improve the performance and responsiveness of our main application.

Here’s how you can do it:

FLAME.call(MyApp.BackgroundRunner, fn ->
  ExAws.S3.download_file(bucket, file_path, :memory)
  |> ExAws.stream!()
  |> Enum.reduce(:crypto.hash_init(:sha256), fn chunk, acc ->
    :crypto.hash_update(acc, chunk)
  end)
  |> :crypto.hash_final()
  |> Base.encode16()
end)

This is similar to Task.async and Task.await, with the key difference being that it runs on a separate node. When the checksum is ready, it returns the result to the main node. We'll discuss configuration options and available functions later in the post.

So, how is this different from any background job processing framework (e.g., Oban)?

Built-in Scaling: FLAME has built-in support for scaling. It can automatically spawn new nodes when new tasks come in and scale down to zero (configurable) when no tasks are in the queue.
Minimal Boilerplate: Unlike other frameworks, FLAME does not require extensive boilerplate code. You simply wrap your task inside FLAME.call or FLAME.cast.
Awaiting Results: In most job frameworks (including the free version of Oban), you cannot await the result of background tasks. FLAME, however, supports this feature, allowing you to wait for a task's completion and retrieve the result.

FLAME in Action

In the previous section, we saw how easy it was to run a piece of code on a separate node using FLAME. Let's pull back a little and see how to integrate FLAME inside an existing Phoenix app.

Install FLAME

Add the dependency in mix.exs:

{:flame, "~> 0.1.12"}

Start a FLAME Pool

FLAME.Pool is the main GenServer provided by FLAME that manages the scaling of nodes inside your app. It also schedules tasks and delivers results to each task's respective nodes.

Add FLAME.Pool to your application's supervision tree by updating the application.ex:

defmodule MyApp.Application do
  use Application

  @half_hour_millis 1_800_000

  @impl true
  def start(_type, _args) do
    children =
      [
        # ...
        # The BackgroundRunner pool controlled by FLAME
        {FLAME.Pool, name: MyApp.BackgroundRunner, min: 0, max: 5, max_concurrency: 5, idle_shutdown_after: @half_hour_millis},
      ]
    opts = [strategy: :one_for_one, name: MyApp.Supervisor]
    Supervisor.start_link(children, opts)
  end
end

The name option defines the pool name to be used in calls to FLAME later in the application. This allows you to define several different pools with different configurations depending on the tasks that you want to achieve.

For example, for nodes that handle hash computation, you might want different concurrency settings than the nodes that handle more complex tasks, like video encoding. Check out all the available options for the pool. The most important ones that you will commonly use are:

:min - The minimum number of nodes to start. You can configure this to zero to support pools that spawn a node only when there is a task, and then scale down when there are no pending tasks. This is especially useful in pre-production environments to save infrastructure costs.
:max - The maximum number of nodes at a time.
:max_concurrency - The maximum number of concurrent executions on a node.
:timeout - Default timeout for functions. This can also be set during individual calls (using FLAME.call with the timeout option).
:idle_shutdown_after - The number of seconds after which an idle node is shut down (only if there are more than the min number of nodes).

Configure FLAME Backend

FLAME Backend is the component responsible for starting up new nodes, connecting them to parent nodes, and running functions. By default, FLAME ships with the FlyBackend. If you run your application on Fly, configuring FLAME is very simple. Just update your config.exs or runtime.exs if you use Elixir releases:

config :flame, :backend, FLAME.FlyBackend

config :flame, FLAME.FlyBackend,
  token: System.fetch_env!("FLY_API_TOKEN"),
  cpu_kind: System.get_env("FLAME_CPU_KIND", "shared"),
  memory_mb: System.get_env("FLAME_MEMORY_MB", "1024") |> String.to_integer()

To access the Fly API for spawning or destroying machines, you need a token from Fly. You can optionally configure the cpu_kind, memory, and cpus for the spawned nodes. Check out the full list of supported options in the FlyBackend docs.

There is also a FLAMEK8sBackend available if you are running on Kubernetes. If you are not using Kubernetes, other platforms have no out-of-the-box support. However, you can refer to the FLAME.FlyBackend code and create a similar backend for your platform.

Running Tasks with FLAME

FLAME provides two main functions for running tasks on other nodes:

FLAME.call/1: This function calls a task on a remote node and waits for the result. It's useful when you need to run tasks in the background but still require a result. Example: A user requests a 10,000,000th Fibonacci number. You can run the computation on another machine to avoid blocking web server resources while the user waits for the result.
FLAME.cast/1: This function calls a task on a remote node without waiting for a result. It's useful when a result isn't needed immediately and you don't want to block the user pipeline. Example: After a user uploads a file, you want to update its checksum in the records. This can be done in the background without making the user wait.

By default, the spawned processes on the remote node are linked to the parent process, preventing orphaned tasks on remote nodes if the parent process is killed or dies. However, for some background tasks (e.g., file checksum generation), it might be useful to continue running a task even if the parent process is terminated.

Both FLAME.call/2 and FLAME.cast/2 support a link option that can be set to false to achieve this.

Deploying FLAME

You don't need anything special to deploy FLAME as long as you have configured a backend with all the required properties. FLAME starts your full application supervision tree on the remote node. Some parts of the application might not be necessary on a worker node. To control this, you can use FLAME.Parent.get/0 to determine if an application is running on the main node or a child node.
Update application.ex to add children to your supervision tree only if they are on the main node (i.e., if FLAME.parent.get() is nil):

defmodule MyApp.Application do
  use Application

  @impl true
  def start(_type, _args) do
    flame_instance? = not is_nil(FLAME.Parent.get())
    children = [
      # ...
      {FLAME.Pool, name: MyApp.BackgroundRunner, min: 0, max: 5, max_concurrency: 5, idle_shutdown_after: @half_hour_millis},
      !flame_instance? && MyAppWeb.Endpoint
    ]

    opts = [strategy: :one_for_one, name: MyApp.Supervisor]
    Supervisor.start_link(children, opts)
  end
end

Technical Deep Dive into FLAME

Internally, FLAME leverages Elixir's powerful Node.spawn_monitor/4 function for spawning processes on remote nodes. This, coupled with BEAM's closure behavior, forms the core of FLAME's implementation.

Let's delve into what occurs under the hood when you execute FLAME.cast or FLAME.call:

The request is dispatched to a pool of runners.
If a runner is readily available (based on defined constraints like min, max, etc.), it spawns and monitors the process on the remote node.
- Upon successful execution, the result is returned or discarded depending on the operation used.
- Additionally, it monitors the process according to the timeout configuration and terminates it if necessary.
- If the remote node crashes (e.g., due to memory exhaustion), the parent process is notified or terminated as per the configuration.
If a process cannot be accommodated on an existing remote node, FLAME tries to spawn a new node (using the configured backend) within the specified limits.
- Once the node is spawned, it follows the same steps as mentioned in (2).
- If spawning a new node fails (e.g., because the maximum limit is reached), the task is queued until resources become available.
Regardless of specific user calls, FLAME autonomously manages idle nodes based on the configuration, shutting them down as needed using the configured backend.

Understanding Closures

Closures play a pivotal role in FLAME's operation, and understanding them is essential in BEAM programming. A closure captures its enclosing environment, including variables from the outer scope. When a closure is defined, it retains references to the variables it "closes over", thus preserving the state of its enclosing process. This behavior is crucial for maintaining consistency, even in scenarios where a process crashes and restarts.

However, when transmitting closures across different nodes in BEAM, the code on all nodes must match precisely. The Fly backend addresses this requirement well, as deployments on Fly rely on Docker images of the released code. This ensures uniformity between the parent node and the remote node, facilitating seamless execution of FLAME.

Leveraging Files as Processes

Things get more interesting when we explore the concept of treating files as processes. In Elixir, opening a file spawns a new process. Writing to a file is akin to sending messages to the process handling the file descriptor. This behavior extends to functions like File.stream! and all other file operations. Consequently, we can extend FLAME's capabilities to handle scenarios such as computing checksums of files stored on S3 or even supporting user-uploaded files directly on the web server.

Here's a code sample:

stream = File.stream!(file_path) # this runs on the web server
FLAME.call(MyApp.BackgroundRunner, fn ->
  # this runs on the remote machine
  stream
  |> Enum.reduce(:crypto.hash_init(:sha256), fn chunk, acc ->
    :crypto.hash_update(acc, chunk)
  end)
  |> :crypto.hash_final()
  |> Base.encode16()
end)

In this scenario, the file stream is initiated on the source machine, while the checksum computation is offloaded to the remote worker.
This setup capitalizes on Elixir and BEAM's handling of closures and processes. However, it's worth noting that a more efficient approach would involve establishing a shared volume accessible from both nodes. A shared volume minimizes resource usage and enhances performance. This is in contrast to utilizing the stream from the main node, which still consumes resources to transmit data to the remote node.

Comparing FLAME With Other Approaches

Let's now see how FLAME stacks up against some alternative approaches.

Running Background Tasks on the Same Node

Using Task.async and similar functions, your tasks run on the same node as your web server. This approach works well for quick, lightweight tasks. However, during periods of heavy load, these background tasks can compete with your web server for resources, potentially slowing down your application's response time.

Using Oban for Elixir to Get More Control

Oban is a powerful library that allows you to manage background jobs with more granularity. It enables you to:

Define dedicated Oban Workers.
Configure job queues.
Set up a job storage backend.

Oban also supports running these tasks on dedicated nodes, which can help reduce the load on your main web server. However, setting up Oban involves significant boilerplate code. In its free version, it does not support automatic scaling of the physical nodes running the jobs.

Achieving Infinite Scale with Serverless Functions

For truly infinite scalability, you can use external serverless functions like AWS Lambda, Google Cloud Functions, or Azure Functions. These services allow you to run background tasks independently of your main application infrastructure. However, they come with their own set of challenges:

Significant boilerplate and context switching for developers.
Synchronization issues between third-party services and your application code.
Potential latency and cold start problems.

FLAME: A Summary

As we have seen, FLAME provides a robust way to handle complex background tasks at scale within your Phoenix app. It aims to simplify the setup process and reduce boilerplate code, offering an efficient and scalable solution. All of this comes without the need to context switch — you can call FLAME code from within your app.

By using FLAME, you can:

Easily offload tasks from the main user pipeline.
Manage and scale background jobs without extensive configuration.
Improve your application's performance and responsiveness during heavy loads.

Wrapping Up

In this post, we've explored how to scale your Phoenix application using FLAME. We've delved into how FLAME stands out by offloading tasks to remote nodes. It also offers built-in scaling with minimal boilerplate code. We've compared FLAME with other methods, too, like Task.async, Oban, and external serverless functions, highlighting its unique advantages.

Ultimately, FLAME helps you build more robust and scalable applications by leveraging Elixir's strengths in concurrency and distributed computing, all while keeping your development process straightforward and intuitive.

Happy coding!

P.S. If you'd like to read Elixir Alchemy posts as soon as they get off the press, subscribe to our Elixir Alchemy newsletter and never miss a single post!

Deep Diving Into the Erlang Scheduler

Sapan Diwakar — Tue, 07 May 2024 13:59:25 +0000

Erlang is renowned for its remarkable fault tolerance and high concurrency. Erlang's scheduler efficiently handles many lightweight processes. The scheduler plays a crucial role in managing processes, concurrency, and system resources, efficiently coordinating these elements to help Erlang maintain fault tolerance and support high levels of concurrency in its applications.

This post will dissect some of the scheduler's key components and shed light on how it works internally.

Let's get started!

Processes in Erlang

Erlang processes are lightweight, independent units of execution managed by the Erlang runtime system. They are created and scheduled by the Erlang virtual machine (BEAM), and each Erlang process has its own memory space. These should not be confused with operating system processes or threads.

OS processes are entities managed by the OS and typically have more overhead in terms of memory and resources, as well as inter-process communication. While threads are lighter than OS processes, they are still heavier than a typical Erlang process and share a common memory space within a process. Communication is usually easier between threads of the same process but still requires synchronization mechanisms.

On the other hand, the Erlang VM (BEAM) is capable of spawning several lightweight processes with independent memory space and can communicate easily using message passing. The scheduler inside the VM manages processes, allocates resources to processes, and context-switches between them.

Erlang Scheduler Architecture — Preemptive Scheduling

In a single-core setup, only one process can occupy the CPU core at any given time. To emulate a concurrent system, the scheduler employs a preemptive, priority-based scheduling mechanism (don't worry, we will explore what this means soon) that rapidly switches between available processes to create the illusion that all processes are executing simultaneously. The Erlang Virtual Machine (BEAM) schedules processes to run sequentially, with one process running for a duration, being suspended, and then allowing another process to take its turn.

This process management strategy is characteristic of concurrency and does not entail true parallelism (which is not possible on a single-core system). Tasks appear to run concurrently due to fast context switching, although they actually execute sequentially on a single core.

To identify processes for potential swapping, Erlang introduces the concept of "reductions". In Erlang, a reduction represents a unit of work performed by BEAM, encompassing fundamental operations such as function application, arithmetic calculations, or message passing. The scheduler keeps track of the reductions executed by each process, preempting a process when it reaches a certain reduction count, thereby allowing another process to run.

Reductions

The idea of "reduction" in Erlang is inherited from its Prolog ancestry. In Prolog, every execution step is termed a goal-reduction, involving breaking down a logic problem into individual components and solving each part accordingly.

To promote fairness among processes, Erlang's preemptive scheduling relies on reductions rather than time slices. If a process exhausts its allocated reductions, it can be preempted, even if its execution isn't complete. This approach prevents a single process from monopolizing the CPU for an extended period, fostering fairness among concurrent processes. By using reductions as the foundation for preemption, Erlang mitigates the risk of processes starving for CPU time. This design ensures that every process, irrespective of its workload, is periodically allowed to execute.

Moreover, reductions are flexibly applied based on the type of operation a process is performing. For example, certain operations, such as I/O operations, may consume various reductions. This adaptability allows the scheduler to effectively handle different types of operations.

In other languages, traditional blocking I/O operations can lead to inefficient resource utilization, as threads might be blocked while waiting for I/O to complete. Erlang's asynchronous and non-blocking I/O model allows processes to continue executing other tasks while waiting for I/O operations to complete. This minimizes the impact of blocking operations on overall system performance.

Priority

Each process in Erlang can have a priority value that decides how often the scheduler will execute that process. A process priority can be set using the Process.flag/2 (or process_flag/2 on Erlang) function call:

iex> Process.spawn(
  fn ->
    Process.flag(:priority, :high)
    # ...
  end,
  [:link]
)

There are 4 priority levels: low, normal, high, and max. max is reserved for internal use in Erlang and should not be used in application code. Processes on each priority level get a separate run queue and are scheduled in the normal round-robin fashion as described above.

Except low and normal, Erlang executes the processes of each priority queue exclusively. This means that if there is a process in the max priority queue, only max priority processes will be executed, and all other processes will be blocked. Similarly, if there is a process in the high priority queue, low and normal processes will not be executed until all processes from the high priority queue are executed (or are non-runnable).

low and normal queues behave slightly differently — the processes inside both queues are interleaved such that normal priority processes are executed more often than low priority ones, but normal processes do not block the execution of low priority processes.

Due to the blocking behavior of high priority processes, they should be used very rarely and only for short-lived tasks. Overusing high priority processes is bound to lead to outages and affect the responsiveness of an application, as all other regular OTP processes run on normal priority.

Another point that's important here is that Erlang places no restrictions on communication between different priority levels of processes. So a high-priority process can wait for a message from a lower-priority process. This is allowed, but will effectively lower the priority of the high-priority process.

Running on Multiple Cores

Up to this point, we've explored how the scheduler orchestrates processes within a single-core system. However, in a multi-core environment, where additional resources are available for parallel processing, the Erlang VM creates a dedicated "run queue" for each available core.
This enables true parallelism, as multiple processes can run simultaneously (one on each available core). Within each run queue, all processes adhere to the preemptive scheduling mechanism we discussed earlier.

Typically, Erlang processes share the same run queue as their parent process, and a work-stealing algorithm may come into play to ensure load balancing. For instance, if there are two cores in the system and one consistently handles busy processes while the other remains relatively idle, the Erlang schedulers on both cores engage in periodic communication. This communication facilitates the movement of processes from the heavily loaded core to the less busy one, ensuring a more equitable distribution of workloads across both cores.

In the broader context, beyond Erlang's internal run queues, the operating system plays a role in managing the scheduling of threads onto OS-level cores. This implies that processes not only experience swapping within the Erlang run queue but also may undergo a complete context switch or be moved to a different core at the OS level.

Note that, because of the concept of work-stealing inside the Erlang VM, it is usually beneficial to run a single Erlang application instance on multiple cores rather than running separate instances of the same application on different cores of the same machine. In a single instance, the schedulers dedicated to each core can better communicate between them to share the load equitably compared to a multi-node cluster where schedulers cannot share process load (even if all of that cluster's nodes are on the same physical machine).

Performance and Optimization

Erlang's scheduler takes out most of the complexities involved in building a concurrent system. It automatically frees the developer from having to think about things like lock contention, thread overhead, and load balancing by handling these issues out of the box with its preemptive scheduling algorithm.

Erlang provides various scheduler-related parameters that can be tuned for optimal performance. Parameters like +S (scheduler count) and +P (maximum number of processes) allow you to configure the number of scheduler threads and processes.

For example, you can start Erlang with erl +S Schedulers:SchedulerOnline to control the number of scheduler threads. By default, Erlang uses the number of CPU cores to identify these values automatically. Note that while both Scheduler and SchedulerOnline accept values up to 1024, starting more schedulers than the number of CPU cores does not have any positive benefits for an app.

Another possible step to fine-tune performance is to control the priorities of processes, as we've discussed. It is indeed possible to execute certain high-priority tasks in Erlang.

Nevertheless, this comes with an inherent risk of potentially rendering a system unresponsive and increasing latency, as processes with a high priority may block all other normal/low-priority processes. Conversely, marking tasks identified as intentionally low priority can be advantageous to prioritize other processes above them.

So be careful and use your judgment.

Wrapping Up

In this post, we've seen that the Erlang scheduler stands as a cornerstone in Erlang's architecture, fostering fault tolerance, concurrency, and adaptability. Its preemptive and dynamic nature equips developers to build resilient, highly concurrent systems capable of handling failures and utilizing resources optimally. Understanding the intricacies of the Erlang scheduler can empower you to craft scalable and robust distributed applications.

If you are interested in learning more about the scheduler, I recommend checking out the Scheduling chapter in The BEAM Book and Processes from the Erlang Efficiency Guide.

Happy coding!

P.S. If you'd like to read Elixir Alchemy posts as soon as they get off the press, subscribe to our Elixir Alchemy newsletter and never miss a single post!

P.P.S. AppSignal has an integration for Erlang — check it out.

A Deep Dive into Mutations with Absinthe

Sapan Diwakar — Tue, 11 Jul 2023 14:43:31 +0000

In the last two posts of this series, we saw how easy it is to integrate Absinthe into your app to provide a GraphQL API for querying data. We also shared some useful tips for building and maintaining large schemas and optimizing queries.

This post will show how we can provide an API to create GraphQL mutations with Absinthe for Elixir.

Let's get started!

A Note on Queries Vs. Mutations in GraphQL

GraphQL places a clear distinction between queries and mutations. Technically, we can implement any query to write data to the server. But GraphQL convention clearly separates them into different top-level mutation types.

Mutations in GraphQL

First, let’s see what a typical mutation looks like:

mutation CreatePost($post: PostCreateInput!) {
  createPost(post: $post) {
    post {
      id
    }
    errors
  }
}

This is a mutation to create a new post. It accepts a variable named post of type PostCreateInput (which is required because ! follows the type name). This variable is passed into the createPost field inside the top-level mutation type.

The result of that mutation is a post (which can have further selections) and an errors array. Note that we have named the mutation CreatePost but that is just a client-side identifier. Here is what a sample response from this mutation looks like:

{
  "data": {
    "createPost": {
      "post": {
        "id": "1"
      },
      "errors": null
    }
  }
}

Input Objects with Absinthe for Elixir

Let’s see how we can implement this with Absinthe. The first thing we need is an input_object that can be used as a variable for the mutation. Let’s create one now:

defmodule MyAppWeb.Schema do
  use Absinthe.Schema

  enum :post_state_enum do
    value :active
    value :draft
  end

  input_object :post_create_input do
    field :title, non_null(:string)
    field :author_id, non_null(:id)
    field :body, non_null(:string)
    field :state, :post_state_enum, default_value: :draft
  end
end

Here, we use the enum macro to create an enum named post_state_enum with two possible values — draft and active.

We then use the input_object macro to define an input object named post_create_input which has four fields. Note that the definition of fields changes slightly from what we would use in an output type. For example, for fields inside an input object, we can add a default_value to a non-required field. Absinthe will fill the field in if the user doesn’t provide a value.

Defining Mutations in Absinthe

Next, let’s define our mutation type in the schema. All individual mutations (like createPost) will be fields inside this mutation:

defmodule MyAppWeb.Schema do
  use Absinthe.Schema

  mutation do
    field :create_post, non_null(:post_mutation_result) do
      arg :post, non_null(:post_create_input)
    end
  end
end

Here, we use the mutation..do..end block to define the base mutation type. And inside it, we define a field named create_post. This takes a single argument named post of the post_create_input type defined above. The result of this field is of type post_mutation_result. We haven’t defined it yet, so let’s do that now.

object :post_mutation_result do
  field :post, :post
  field :errors, list_of(non_null(:string))
end

Now on to the interesting part — actually performing the mutation operation. This is similar to what we already did for queries. We will define a resolver to handle it.

If you remember from our previous post, a 3-arity resolver receives the parent object, the attributes, and an Absinthe.Resolution struct. Let’s define that first to create the post:

defmodule MyAppWeb.Resolvers.PostResolver do
  def create_post(_parent, %{post: attrs}, _resolution) do
    case MyAppWeb.Blog.create_post(attrs) do
      {:ok, post} ->
        {:ok, %{post: post}}
      {:error, changeset} ->
        {:ok, %{errors: translate_changeset_errors(changeset)}}
    end
  end
end

In the resolver, we use the post attributes to create a post. If that is successful, we respond with the post object (the result map should correspond to the mutation's result type — post_mutation_result, in our case). On an error, we respond with the errors. Note that translate_changeset_errors is a custom helper function that translates Ecto.Changeset errors into an array of strings.

With the resolver in place, we can now plug it into our schema to create a post:

defmodule MyAppWeb.Schema do
  use Absinthe.Schema

  mutation do
    field :create_post, :post_mutation_result do
      arg :post, non_null(:post_create_input)

      resolve &MyAppWeb.Resolvers.PostResolver.create_post/3
    end
  end
end

Now, when we execute the above mutation against our schema, Absinthe will call the create_post function. The return value from the resolver's {:ok, value} tuple will then be used as the mutation's result and returned to the user.

Authorization in Your Elixir App with GraphQL and Absinthe

Up until now, we have been discussing everything as if we're using an open public API. But in most apps, this is not how things work. Often, certain APIs are only available to logged-in users, and this is even more important in the case of mutations. Let’s see how we can add authorization to our API.

First, we will need to identify the users making requests. In the first post of this series, we used Absinthe.Plug to handle all the requests coming into the /api endpoint using the MyAppWeb.Schema schema. This doesn’t handle any user authorization for us.

Absinthe provides a context concept containing shared information that might be useful for all queries and mutations. This is passed to all resolver functions that accept an Absinthe.Resolution struct inside the context field.

Let’s fix that first to identify users before a request is forwarded to Absinthe.

An Example Using Absinthe Context

Update the router in your app to execute an additional plug before forwarding a request:

defmodule MyAppWeb.Router do
  use MyAppWeb, :router

  pipeline :api do
    plug :accepts, ["json"]
  end

  pipeline :graphql do
    plug MyAppWeb.Schema.Context
  end

  scope "/" do
    pipe_through [:api, :graphql]

    forward "/api", Absinthe.Plug, schema: MyAppWeb.Schema
  end
end

We've added a new MyAppWeb.Schema.Context plug to the requests. Let’s implement it to put a user in the Absinthe context.

defmodule MyAppWeb.Schema.Context do
  @behaviour Plug

  import Plug.Conn

  #...

  def call(conn, _default) do
    Absinthe.Plug.put_options(conn, context: absinthe_context(conn))
  end

  def absinthe_context(conn) do
    %{conn: fetch_query_params(conn)}
    |> put_user()
  end
end

Note: I have intentionally left out some app-specific parts of the plug. Here is the full code of that module if you are interested.

An interesting part of the code in the above code block is the use of Absinthe.Plug.put_options/2 to set values that Absinthe.Plug will pass to Absinthe when executing the query/mutation. This is similar to how we use Plug.Conn.assign to assign something on the conn.

Internally, Absinthe.Plug puts a private assign inside the conn and passes it as the third parameter to Absinthe.run/3 when executing the document. The context option we use above is a special value that Absinthe will then pass to all resolvers inside the Absinthe.Resolution struct.

Now let’s update our create_post/3 resolver function to use this context and deny the request if the user isn’t present.

defmodule MyAppWeb.Resolvers.PostResolver do
  def create_post(
    _parent,
    %{post: attrs},
    %Absinthe.Resolution{context: %{user: nil}}
  ) do
    {:error, "unauthorized"}
  end

  def create_post(_parent, %{post: attrs}, %Absinthe.Resolution{}) do
    case MyAppWeb.Blog.create_post(attrs) do
      {:ok, post} ->
        {:ok, %{post: post}}
      {:error, changeset} ->
        {:ok, %{errors: translate_changeset_errors(changeset)}}
    end
  end
end

If a resolver function returns an error tuple, Absinthe will not resolve that field and adds an error to the response.

This is just one example of how to use Absinthe context. There are many more advanced potential use cases. For example, you might want to automatically set a user’s id as the post author, instead of accepting an author_id in the post_create_input.

Middleware in Absinthe for Elixir

We have used context to authorize a user during resolution. But if we have many fields to handle, this soon becomes too cumbersome. Absinthe provides middleware to handle such cases.

For example, let's assume that several fields require a user to be present when performing an operation. Instead of updating the resolver function for all those fields, wouldn’t it be better if we could just write middleware MyAppWeb.Schema.RequireUser in the field definition?

We can do that using the middleware/2 macro:

defmodule MyAppWeb.Schema do
  use Absinthe.Schema

  mutation do
    field :create_post, :post_mutation_result do
      arg :post, non_null(:post_create_input)

      middleware MyAppWeb.Schema.RequireUser

      resolve &MyAppWeb.Resolvers.PostResolver.create_post/3
    end
  end
end

The argument to middleware is a module that implements the Absinthe.Middleware behaviour. The module should start a call/2 function that receives an Absinthe.Resolution struct as the first argument.

The second argument is whatever is passed to the middleware/2 macro. We don’t pass anything above, so it's nil by default. The call/2 function should return an updated Absinthe.Resolution struct.

Implement `RequireUser` Middleware

Let’s implement the RequireUser middleware now to stop requests if a user is not present:

defmodule SpendraWeb.Schema.RequireUser do
  @behaviour Absinthe.Middleware

  def call(%Absinthe.Resolution{state: :resolved} = resolution, _config), do: resolution

  def call(%Absinthe.Resolution{context: {user: nil}} = resolution, _config) do
    Absinthe.Resolution.put_result(
      resolution,
      {:error, "You must be logged in to access this API"}
    )
  end

  def call(%Absinthe.Resolution{} = resolution, _config), do: resolution
end

The middle clause is the most important. Here, we receive a context with a nil value for the user. We use Absinthe.Resolution.put_result to mark that the resolution is now complete. It does two things:

Marks the state of the resolution as resolved.
Puts the specified value as the resolution result. Here we use an error tuple to signal that this is an erroneous response.

We also have a special clause at the beginning that checks for the resolution's existing state. If you are using multiple middlewares in your app, this is important. It avoids a middleware running on a resolution that has already been resolved.

Finally, if a resolution's state is not already resolved and we have a user in the context, we just return the original resolution struct without any modifications. This allows execution to proceed.

Chaining Middleware

The great thing about middleware is that it can be chained. For example, we might have several user roles and only want authors to be able to create posts. We can use multiple middleware clauses that each perform a single task before the final resolution.

field :create_post, :post_mutation_result do
  middleware MyAppWeb.Schema.RequireUser

  middleware MyAppWeb.Schema.RequireAuthor

  resolve &MyAppWeb.Resolvers.PostResolver.create_post/3
end

In fact, resolve itself is just a middleware which roughly translates to middleware Absinthe.Resolution, unquote(function_ast).

Another important point about middlewares is that they are executed in the order they are defined in a field. So in the above example, first RequireUser will be executed, followed by RequireAuthor and, finally, the resolver.

It is also possible to use middleware after a resolve call — for example, to handle resolution errors.

Wrap Up

In this post, we created GraphQL mutations with Absinthe. We also added a custom plug to put shared information in an Absinthe context and defined middleware to handle common tasks like authorization.

In the next and final part of this series, we will discuss advanced GraphQL use cases like subscriptions (including how to implement and deliver subscriptions over a WebSocket connection).

Happy coding!

P.S. If you'd like to read Elixir Alchemy posts as soon as they get off the press, subscribe to our Elixir Alchemy newsletter and never miss a single post!

Absinthe for Large Elixir Applications

Sapan Diwakar — Tue, 13 Jun 2023 10:32:52 +0000

In our introduction to Absinthe, we covered the basics of Absinthe and GraphQL for an Elixir application.

Now we'll dig deeper and see how we can customize Absinthe for larger-scale Elixir applications.

Let's get going!

Defining Resolvers for a Large Elixir App

We've seen that creating a query and returning a result in Absinthe is really easy. But if you have big resolution logic, the schema can soon get very heavy. It's common practice to define resolver functions in a separate module for large apps using Absinthe.

First, create a module that defines functions acting as field resolvers:

# lib/my_app_web/schema/resolvers/blog.ex
defmodule MyAppWeb.Schema.Resolvers.Blog do
  def post(%{id: post_id}, _resolution) do
    # complex resolution logic here
    # post = ...
    {:ok, post}
  end
end

Then, update your schema to use this resolver:

defmodule MyAppWeb.Schema do
  use Absinthe.Schema

  query do
    field :post, :post do
      arg :id, non_null(:id)
      resolve &MyAppWeb.Schema.Resolvers.Blog.post/2
    end
  end
end

This also allows you to unit-test that resolution logic separately from your GraphQL integration tests. We will discuss more about testing schemas later on in this series.

The resolvers additionally help you to reduce code duplication at several places in your schema. For example, let's say you need to expose a field under a different name from what is defined on the struct.

We can build the object like this:

object :post do
  # ...
  field :published_at, :datetime do
    resolve fn %Post{} = post, _args, _resolution ->
      {:ok, post.inserted_at}
    end
  end
end

If you find yourself doing that at several places in the schema, it might be better to create a resolver:

defmodule MyAppWeb.Schema.Resolvers.Base do
  @doc """
  Returns a resolver function that returns the value at `field` from `parent`
  """
  def alias(field) do
    fn parent, _args, _resolution -> {:ok, Map.get(parent, field)} end
  end
end

And then use it in your object like this:

object :post do
  # ...
  field :published_at, :datetime, resolve: Resolvers.Base.alias(:inserted_at)
end

Avoiding N+1 Queries in Elixir

Let’s get back to our schema, but with a query that returns a list of posts:

defmodule MyAppWeb.Schema do
  use Absinthe.Schema

  object :post do
    # ...
    field :author, non_null(:author),
      resolve: &Resolvers.Blog.post_author/3
  end

  query do
    field :posts, non_null(list_of(:post)),
      resolve: &Resolvers.Blog.list_posts/2
  end
end

Here is the full Resolvers.Blog if you are interested.

Now, perform a query that includes the author of each post:

query {
  posts {
    id
    author {
      id
      firstName
    }
  }
}

When this query is executed, we first fetch all posts from the database. Then we fetch the author by their id for each post — that's not very efficient.

But that’s an easy problem to solve. We can just preload the authors in Resolvers.Blog.list_posts/2.

However, what if someone makes a query that doesn’t need an author? We will still be unnecessarily fetching all authors, defeating the whole purpose of having a composable query like this.

One possible solution is to be smart when resolving the initial list of posts and load authors only when the user has selected the author field in the query. If you remember, we get an Absinthe.Resolution struct as the last argument to the resolver function.
resolution.definition.selections contains all the selected fields (Absinthe.Blueprint.Document.Field structs).

We can check if the author was selected here, and preload it right there:

defmodule Resolvers.Blog do
  def list_posts(%{}, %Absinthe.Resolution{} = res) do
    posts = Blog.list_posts()

    res.definition.selections
    |> Enum.any?(&(&1.name == "author"))
    |> if do
      {:ok, Repo.preload(posts, :author)}
    else
      {:ok, posts}
    end
  end
end

That works, but if you have many fields (or several nested levels), it can soon become too cumbersome. This is where dataloader can help.

Dataloader to the Rescue!

Dataloader provides an efficient way to load linked data by batching queries. It does this by first performing a full pass through the query resolution phase, collecting all the ids of objects to be loaded. Dataloader then loads them all in one go instead of making a request to the database for each of them separately.

It’s a separate dependency, so first add it to your mix.exs inside deps.

You then need a one-time setup in your schema:

defmodule MyAppWeb.Schema do
  use Absinthe.Schema

  # ... schema definition here ...

  # Add dataloader to the context
  def context(ctx) do
    loader =
      Dataloader.new
      |> Dataloader.add_source(Blog, Blog.data())
      # ... add other sources here ...

    Map.put(ctx, :loader, loader)
  end

  # Add dataloader to the plugins
  def plugins do
    [Absinthe.Middleware.Dataloader] ++ Absinthe.Plugin.defaults()
  end
end

You can add custom fields to the context through the context method in the schema. The context's value is available to all steps in the GraphQL request cycle (e.g., inside resolvers or middleware) inside the %Absinthe.Resolution{} struct. Context is also where we usually store user details if we authenticate users.

Check out the Absinthe Context and Authentication guide to explore this further.

In addition, we add dataloader to plugins using the plugins/0 callback on the schema. This allows dataloader to hook into the resolution pipeline. If you want to learn more about plugins, read the Writing Middleware and Plugins guide for Absinthe.

DataLoader.add_source/3 expects the name of the data source as its second argument and a module implementing the Dataloader.Source protocol. Dataloader supports an Ecto-based data source out of the box, which is what we will need for our example.

Let's update our Phoenix context (Blog in our example) to return the Ecto data source from data/0:

# my_app/blog.ex
defmodule MyApp.Blog do
  def data(), do: Dataloader.Ecto.new(MyApp.Repo, query: &query/2)

  def query(queryable, _params), do: queryable
end

It isn't really documented very well, but if you are feeling adventurous, most of the data-loading magic lies inside the Ecto data source.
It uses the query/2 function we passed to generate a base query when it needs to load some data.

For example, if we try to load Author with ids 1 through 5, it will make a single query like from a in Author, where a.id in [1, 2, 3, 4, 5], instead of making 5 different queries.

This function is our opportunity to filter results and return a query that will finally be used to fetch the items.
For now, we just return the queryable as it is, which means that we don’t need any special filtering.

Use Dataloader Inside the Absinthe Schema

To use Dataloader inside our schema, we must now modify our object post to use the dataloader helper.

import Absinthe.Resolution.Helpers, only: [dataloader: 2]

object :post do
  # ... other fields
  field :author, non_null(:author),
    resolve: dataloader(MyApp.Blog, :author)
  end
end

The first argument to dataloader/2 is the source name (as registered in the schema).
The next argument is the name of the field in the parent object (author field in parent object post).

Note that the data source should be the one that will resolve the field. So if the post belongs to an author with type MyApp.Accounts.User, you must use dataloader(MyApp.Accounts, :author) as the resolver and support data/0 and query/2 inside the Accounts context.

Here is the full code if you are interested. I know it's a lot to take in, so let's go through the execution of the query above.

Absinthe first invokes our posts resolver (Resolvers.Blog.list_posts/2), and returns the list of posts. Absinthe then checks for the fields it needs inside post and encounters a selection for author.
This is where dataloader takes over:

It collects the author_id for all posts that will be returned in our result. Let's say we need to load authors [1, 2, 3, 4, 5].
It then calls MyApp.Blog.query(Author, %{}) to get the initial query. In our example, we are simply returning Author (but in a real application, this could be filtered by business case — for example, if we need only authors that have an active account, we could return where(queryable, [a], a.active), instead of just returning queryable).
Finally, it loads the required ids from the above query — from a in Author, where a.id in [1, 2, 3, 4, 5].

As you can see, we only performed a single query instead of 5 different ones.

Nesting also works out of the box, so if each author has an organization field and we select that in the query, Dataloader will load all organizations in one batch.

Organizing Your Absinthe Schema with Imports

As your schema starts growing, you will soon notice that putting all type definitions and query fields in the same file is not sensible. This is where import_types and import_fields come into play.

The level to split at depends on the size of your API and your application, but it is a common practice to split by business context (the same as your Phoenix contexts).

Here is a structure that works well.

Create a module that contains queries (and another for mutations) related to each model:

   # lib/my_app_web/schema/types/blog/post/queries.ex
   defmodule MyAppWeb.Schema.Types.Blog.Post.Queries do
     use Absinthe.Schema.Notation

     object :post_queries do
       field :posts, list_of(:post), resolve: Resolvers.Blog.posts/2
       # ... all queries related to post here
     end
   end

Create a module for types related to each model. Also import the query and mutation types here.

   # lib/my_app_web/schema/types/blog/post.ex
   defmodule MyAppWeb.Schema.Types.Blog.Post do
     use Absinthe.Schema.Notation

     import_types(MyAppWeb.Schema.Types.Blog.Post.Queries)
     import_types(MyAppWeb.Schema.Types.Blog.Post.Mutations)

     object :post do
       field :title, not_null(:string)
       # ...
     end

     # all types related to blog here
   end

Create a module for types related to each context. This should only import the types from model-specific modules.

   # lib/my_app_web/schema/types/blog.ex
   defmodule MyAppWeb.Schema.Types.Blog do
     use Absinthe.Schema.Notation

     alias MyAppWeb.Schema.Types

     import_types(Types.Blog.Post)
     # ... import all types related to blog here

     object :blog_queries do
       import_fields(:post_queries)
       # ... import all queries related to blog here
     end

     object :blog_mutations do
       import_fields(:post_mutations)
       # ... import all queries related to blog here
     end
   end

Finally, import the context-specific types to your schema.

   # lib/my_app_web/schema.ex
   defmodule MyAppWeb.Schema do
     use Absinthe.Schema

     import_types(MyAppWeb.Schema.Types.Blog)

     query do
       import_fields :blog_queries
     end

     mutation do
       import_fields :blog_mutations
     end
   end

This way, your schema remains very clear, declaring only what it imports. All specific queries are further down the pipeline.

This may seem like overkill for our small API example.
But we have been using it in production for a large app with several contexts, and it’s been a boon to keep our schema manageable.

Wrap Up

In this post, the second part of our series on Absinthe, we customized Absinthe for an Elixir application pushing a lot of data. We started by defining resolvers for a big Elixir application and covered how to avoid N+1 queries.

Finally, we dived into Dataloader (which helps to load linked data) in some detail and explored how to organize our Absinthe schema.

Next up, we'll look at creating mutations and subscriptions with Absinthe.

Until then, happy coding!

P.S. If you'd like to read Elixir Alchemy posts as soon as they get off the press, subscribe to our Elixir Alchemy newsletter and never miss a single post!

An Introduction to Absinthe

Sapan Diwakar — Tue, 23 May 2023 11:41:57 +0000

Absinthe is a toolkit for building a GraphQL API with Elixir. It has a declarative syntax that fits really well with Elixir’s idiomatic style.

In today’s post — the first of a series on Absinthe — we will explore how you can use Absinthe to create a GraphQL API.

But before we jump into Absinthe, let’s take a brief look at GraphQL.

GraphQL

GraphQL is a query language that allows declarative data fetching. A client can ask for exactly what they want, and only that data is returned.

Instead of having multiple endpoints like a REST API, a GraphQL API usually provides a single endpoint that can perform different operations based on the request body.

GraphQL Schema

Schema forms the core of a GraphQL API. In GraphQL, everything is strongly typed, and the schema contains information about the API's capabilities.

Let's take an example of a blog application. The schema can contain a Post type like this:

type Post {
  id: ID!
  title: String!
  body: String!
  author: Author!
  comments: [Comment]
}

The above type specifies that a post will have an id, title, body, author (all non-null because of ! in the type), and an optional (nullable) list of comments.

Check out Schema to learn about advanced concepts like input, Enum, and Interface in the type system.

GraphQL Query and Mutation

A type system is at the heart of the GraphQL schema. GraphQL has two special types:

A query type that serves as an entry point for all read operations on the API.
A mutation type that exposes an API to mutate data on the server.

Each schema, therefore, has something like this:

schema {
  query: Query
  mutation: Mutation
}

Then the Query and Mutation types provide the real API on the schema:

type Query {
  post(id: ID!): Post
}

type Mutation {
  createPost(post: PostInput!): CreatePostResult!
}

We will get back to these types when we start creating our schema with Absinthe.

GraphQL API

Clients can read the schema to know exactly what an API provides. To perform queries (or mutations) on the API, you send a document describing the operation to be performed. The server handles the rest and returns a result. Let’s check out an example:

query {
  post(id: 1) {
    id
    title
    author {
      id
      firstName
      lastName
    }
  }
}

The response contains exactly what we've asked for:

{
  "data": {
    "post": {
      "id": 1,
      "title": "An Introduction to Absinthe",
      "author": {
        "id": 1,
        "firstName": "Sapan",
        "lastName": "Diwakar"
      }
    }
  }
}

This allows for a more efficient data exchange compared to a REST API. It's especially useful for rarely used complex fields in a result that takes time to compute.

In a REST API, such cases are usually handled by providing different endpoints for fetching that field or having special attributes like include=complex_field in the query param. On the other hand, a GraphQL API can offer native support by delaying the computation of that field unless it is explicitly asked for in the query.

Setting Up Your Elixir App with GraphQL and Absinthe

Let’s now turn to Absinthe and start building our API. The installation is simple:

Add Absinthe, Absinthe.Plug, and a JSON codec (like Jason) into your mix.exs:

   def deps do
     [
       # ...
       {:absinthe, "~> 1.7"},
       {:absinthe_plug, "~> 1.5"},
       {:jason, "~> 1.0"}
     ]
   end

Add an entry in your router to forward requests to a specific path (e.g., /api) to Absinthe.Plug:

   defmodule MyAppWeb.Router do
     use Phoenix.Router

     # ...

     forward "/api", Absinthe.Plug, schema: MyAppWeb.Schema
   end

The Absinthe.Plug will now handle all incoming requests to the /api endpoint and forward them to MyAppWeb.Schema (we will see how to write the schema below).

The installation steps might vary for different apps, so follow the official Absinthe installation guide if you need more help.

Define the Absinthe Schema and Query

Notice that we've passed MyAppWeb.Schema as the schema to Absinthe.Plug. This is the entry point of our GraphQL API. To build it, we will use Absinthe.Schema behaviour which provides macros for writing schema. Let’s build the schema to support fetching a post by its id.

defmodule MyAppWeb.Schema do
  use Absinthe.Schema

  query do
    field :post, :post do
      arg :id, non_null(:id)
      resolve fn %{id: post_id}, _ ->
        {:ok, MyApp.Blog.get_post!(post_id)}
      end
    end
  end
end

There are a lot of things happening in the small snippet above. Let’s break it down:

We first define a query block inside our schema. This defines the special query type that we discussed in the GraphQL section.
That query type has only one field, named post. This is the first argument to the field macro.
The return type of the post field is post — this is the second argument to the macro. We will get back to that later on.
This field also has an argument named id, defined using the arg macro.The type of that argument is non_null(:id), which is the Absinthe way of saying ID! — a required value of type ID.
Finally, the resolve macro defines how that field is resolved. It accepts a 2-arity or 3-arity function that receives the parent entity (not passed for the 2-arity function), arguments map, and an Absinthe.Resolution struct. The function's return value should be {:ok, value} or {:error, reason}.

Define the Type In Absinthe

In Absinthe, object refers to any type that has sub-fields. In the above query, we saw the type post. To create that type, we will use the object macro.

defmodule MyAppWeb.Schema do
  use Absinthe.Schema

  @desc "A post"
  object :post do
    field :id, non_null(:id)
    field :title, non_null(:string)
    field :author, non_null(:author)
    field :comments, list_of(:comment)
  end

  # ...
end

The first argument to the object macro is the identifier of the type. This must be unique across the whole schema. Each object can have many fields. Each field can use the full power of the field macro that we saved above when defining the query. So we can define nested fields that accept arguments and return other objects.

As we discussed earlier, the query itself is an object, just a special one that serves as an entry point to the API.

Using Scalar Types

In addition to objects, you can also get scalar types. A scalar is a special type with no sub-fields and serializes to native values in the result (e.g., to a string). A good example of a scalar is Elixir’s DateTime.

To support a DateTime that we'll use in the schema, we need to use the scalar macro. This tells Absinthe how to serialize and parse a DateTime.

Here is an example from the Absinthe docs:

defmodule MyAppWeb.Schema do
  use Absinthe.Schema

  scalar :isoz_datetime, description: "UTC only ISO8601 date time" do
    parse &Timex.parse(&1, "{ISO:Extended:Z}")
    serialize &Timex.format!(&1, "{ISO:Extended:Z}")
  end

  # ...
end

We can then use this scalar anywhere in our schema by using :isoz_datetime as the type:

defmodule MyAppWeb.Schema do
  use Absinthe.Schema

  @desc "A post"
  object :post do
    # ...
    field :created_at, non_null(:isoz_datetime)
  end

  # ...
end

Absinthe already provides several built-in scalars — boolean, float, id, integer, and string — as well as some custom scalars: datetime, naive_datetime, date, time, and decimal.

Type Modifiers and More

We can also modify each type to mark some additional constraints or properties. For example, to mark a type as non-null, we use the non_null/1 macro. To define a list of a specific type, we can use list_of/1.

Advanced types like union and interface are also supported.

Wrap Up

In this post, we covered the basics of GraphQL and Absinthe for an Elixir application. We discussed the use of GraphQL and Absinthe schema, and touched on types in Absinthe.

In the next part of this series, we'll see how we can apply Absinthe and GraphQL to large Elixir applications.

Happy coding!

P.S. If you'd like to read Elixir Alchemy posts as soon as they get off the press, subscribe to our Elixir Alchemy newsletter and never miss a single post!

Under the Hood of Ecto

Sapan Diwakar — Tue, 28 Feb 2023 12:08:38 +0000

Ecto is a toolkit for mapping database objects to Elixir structs and provides a unified interface to manipulate that data.

In this post, we will dive into the internals of Ecto — its major components, their functions, and how they work. In doing so, we'll demystify some of the apparent magic behind Ecto.

Let's get going!

Ecto's Modules

Ecto is made up of four major modules — Repo, Query, Schema, and Changeset.

We'll look at each in turn. Let’s start with the Repo module.

Repo Module

If you use Ecto with a database (like most users out there), Repo is the heart of Ecto. It binds everything together and provides a centralized point of communication between a database and your application. Repo:

maintains connections
executes queries against a database
provides an API to write migrations that interact with the database

Let's get started with Repo. Simply call use Ecto.Repo inside your Repo module. If you use mix phx.new to generate your Elixir project, this is done automatically for you.

# lib/my_app/repo.ex
defmodule MyApp.Repo
  use Ecto.Repo,
      otp_app: :my_app,
      adapter: Ecto.Adapters.Postgres

These few lines of code define the repo. Putting it under the Supervision tree inside application.ex gives you access to a whole set of functions provided by Repo to interact with a database. Again, this is code that is generated for you when using Phoenix:

defmodule MyApp.Application do
  use Application

  @impl true
  def start(_type, _args) do
    children = [
      # Start the Ecto repository
      MyApp.Repo,
      # Other Children...
    ]

    # See https://hexdocs.pm/elixir/Supervisor.html
    # for other strategies and supported options
    opts = [strategy: :one_for_one, name: MyApp.Supervisor]
    Supervisor.start_link(children, opts)
  end

With the few lines of code above, you get the following:

Access to the full Ecto.Repo API included in MyApp.Repo. The most common use cases include fetching records with MyApp.Repo.all/2, inserting new records with MyApp.Repo.insert/2, and updating records with MyApp.Repo.update/2.
A Supervisor starts that keeps track of all the processes required to keep Ecto working. The Supervision tree initializes the adapter (Ecto.Adapters.Postgres, in this case), which is responsible for all communication with the database. The Postgres adapter, in turn, starts a connection pool to your database using the DBConnection library.
A query planner starts that's responsible for planning and normalizing a query and its parameters. It also keeps a cache of all planned queries in an ETS table. We will learn more about this when we get to the Query module.

Monitor Queries Sent to Ecto from Your Elixir Application

In addition, Ecto also automatically publishes telemetry events that can be monitored.
For example, to monitor statistics for all the queries sent to Ecto, you can subscribe to the [:my_app, :repo, :query] event with telemetry.

Then, each time a query is performed, this event triggers some query metadata that includes the time spent executing the query, retrieving the data from the database, and more.

For more details, see this full list of Ecto telemetry events.

There are many options available to configure the Repo or the adapter as per your needs, but that's out of the scope of this post. Let's just take a very quick look at how you can monitor queries with AppSignal.

Instrumenting Ecto Queries with AppSignal in Your Elixir App

AppSignal automatically instruments Ecto so you can get insights into Queries running in your Phoenix or Plug applications. Make sure the :otp_app configuration option matches your app’s OTP app name, and you’re all set!

Here's an example of how an Ecto query will look in AppSignal:

Query Module

The Query module provides a unified API to write database-agnostic queries in Elixir.
Note that building database queries with functions provided by the Ecto.Query module does not result in the queries being executed.

These functions return a query in the form of an Ecto.Query struct.
Nothing is actually sent to the database until the built %Ecto.Query{} is passed to one of the functions provided by the Repo module.

As an example, let’s see a simple query that selects all users above 18 years of age:

age = 18
query = from u in "users",
                where: u.age > ^age,
                select: u.name

Type this into an IEx console and you will see that it creates a struct like this:

#Ecto.Query<from u0 in "users", where: u0.age > 18, select: u0.name>

You can also print it as a full map to see everything inside it:

iex(9)> IO.inspect(query, structs: false)
%{
  __struct__: Ecto.Query,
  aliases: %{},
  assocs: [],
  combinations: [],
  distinct: nil,
  from: %{
    __struct__: Ecto.Query.FromExpr,
    as: nil,
    file: "iex",
    hints: [],
    line: 40,
    params: [],
    prefix: nil,
    source: {"users", nil}
  },
  group_bys: [],
  havings: [],
  joins: [],
  limit: nil,
  lock: nil,
  offset: nil,
  order_bys: [],
  prefix: nil,
  preloads: [],
  select: %{
    __struct__: Ecto.Query.SelectExpr,
    aliases: %{},
    expr: {{:., [], [{:&, [], [0]}, :name]}, [], []},
    fields: nil,
    file: "iex",
    line: 40,
    params: [],
    subqueries: [],
    take: %{}
  },
  sources: nil,
  updates: [],
  wheres: [
    %{
      __struct__: Ecto.Query.BooleanExpr,
      expr: {:>, [], [{{:., [], [{:&, [], [0]}, :age]}, [], []}, {:^, [], [0]}]},
      file: "iex",
      line: 40,
      op: :and,
      params: [{18, {0, :age}}],
      subqueries: []
    }
  ],
  windows: [],
  with_ctes: nil
}

This is much more interesting — it shows exactly how the simple query is represented internally in Ecto.
Ecto.Query.FromExpr contains details about the table we are querying (users).

ASTs in the Query

The other two expressions we see in the query are much more complex, but this is something that the adapters understand and convert to the query.
If you look closely, they are ASTs.

Note: If you are interested in learning more about ASTs, check out An Introduction to Metaprogramming in Elixir.

Let's see what the code looks like for this expression:

iex> Macro.to_string({:>, [], [{{:., [], [{:&, [], [0]}, :age]}, [], []}, {:^, [], [0]}]})
"&0.age() > ^0"

This is our condition in where, just normalized into terms the adapters understand.

The adapter does the final translation of the query to actual SQL that the database understands. Note that while we usually write SQL here, the adapters don't need to work with SQL databases only — some adapters work just as well with no-SQL databases. Query generation and all database communication are clearly separated from Ecto's core.

If you want to explore this further, try building out some complex queries with joins, subqueries, windows, etc., and see how they are represented internally — it is a great way to learn how abstractions are made inside Ecto.

Finally, this query struct is converted to a SQL statement by the adapter:

iex> Ecto.Adapters.SQL.to_sql(:all, MyApp.Repo, query)
{"SELECT u0.\"name\" FROM \"users\" AS u0 WHERE (u0.\"age\" > $1)", [18]}

Back to Erlang's ETS Table

Back in the section about the Repo module, we created an ETS table when we started the Repository in our application.

Now that ETS table comes into play.
When a query is executed multiple times, the query is only prepared the first time.

Note: You can learn more about PREPARE in the context of Postgres.

It is then cached inside that ETS table and fetched from there for all subsequent calls.
To see the caching in action, check this out (notice the :cached in result, which signals that this query has been cached):

iex> MyApp.Repo.all(query) # This puts the query in the cache

# Trying to prepare the query again gets a cached version
iex> Ecto.Adapter.Queryable.prepare_query(:all, MyApp.Repo, query)
{{:cached, #Function<41.44551318/1 in Ecto.Query.Planner.query_with_cache/8>,
  #Function<42.44551318/1 in Ecto.Query.Planner.query_with_cache/8>,
  {5122,
   %Postgrex.Query{
     ref: #Reference<0.3269063957.2912157697.165169>,
     name: "ecto_5122",
     statement: "SELECT u0.\"name\" FROM \"users\" AS u0 WHERE (u0.\"age\" > $1)",
     param_oids: [20],
     param_formats: [:binary],
     param_types: [Postgrex.Extensions.Int8],
     columns: ["name"],
     result_oids: [1043],
     result_formats: [:binary],
     result_types: [Postgrex.Extensions.Raw],
     types: {Postgrex.DefaultTypes, #Reference<0.3269063957.2912288771.132368>},
     cache: :reference
   }}}, [18]}

Note that this doesn’t cache the result, only the prepared statements. Prepared statements give a large performance advantage, especially for complex queries. From the Postgres docs:

Prepared statements potentially have the largest performance advantage when a single session is being used to execute a large number of similar statements.

The performance difference will be particularly significant if the statements are complex to plan or rewrite, e.g., if the query involves a join of many tables or requires the application of several rules.

The next important module in Ecto is the Schema. Let's take a look at it now.

Schema Module

You can use Ecto without schemas and it works just as well (as we saw above when we referenced the table names directly).

The Schema module is responsible for defining and mapping a record's attributes (fields and associations) from a database table to an Elixir struct.

To create a schema, we write use Ecto.Schema at the top of our module and use the schema DSL.

For example:

defmodule MyApp.Organization do
  use Ecto.Schema

  schema "organizations" do
    field :name, :string
  end
end

defmodule MyApp.User do
  use Ecto.Schema

  schema "users" do
    field :name, :string
    belongs_to :organization, MyApp.Organization
  end
end

The use statement includes several utility functions and macros inside the module and sets some default module attributes required for Ecto to gather data from the Schema.
The schema macro then updates some of those attributes to mark that this is a persisted schema (there is also another embedded_schema macro to deal with non-persisted schemas) and sets some other defaults, like the primary key.
The field and belongs_to inside the schema block then put those fields in the module attributes (for type validation), and add the fields to the struct defined by the module.

The Ecto.Schema behavior exposes some methods inside the schema to fetch field details. For example:

iex(62)> MyApp.User.__schema__(:source)
"users"
iex(63)> MyApp.User.__schema__(:fields)
[:id, :name, :organization_id]
iex(64)> MyApp.User.__schema__(:primary_key)
[:id]
iex(65)> MyApp.User.__schema__(:associations)
[:organization]
iex(66)> MyApp.User.__schema__(:association, :organization)
%Ecto.Association.BelongsTo{
  field: :organization,
  owner: MyApp.User,
  related: MyApp.Organization,
  owner_key: :organization_id,
  related_key: :id,
  queryable: MyApp.Organization,
  on_cast: nil,
  on_replace: :raise,
  where: [],
  defaults: [],
  cardinality: :one,
  relationship: :parent,
  unique: true,
  ordered: false
}

This __schema__ function is also the entry-point for other parts of Ecto to reflect on more details about the defined schema and perform operations on it.

For example, when used as the source of a query, the repo will use schema to validate the conditions in the where clause, and cast the data returned from the database to Elixir structs.
This results in much better feedback when there's something wrong.

A Schema Module In Action on an Elixir App

Let's try executing a query that has a typo to see the benefits of using a schema in action:

from u in "users",
  select: u.id,
  where: u.ages > 19

Executing this with Repo.all will throw a generic Postgrex.Error:

** (Postgrex.Error) ERROR 42703 (undefined_column) column u0.ages does not exist

    query: SELECT u0."id" FROM "users" AS u0 WHERE (u0."ages" > 19)

Let's try the same query, but this time with a schema.

from u in MyApp.Accounts.User,
  select: u.id,
  where: u.ages > 19

As expected, this also throws an error, but it now includes the line number where it happened and has a more specific Exception type:

** (Ecto.QueryError) lib/my_app/accounts.ex:109: field `ages` in `where` does not exist in schema MyApp.Accounts.User in query:

from u0 in MyApp.Accounts.User,
  where: u0.ages > 19,
  select: u0.id

This works because the query planner in Ecto can look at the schema's metadata and figure out that this field doesn't exist on the schema even before hitting the database.

Ecto also does type conversions behind the scenes when using the schema. For example, it allows us to run this query:

id = "2"
query = from u in MyApp.Accounts.User, where: u.id == ^id
Repo.all(query)

On the other hand, if you are not using a schema, a similar query will raise an exception:

query = from u in "users", where: u.id == ^id, select: u.id
Repo.all(query)

** (DBConnection.EncodeError) Postgrex expected an integer in -9223372036854775808..9223372036854775807, got "2". Please make sure the value you are passing matches the definition in your table or in your query or convert the value accordingly.

Changeset Module

The final module that we will look at today is Changeset.
It provides an interface for validating and transforming data before it is written into a database.

Similarly to Query, Changeset provides a structured way to represent changes to data. It is most commonly used with Ecto schemas, but schemaless changesets are also possible when you don’t need a full-fledged schema.

Ecto.Changeset provides a comprehensive API to work with data.

The `cast/4` Changeset

Let's start by looking at the most commonly used changeset, cast/4:

iex> changeset = %MyApp.User{name: "some name"}
     |> cast(%{"name" => "", "organization_id" => "1", "foo" => "bar"}, [:name, :organization_id])
     |> validate_required(:name)

We pass initial data (the MyApp.User struct in this case) to cast followed by some parameters and the list of allowed fields.

cast figures out the type of each allowed field by looking at the schema metadata. cast then typecasts a parameter value to an allowed value, or adds an error to the changeset.

For example, here we can see that we had a value of 1 (String) as the organization_id.
But from the schema, cast can figure out that organization_id is of type int and cast the value to an integer before putting the change inside the Changeset.

The `validate_required/3` Changeset

The second call in the pipeline, validate_required/3, requires the field to be present (as the name suggests).
By default, it trims any strings/binaries before running validations and assumes an empty string to be blank.

Here's what is printed out when you inspect the Changeset.

#Ecto.Changeset<
  action: nil,
  changes: %{organization_id: 1},
  errors: [name: {"can't be blank", [validation: :required]}],
  data: #MyApp.User<>,
  valid?: false
>

This small summary already contains most of the information we need about the changeset.
It shows what changes were made to the initial data (organization_id was set to 1), and that the changeset is invalid. It lists all the errors.

Let’s go one step further and inspect the full map.

iex> IO.inspect(changeset, structs: false)
%{
  __struct__: Ecto.Changeset,
  action: nil,
  changes: %{organization_id: 1},
  constraints: [],
  data: %{
    __meta__: %{
      __struct__: Ecto.Schema.Metadata,
      context: nil,
      prefix: nil,
      schema: MyApp.User,
      source: "users",
      state: :built
    },
    __struct__: MyApp.User,
    id: nil,
    name: "some name",
    organization: %{
      __cardinality__: :one,
      __field__: :organization,
      __owner__: MyApp.User,
      __struct__: Ecto.Association.NotLoaded
    },
    organization_id: nil
  },
  empty_values: [""],
  errors: [name: {"can't be blank", [validation: :required]}],
  filters: %{},
  params: %{"name" => "", "organization_id" => 1, "foo" => "bar"},
  prepare: [],
  repo: nil,
  repo_opts: [],
  required: [:name],
  types: %{
    id: :id,
    name: :string,
    organization: {:assoc,
     %{
       __struct__: Ecto.Association.BelongsTo,
       cardinality: :one,
       defaults: [],
       field: :organization,
       on_cast: nil,
       on_replace: :raise,
       ordered: false,
       owner: MyApp.User,
       owner_key: :organization_id,
       queryable: MyApp.Organization,
       related: MyApp.Organization,
       related_key: :id,
       relationship: :parent,
       unique: true,
       where: []
     }},
    organization_id: :id
  },
  valid?: false,
  validations: []
}

This contains much more information now.

The data and params are self-explanatory — the initial data and the params we fed to cast.

types contains additional data about the schema we are working with (fetched using the __schema__ method we saw in the previous section).

changes and errors are where it gets interesting. cast automatically converts the string organization_id to an integer because it knows that the organization_id is a numeric primary key from the association details.

What's also interesting is that it understands that "" is a blank value and inserts an error into the changeset from the validate_required call.

The database manipulation functions from Repo understand changesets and return errors if the changeset is invalid.

The Changeset API provides several other functions for validating data and database constraints, as well as dealing with associations.

These functions interact with the data and eventually update the struct that we saw above. When fed to the Repo module's functions, structs perform the eventual database operations.

Wrapping Up

In this post, we looked at the core concepts of the Ecto library:

We started with a Schema that defined our business objects mapped to database tables.
To get those objects out of the database, we used the Query API.
We then used Changesets to change those objects, and inserted or updated them in the database.
Tying everything together was the Repo module which takes inputs from all the other modules, eventually connecting to the database to fetch data or update records.

All of these modules work together to provide a structured and safe way to interact with databases.

Check out the official Ecto guide to integrate Ecto into your Elixir application. I have also included links to the source code in parts of this post, so feel free to go back and dig a little deeper.

Until next time — happy digging!

P.S. If you'd like to read Elixir Alchemy posts as soon as they get off the press, subscribe to our Elixir Alchemy newsletter and never miss a single post!

How to Scale Ruby on Rails Applications

Sapan Diwakar — Wed, 16 Nov 2022 12:34:39 +0000

Today we will dive into some strategies you can use to scale Ruby on Rails applications to a huge user base.

One obvious way of scaling applications is to throw more money at them. And it works amazingly well — add a few more servers, upgrade your database server, and voila, a lot of the performance issues just go poof!

But it is often also possible to scale applications without adding more servers. That's what we will discuss today.

Let's get going!

Use AppSignal for your Rails Application

Before we dive into scaling and performance optimization, you first need to identify if you need to do this, what the bottlenecks are in your application, and what resources can be scaled.

One easy way to do this is to use AppSignal's performance monitoring and metrics for Ruby.

The performance dashboard helps you pinpoint the exact controller actions and background jobs that are slow on average.

For example, here's how a performance dashboard might look for ActiveRecord:

This gives a good starting point to any scaling journey — whether you decide to add more servers or optimize performance through code.

Now let's move on to one of the simplest techniques you can use to scale your Rails app — caching.

Caching in Ruby on Rails

Caching allows you to stop computing the same things again and again.

For example, let's say you run a social media platform and there's a very popular post. Caching can immediately help you regain all the CPU cycles you spend rendering that post for every user. And that's only a part of what caching can help you do.

Let's look at all the possible resources that can be cached.

Caching Views

Rendering views can sometimes be an expensive operation, especially when that view has a lot of data to be rendered. Even when the operation isn't expensive, using a pre-rendered view will give you a lot of performance as opposed to rendering that same view a million times.

Rails supports this out of the box using the cache view helper. For example, this is how it can cache each post when rendering a list:

<% @posts.each do |post| %>
  <% cache post do %>
    <%= render post %>
  <% end %>
<% end %>

For this, Rails automatically caches each post under a specific key that depends on the HTML content of the template, post id, and update timestamp.

To read more about this technique, check out the posts Fragment caching in Rails and Rails collection caching.

One thing to keep in mind, though, is that the cache keys don’t include nested template content. So if you are nesting the cache calls deeper than one level, there might be stale results. Read more about this in Russian doll caching in Rails.

Caching Responses

In addition to caching views/fragments, you can also choose to cache the full response of GET requests. This is supported through the If-None-Match and If-Modified-Since headers sent by the browsers.

When an If-None-Match header is present on the request, the server can return a 304 Not Modified response with no content if there are no changes to the response. The server-computed Etag is compared with the value inside that header.

Similarly, if the If-Modified-Since header is present without an If-None-Match, the server can return a 304 Not Modified response with no content (as long as the response hasn’t changed since that date).

Rails provides easy ways to do this inside controller actions. You can simply write:

class PostsController < ApplicationController
  def show
    @post = Post.find(params[:id])
    fresh_when last_modified: @post.updated_at.utc, etag: @post
  end
end

Rails will send all the required headers to support caching, handle incoming headers, and respond with 304 when the data hasn’t changed. The server can skip rendering the full views again unless things change. You can read more about advanced configuration for this strategy in Client-side caching in Rails: conditional GET requests.

Caching Values

Finally, it is also possible to cache raw values (anything that can be serialized to the cache store). This is usually useful to cache the results of resource-intensive or slow operations and avoid performing them again.

Identifying a value that can benefit from this caching depends greatly on the application, but usually, looking at your slowest events can help point you in the correct direction.

Finally, when you identify what to cache, the API that Rails provides for this is very simple to use:

Rails.cache.fetch(cache_key_with_version, expires_in: 12.hours) do
  perform_the_slow_computation
end

The above code will perform_the_slow_computation only once and then cache the value under the cache_key_with_version key. The next time the same code is called, Rails will first check if we already have a cached value and use that instead of triggering perform_the_slow_computation again.

The most important part of this caching strategy is to compute a good cache key that depends on all the inputs used in the value's computation. This is to ensure we don’t keep using a stale value.

Cache Stores

Now that we know what to cache and the techniques Rails provides to store things in the cache, the next logical question is — where do we cache this data? Rails comes with several in-built cache store adapters. The most popular cache stores for production use cases are Redis and Memcached. There are a couple of other options as well — the file store and memory store. A full discussion of these stores can be found in the post Rails' built-in cache stores: an overview.

File and memory stores can be great for development use to get things up and running quickly. However, they are usually unsuitable for production, especially if you're working in a distributed setup with multiple servers. Redis and memcached are both suited for production use. Which one you use usually depends on the application.

Background Workers in Ruby on Rails

Most applications need background jobs for mailers, regular clean-ups, or any other time-consuming operation that doesn't require a user to be present. Chances are, you already have a background worker set up already.

Whenever you find yourself doing anything that takes more than a second to do inside a controller action, see if you can move it to a background worker instead. This could range from a user-facing operation like searching for data inside a large table to an API method that ingests a large amount of data.

Example Implementation

To run custom jobs, Rails provides the Active Job framework. Let's see how we can use it to move a very complex filtering logic to a background job. First, let’s create our background job:

# jobs/filter_huge_dataset_job.rb
class FilterHugeDatasetJob < ApplicationJob
  queue_as :default

  def perform(user, filters)
    # search your data
  end
end

We can run this job from the controller like this:

# controllers/huge_datasets_controller.rb
class HugeDatasetsController < ApplicationController
  def index
    FilterHugeDatasetJob.perform_later(@current_user, filters)
  end
end

We need to render a loading indicator on our template while we wait for our job to compute data and deliver the results.

But how can we get the results from our job to the view? Turbo makes this really easy. For example, inside the view, we can subscribe to turbo-stream events on a specific notification channel using turbo_stream_from.

Using this, let’s write our templates:

# view/huge_datasets/index.html.erb
<%= render "index", user: @current_user %>

# view/huge_datasets/_index.html.erb
<%= turbo_stream_from user, :huge_datasets %>
<%= render "filters" %>
<div id="data-container">
  <% if defined? data %>
    <%= render partial: "item", collection: data  %>
  <% else %>
    <%= render "loading" %>
  <% end %>
</div>

Since data is not defined in the initial controller action, we will only render a loading indicator. Let’s now deliver the results from our job:

# jobs/filter_huge_dataset_job.rb
class FilterHugeDatasetJob < ApplicationJob
  queue_as :default

  def perform(user, filters)
    data = search_huge_dataset(filters)
    notify_completed(user, data)
  end

  def search_huge_dataset(filters)
    # search your data
  end

  def notify_completed(user, data)
    Turbo::StreamsChannel.broadcast_replace_to(
      [user, :huge_datasets],
      target: "data-container",
      partial: "huge_datasets/index",
      locals: { user: user, data: data }
    )
  end
end

The important part here is the notify_completed method. It uses Turbo::StreamsChannel, broadcasting a replace event to the [user, :huge_datasets] notification stream that we subscribed to from our view.

That is everything we need to move complex operations from our controller to background jobs. The main advantage of moving tasks to the background is that background workers can be scaled independently of web servers. This frees up resources on the web server side considerably. For the user, such interfaces also feel much more responsive because we can respond quickly and deliver results incrementally.

Note: If you need help deciding between a background job worker, read Delayed Job vs. Sidekiq: Which Is Better?

Scaling a Database in Your Ruby on Rails Application

The last scalable resource that we will discuss in this post is the database. Databases form the core of most applications. As data and the number of servers accessing that data grows, databases start to feel the load.

The easiest way to scale a database is to add more processing power and memory to the database server. As opposed to scaling web servers, doing this with a database is usually a very slow operation, especially if you have high storage.

The second option to scale databases is to scale horizontally using multiple databases or by sharding your database. Check out Multiple Databases with Active Record for more details about this.

Instead, we'll focus on optimizing your database's performance by looking at PostgreSQL.

Find Time-Consuming Queries in PostgreSQL

First, we need to identify our most time-consuming queries. The way we can do that is to query the pg_stat_statements table that contains statistics about all SQL statements executed on the server. Let’s see how we can find the top 100 queries with the highest run times:

SELECT query, calls, (total_exec_time/calls)::integer as avg_time_ms
FROM pg_stat_statements
WHERE calls > 1000
ORDER BY avg_time_ms desc
LIMIT 100;

This will return the query, the number of calls, and the average run time of these queries. Try to find the ones you think could be faster and analyze why they were slow.

You can also run EXPLAIN or EXPLAIN ANALYZE on the query to see the query plan and actual execution details, respectively.

One of the most important things to look out for in the results is Seq Scan, which indicates that Postgres has to go through all the records sequentially to run the query. If this happens, try to bypass that sequential scan by adding an index to the columns that you've filtered.

Tables with the Most Sequential Scans

Another useful query that I like to run is to find the total number of sequential scans run against a table:

SELECT relname AS name, seq_scan as count
FROM pg_stat_user_tables
ORDER BY seq_scan DESC;

If you see a very large table (with a high number of rows) and a high count value from this result, then you have a problem. Try to check all queries against that table, find ones that can run sequential scans, and add indices to boil that down.

Index Usage

You can also find statistics about index usage by running this query:

SELECT relname,
   CASE idx_scan
     WHEN 0 THEN 'Insufficient data'
     ELSE (100 * idx_scan / (seq_scan + idx_scan))::text
   END percent_of_times_index_used,
   n_live_tup rows_in_table
 FROM
   pg_stat_user_tables
 ORDER BY
   n_live_tup DESC;

This returns the percentage of index usage for each table. A low number means that you are missing some indexes on that table.

Wrap Up

In this post, we explored several strategies to scale your Ruby on Rails applications, including caching and background workers. We also looked at optimizing your PostgreSQL database's performance.

Rails makes it really easy to add several layers of performance optimization to your application.

The most important consideration with scalability is to identify bottlenecks in an application before we can act on them. A good performance monitoring tool can help. If you need one, check out AppSignal for Ruby.

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

Get Started with Hotwire in Your Ruby on Rails App

Sapan Diwakar — Wed, 13 Jul 2022 11:26:31 +0000

Hotwire is a hot topic at the moment for every Rails developer. If you work with Rails, there is a good chance you have already heard a lot about it.

Hotwire is a completely new way of adding interactivity to your app with very few lines of code, and it works blazing fast by transmitting HTML over the wire.

That means you can keep your hands clean from most Single Page Applications (SPA) frameworks. You can also keep your rendering logic centralized on the server, while still maintaining quick page load times and interactivity.

In this post, we'll look at the main components of Hotwire and how to use it in your Rails app. But first: what is Hotwire and why should you use it?

What Is Hotwire?

Hotwire is not a single library, but a new approach to building web and mobile applications by sending HTML over the wire. It includes Turbo, Stimulus, and Strada (coming later this year).

We will discuss each of these in detail in the next section.

Side note: While Hotwire is highly linked with Rails, it is completely language-agnostic, so it can work just as well with other applications.

I have been using Stimulus in production on several non-Rails apps and some static websites. You can use Turbo without Rails as well.

But let us come back to the Rails world for now.

Why Use Hotwire in Your Rails App?

So when should you use Hotwire? The answer is anywhere you want to add interactivity to your application. For example, if you want:

Some content to be displayed/hidden conditionally based on a user's interaction (e.g., an address form where the list of states automatically changes based on the selected country).
To update some content in real-time (e.g., a feed like Twitter where new Tweets automatically get added to the page).
To lazy-load some parts of your pages (e.g., inside an accordion, you can load the titles and mark the details to be lazy-loaded to speed up load times).

Hotwire Components

As mentioned before, Hotwire is a collection of new (and some old) techniques for building web apps.

Let's discuss each of these in the next few sections.

Turbo

HTML drives Turbo at its core.

Turbo provides several techniques to handle HTML data coming over the wire and display it on your application without performing a full page reload.

It is composed of:

Turbo Drive

If you have used Turbolinks in the past, you will feel right at home with Turbo Drive. At its core, some JS code intercepts JavaScript events on your application, loads HTML asynchronously, and replaces parts of your HTML markup.

Turbo Frames

Turbo Frames decouple parts of your markup into different sections that can be loaded independently. For example, if you have a blog application, the content of your post and the comments are two related but independent parts of the page. You can decouple them so navigation works independently or even load them asynchronously with turbo frames.

Turbo Streams

Turbo Streams offers utilities to easily bring in real-time data to your application. For example, let's say you are building a news feed like Twitter. You want to pull new tweets into a user's feed as soon as they are posted without reloading the page. Turbo Streams allow you to do this without writing a single line of JS.

Turbo Native

Turbo Native lets you build a native wrapper around your web application. Navigations and interactions will feel native without you having to redo all the screens natively. You'll keep delivering the rest of the application through the web. That way, you can focus on the really interactive parts of your application and get them right.

Stimulus

Stimulus is a JavaScript framework for writing controllers that interact with your HTML.

Let's say we need to add some JavaScript attributes like data-controller, data-action, and data-target to elements on a page. We'll write a stimulus controller with access to elements that receives events based on those attributes.

Here's an example:

<div data-controller="clipboard">
  PIN:
  <input data-clipboard-target="source" type="text" value="1234" readonly />
  <button data-action="clipboard#copy">Copy to Clipboard</button>
</div>

It is very easy to get an idea about what this does without even reading the associated Stimulus controller.

Here's a controller that goes with the HTML:

// src/controllers/clipboard_controller.js
import { Controller } from "@hotwired/stimulus";

export default class extends Controller {
  static targets = ["source"];

  copy() {
    navigator.clipboard.writeText(this.sourceTarget.value);
  }
}

That is at the core of Stimulus: keeping things simple and reusable.

Now, if you ever need a copy-to-the-clipboard button on another page, you can just re-use that controller. Add the data-* attributes on the markup to get everything working.

Strada

Unfortunately, we don't know much about Strada yet. But it will allow a web application to communicate (and possibly perform actions) with a native app using HTML bridge attributes.

How to Use Hotwire in Your Ruby on Rails Application

I don't want to spend too much time discussing Hotwire installation or a basic use case. The Hotwire team has already done an excellent job of it in their Hotwire screencast. For full instructions, see turbo-rails installation and Stimulus installation.

Let's jump straight into some common Hotwire use cases.

Endless Scroll

Using Turbo Frames, we can easily make a page with automatic pagination as the user scrolls. For this, we need to do two things:

Render each "page" inside its own frame by appending the page number to the frame id (e.g., turbo_frame_tag "posts_#{@posts.current_page}").
Use a lazy frame for the next page so that it doesn't load automatically unless it comes into view.

<%= turbo_frame_tag "posts_#{@posts.current_page}" do %>
  <%= render @posts %>
  <% unless @posts.last_page? %>
    <%= turbo_frame_tag "posts_#{@posts.next_page}", :src => path_to_next_page(@posts), :loading => "lazy" do %>
      <%= render "loading" %>
    <% end  %>
  <% end  %>
<% end %>

Note that this example uses methods from Kaminari, but you can adapt it to any other pagination method.

We don't need anything special in the controller. A standard index method works:

class PostsController < ApplicationController
  def index
    @posts = Post.page(params[:page]).per(params[:per_page])
  end
end

The trick here is that we use nested frames, with the frame for the next page nested inside the frame for the previous page.

That way, when the first page loads, the frame for the next page is placed at the end. When the user scrolls to that frame, it is replaced with the content of the second page. The lazy frame for the third page renders at the end.

Dynamic Forms

You can easily implement dynamic forms with Hotwire without custom logic for toggling fields on the front end. This is a bit more involved than the endless scroll use case, as it includes the use of both Turbo Stream and Stimulus.

Let's start with our form first.

<!-- app/views/posts/new.html.erb -->
<div data-controller="refresh-form" data-refresh-form-url="<%= refresh_form_posts_url(:target => "new_post") %>">
  <%= render "form" %>
</div>

<!-- app/views/posts/_form.html.erb -->
<%= form_for(@post, :data => { :target => "refresh-form.form" }) do |f| %>
  <%= f.select :kind, options_for_select([["News", :news], ["Blog", :blog]], @post.kind), {}, data: { action: "change->refresh-form#refreshForm" } %>

  <%= f.select :category, options_for_select(categories_for_kind(@post.kind), @post.category) %>
<% end %>

The form is simple enough — we display a kind select with News and Blog options. We want to change the available categories' values based on the kind that is selected (assuming that categories_for_kind(@post.kind) returns the list of categories for the given kind).

If you look closer, you'll see that we've added some data attributes to the form.

The data-target will link the form element to the RefreshFormController Stimulus Controller's form target.
And the data-action with the value of change->refresh-form#refreshForm will call the refreshForm method on the linked Stimulus Controller every time the kind select is changed.

Let's look at our Stimulus Controller:

// app/javascript/controllers/refresh_form_controller.js
import { Controller } from "stimulus";
import { put } from "@rails/request.js";

export default class extends Controller {
  static targets = ["form"];

  refreshForm() {
    put(this.data.get("url"), {
      body: new FormData(this.formTarget),
      responseKind: "turbo-stream",
    });
  }
}

On all refreshForm calls, we just make a new PUT request to the controller's URL (set using the data-refresh-form-url on the same element with a data-controller="refresh-form").
The important part here is that the responseKind is set to turbo-stream.

The @rails/request library understands this response and performs instructions based on the response stream.

Now all that's left is to return the correct stream from our refresh_form call for Turbo to understand and update our form.

class PostsController < ApplicationController
  def refresh_form
    @post = Post.new
    @post.attributes = post_params
    @post.valid?
    respond_to do |format|
      format.turbo_stream
    end
  end
end

Just update the attributes on the post and mark that you want to respond in a turbo_stream format (so that it looks up refresh_form.turbo_stream.erb).

<!-- app/views/posts/refresh_form.turbo_stream.erb -->
<%= turbo_stream.replace params[:target] do %>
  <%= render "form" %>
<% end %>

In this step, we are reusing our form partial, wrapping it inside a turbo_stream with a replace action.

And that's all you need to get a dynamic form working.

I know this looks a bit advanced, but the refresh stimulus controller is a shared part you can now use for all your dynamic forms by adding the correct data-* attributes.
So essentially, you now get server-side dynamic form refresh without writing any new JS for other forms. Pretty awesome, right?

Append Content to Pages Without Reloading

The next use case that Hotwire makes easy is streaming HTML over a WebSocket connection and updating a page with new content as it comes in.

A good example of this is the GitHub comments section.
You can implement this very easily using Turbo Streams.

There are two parts to this.

First, we embed a turbo stream listener on the listing page that opens a WebSocket connection to the server and listens for events.

<!-- app/views/comments/index.html.erb -->
<div id="comments">
  <%= turbo_stream_from @post, :comments %>

  <% @comments.each do |comment| %>
    <%= render comment %>
  <% end %>
</div>

Next, we update the model to broadcast new comments to the stream.

# app/models/coment.rb
class Comment < ApplicationRecord
  belongs_to :post

  after_create_commit :stream

  private

  def stream
    broadcast_prepend_later_to(post, :comments, target: :comments)
  end
end

You don't need anything else. Turbo will automatically render the app/views/comments/_comment.html.erb partial for each new comment and send it over a WebSocket connection. It will be picked up by Turbo's JS and prepended to the target with id comments.

Let's go one step ahead and add an indication to all newly added comments with a small Stimulus Controller.

First, modify the broadcast and comment partial to include the controller conditionally.

# app/models/coment.rb
# ...
def stream
  broadcast_prepend_later_to(post, :comments,
                             target: :comments,
                             locals: { highlight: true })
end

<!-- app/views/comments/_comment.html.erb -->
<div <%= %s(data-controller="highlight") if local_assigns[:highlight] %>
  <%= comment.body %>
</div>

This small Stimulus controller adds a special highlight class on connection for 3 seconds and then removes it.

export default class extends Controller {
  connect() {
    this.element.classList.add("highlight");
    this.timeout = setTimeout(
      () => this.element.classList.remove("highlight"),
      3000
    );
  }

  disconnect() {
    clearTimeout(this.timeout);
  }
}

Note: You also need to update the CSS highlighting based on the presence of that class.

Once this controller is done, you can re-use it on anything that requires a highlight class. You could even modify it to get the duration and class name from data attributes if you need that flexibility.

That's the great thing about Hotwire — it takes you a long way, and you don't have to dip your hands in JS. When you do need to write some JS, Stimulus gives you the tools to build small generic controllers that can be re-used.

Wrap Up and Further Reading

The Rails community has been really excited with the introduction of Hotwire, and rightly so.

In this post, we looked at the key components of Hotwire and how to use Hotwire in your Rails app. We touched on how you can bring your application to life using Turbo and Stimulus.

The official Hotwire screencast introduction and the Turbo documentation are great places to see what Hotwire and Turbo can do for you.

For advanced usage, I suggest heading over to the turbo-rails GitHub repo.
Sadly, the documentation is a bit sparse, but if you are not afraid to get your hands dirty, read the code and inline comments in:

Turbo::FramesHelper for Turbo Frames.
Turbo::Broadcastable for broadcasting to Turbo Streams from the code.
Turbo::Streams::TagBuilder for broadcasting to Turbo Streams as part of inline controller actions.

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

A Guide to Event-Driven Architecture in Elixir

Sapan Diwakar — Tue, 17 May 2022 12:14:37 +0000

In this post, we will explore how event-driven architecture can make your app more responsive for users and decouple your modules for a better developer experience.

We will also look at several methods of implementing event-driven architecture with Elixir.

Elixir is particularly good for this because of the advanced and concise message-passing APIs that it offers and BEAM's outstanding support for concurrency.

But first: what is event-driven architecture, exactly?

Event-Driven Architecture: An Introduction

Event-driven architecture is an architecture where events control the behavior and flow of your application.

The main components of the architecture are event producers, event bus, and event consumers.

An event could be anything that represents a change of state in the system.

For example, in an e-commerce application, the purchase of a product by the user could produce a sold event which the consumer can then process to update inventory.

An event-based architecture allows applications to act on events as they occur.

Different parts of an application work and develop relatively independently in well-crafted event-based design. Organizations can assign separate teams to focused parts of the application and streamline the workflow. This also creates a clear boundary between different parts of an application, assisting in future scalability exercises.

Event-driven architecture has mainly gained popularity with microservice-based products but can also be used for a monolith.

Things are always clearer with an example, so let's look at one.

Building Blocks of Event-Driven Architecture

Let's discuss each building block in detail, using an e-commerce application as an example.

Imagine that a user makes a new purchase on a website.
The new order is an event generated by the part that controls the ordering: the event producer.

The event can be pushed onto an event bus.
The event bus could be anything, such as:

A table in the database.
An in-memory event queue inside the app.
An external tool like RabbitMQ or Apache Kafka.

The event consumers interested in this type of event can subscribe to the event bus. The event is delivered to them, and they do some processing on top of it.

For example, an inventory management system would subscribe to the new order event and update the inventory of the product.
Another system could also pick the same event in the application — for example, a fulfillment service might process that event and create a delivery route for the product.

Benefits of Event-Driven Architecture

There are several advantages of using an event-driven architecture instead of one that processes everything sequentially.

An event-driven architecture allows us to build several independent parts of an application to work off the same event and do different focused tasks.

This can be advantageous for a couple of reasons:

One team needs to focus on only one part.
The application code for small parts can be simple.

Another advantage of the design is that it allows us to deliver a snappy interface to the user. As an example from the above application, a user needs to make an order.

The application can continue processing all other non-interactive tasks, like updating its inventory and interacting with the delivery application, without the user's attention.

This also makes adding new processing steps in the event pipeline very easy. For example, let's say we need an additional task to be performed from an event. We only need to add a new consumer to handle the event, without touching any other parts of the application.

Finally, it is much easier to scale each individual module if it is decoupled from the others, than to scale a whole application together.

This is even more beneficial when you have a part that takes much more resources than its counterparts in the event processing pipeline.

But event-driven architecture does not come without disadvantages when not properly thought out. If applied to very simple problems, it can lead to complex workflows that are slow and difficult to debug.

Let's explore some simple ways event-driven architecture can be implemented with Elixir, without the need to write complex pieces of code.

Synchronous Event-Driven Architecture in Elixir

The simplest (and most inefficient) way to run the above flow would be to do everything synchronously in the user request.

So, if you have an Orders module that processes a user's order request, the synchronous implementation could look like this:

defmodule Orders do
  def create_order(attrs) do
    {:ok, order} = save_order(attrs)
    {:ok, _inventory} = update_inventory(order)
    {:ok, _delivery} = create_delivery(order)
    {:ok, order}
  end
end

We can improve this to more easily scale for new event consumers:

defmodule Orders do
  @event_consumers [
    {Inventory, :handle_event},
    {Delivery, :handle_event},
  ]

  def create_order(attrs) do
    {:ok, order} = save_order(attrs)

    event = %Orders.Event{type: :new_order, payload: order}
    @event_consumers
    |> Enum.each(fn {module, func} ->
      apply(module, func, [event])
    end)

    {:ok, order}
  end
end

With this implementation, all we need to do to add new consumers is to add the specification in the @event_consumers array, and those consumers can work independently.

While the synchronous approach works well for a small number of consumers, it has a disadvantage. Creating an order might take a long time because you will need to wait for the inventory to update and the delivery to be created.

These are all internal tasks that can be performed without user interaction and moved from the synchronous chain.

Let's see how we can further streamline event-driven architecture using GenServer.

Using GenServer for Event-Driven Architecture in Elixir

For this implementation, we will run a separate process for each consumer.
These will subscribe to an event from a producer and run their tasks concurrently.

For the event bus, we can use Phoenix.PubSub.
Note that it is possible for apps that don't use Phoenix to directly use Registry as a PubSub.

First, let's look at the producer.

defmodule Orders do
  def create_order(attrs) do
    {:ok, order} = save_order(attrs)
    event = %Orders.Event{type: :new_order, payload: order}
    Phoenix.PubSub.broadcast(:my_app, "new_order", event)
    {:ok, order}
  end
end

On a new order, we create the event struct and use Phoenix.PubSub.broadcast/3 to broadcast that event on the bus. As you can see, it is much simpler than the previous implementation where the Orders module processed tasks from the other module serially.

The consumers can then subscribe to the new_order topic and implement the handle_info/2 to be notified every time a new event is published by the producer.

defmodule Inventory do
  use GenServer

  def start_link(opts), do: GenServer.start_link(__MODULE__, opts, name: __MODULE__)

  def init(_opts) do
    Phoenix.PubSub.subscribe(:my_app, "new_order")
  end

  def handle_info(%Orders.Event{type: :new_order, payload: order}, state) do
    state = consume(state, order.product)
    {:noreply, state}
  end
end

The Delivery module will be very similar to the above, so I am skipping it here.

As you can see, this is much better than the previous implementations. Inventory and Delivery modules can independently subscribe to the new_order topic. The Orders module broadcasts to this topic on new orders and events are delivered to the subscribed processes.

You could even distribute this between multiple nodes and Phoenix.PubSub (with a PG, Redis, or other adapter), spreading the events to all nodes.

Great, right? Not really. There are several issues with this approach:

PubSub provides a real-time broadcast without message queueing, so if one of the subscriber processes is down, it might miss the broadcasts.
If the subscriber does some heavy work, it might not be able to keep up with the incoming messages, resulting in timeouts and consequently crashing the process tree.
If the subscriber experiences an error when processing a message, it is considered consumed and won't be retried later.

So this approach is a bad one to follow for our current use case.

However, the approach still has its use cases. It can be used for tasks that aren't critical, or that can be corrected with the next message: for example, if a task computes the suggestions for a user's next purchases based on their last purchase.

While this would also need to be triggered on a new order, it isn't exactly critical (for a traditional e-commerce website) and can re-compute suggestions for a user on their next purchase.

Event-Driven Implementation Using GenStage in Elixir

In the previous section, we saw a great implementation of our event-driven system using GenServer. But it didn't come without its limitations. Let's see how GenStage fares.

GenStage makes a clear distinction between producers, consumers, and producer_consumers, and each process has to pick one when it starts (in its init/1). In our case, both Inventory and Deliver are consumers, and Orders is a producer.

This is where things start to get a little complicated.
GenStage has a concept of demand. Each consumer can issue a demand of how many events it can handle. The producer needs to send those events to the consumer.

Let's see a basic producer in action.

defmodule Orders do
  use GenStage

  def start_link(opts) do
    GenStage.start_link(__MODULE__, opts, name: __MODULE__)
  end

  def init(_opts) do
    {:producer, :some_state_which_does_not_currently_mattere}
  end

  def create_order(pid, attrs) do
    GenStage.cast(pid, {:create_order, attrs})
  end

  def handle_cast({:create_order, attrs}, state) do
    {:ok, order} = save_order(attrs)
    {:noreply, [%Orders.Event{type: new_order, payload: order}], state}
  end

  def handle_demand(_demand, state), do: {:noreply, [], state}
end

The meat of our code is in handle_cast, where we save the order and return a tuple like {:noreply, events, new_state}.
The new events are stored in an internal GenStage buffer and dispatched to the consumers as they make new demands (or immediately, if there are consumers with unmet demand).

Let's check out a sample implementation of the consumer:

defmodule Inventory do
  use GenStage

  def start_link(opts) do
    GenStage.start_link(__MODULE__, opts, name: __MODULE__)
  end

  def init(_opts) do
    {:consumer, [], subscribe_to: [Orders]}
  end

  def handle_events(events, _from, state) do
    state = Enum.reduce(events, state, & handle_event(&1, &2))
    {:noreply, [], state}
  end

  def handle_event(%Orders.Event{type: :new_order, payload: order}, state) do
    new_state = update_inventory(order)
    new_state
  end
end

In the consumer, first notice that we have a subscribe_to inside init/1. This automatically subscribes Inventory to any events published by Orders. Please check the GenStage documentation for additional options available in init.

Here, most of the work happens inside handle_events/3, which is automatically called by GenStage as soon as new events become available.

We handle the new_order event here, updating the inventory and returning a new state.

With this simple implementation, we get several benefits that outpace the GenServer implementation:

Automatic buffering of events inside GenStage's internal buffer when the producer has new events without any available consumer.

Even if consumers are down when some events are produced, we are still guaranteed to receive them when the consumer comes back up.

Check out Genstage's guide on buffering demand for advanced buffering logic.

Automatic distribution of work on multiple consumers.

If you have heavy consumer tasks, you can start multiple consumer processes. The default DemandDispatcher for GenStage will distribute the work evenly across all processes.

See GenStage.Dispatcher for other dispatch strategies to distribute events to all consumers or partition distribution to consumers based on a hash function.

But, as with GenServer or synchronous implementation, using GenStage does not come without its problems.

If a consumer crashes while it is processing an event, GenStage will consider the event delivered and will not send it again when the consumer comes back up.

To make sure that you properly track crashes, you can use a monitoring service like AppSignal. AppSignal is easy to install for your Elixir app and helps you monitor performance as well as track errors. Here's an example of an error tracking dashboard that AppSignal provides:

You can set up notifications for crashes via AppSignal as well.

On the app side, you can cache such events in a persistent store once they are delivered to the consumer. If the consumer crashes, then once it recovers, it can revert to the cached events.

Be very cautious about producing too many events without enough consumers, though. While GenStage offers automatic buffering of events, this buffer has a (configurable) maximum size and a practical maximum size constrained by the server's memory.

If you don't control the frequency with which events are produced, consider using an external data store like Redis or Postgres to buffer events.

Wrap Up: Event-Driven Architecture in Elixir — Going Beyond GenStage

In this post, we examined three approaches to implementing an event-driven system in Elixir: synchronously, using GenServer, and finally, using GenStage. We took a look at some of the advantages and disadvantages of each approach.

The simple GenStage example can be a starting point for implementing complex event-driven data processing pipelines that span multiple nodes. I suggest you read the great GenStage documentation for more information.

If you are looking for an even higher-level abstraction, Broadway is a good starting point. It is built on top of GenStage and offers several additional features, including consuming data from external queues like Amazon SQS, Apache Kafka, and RabbitMQ.

Until next time, happy coding!

P.S. If you'd like to read Elixir Alchemy posts as soon as they get off the press, subscribe to our Elixir Alchemy newsletter and never miss a single post!

Delayed Job vs. Sidekiq: Which Is Better?

Sapan Diwakar — Tue, 08 Mar 2022 12:44:49 +0000

Most applications need background jobs for mailers, regular clean-ups, or any other time-consuming operation that doesn't require a user to be present.

Several gems support job queues and background processing in the Rails world — Delayed Job and Sidekiq being the two most popular ones.

In this post, we will take a detailed look at Delayed Job and Sidekiq, including how they fare against each other.

Let's go!

A Quick Introduction to Delayed Job

Delayed Job is a direct extraction from Shopify and uses a table to maintain all background jobs. It follows a very simple pattern. Any Ruby object that responds to a perform method can be enqueued in the jobs table.

In addition, if you don't need to maintain special job objects (although this is highly recommended for testability and clear separation of long-running operations), it also allows you to call .delay.method(params) on any Ruby object. It will process the method in the background.

The Delayed Job README does a great job of explaining all common usage patterns.

Many teams choose Delayed Job because it is simple and uses their already existing database. They don't need to spend/maintain other resources.

However, it will still take up space in your database table. If you have too many jobs queued at the same time, you might need more disk space to accommodate them all.

A Quick Introduction to Sidekiq

Sidekiq, on the other hand, uses Redis as its data store to maintain all job metadata. This comes with the obvious benefit of being much faster than the regular database systems Delayed Jobs uses. In addition to this, each Sidekiq process spawns multiple threads to process the jobs even faster.

For each background job in Sidekiq, we need a specialized class that includes the Sidekiq::Worker concern and responds to the perform method. To enqueue the job, we need to call perform_async(arg1, arg2) on the worker with the arguments.

The Sidekiq 'Getting Started' guide explains this and other usage patterns in good detail.

Using Active Job with Delayed Job or Sidekiq

Rails already provides a mature job framework for top-level declaration and handling of jobs. Both Delayed Job and Sidekiq support running jobs through ActiveJob's unified API. Just inherit from ApplicationJob and call perform_later on your job class to enqueue the job to the configured queuing backend.

The advantage of running jobs with Active Job is that your application code becomes framework agnostic, and switching from Delayed Job to Sidekiq (or vice versa) becomes pretty easy. The ActiveJob::TestHelper also makes testing enqueued jobs a breeze.

But the abstraction provided by Active Job also comes with a performance overhead, as job data has to be wrapped before it's pushed to the store.

Sidekiq claims that ActiveJob is about 2-20x slower when pushing to Redis, with ~3x the processing overhead.

Delayed Jobs vs. Sidekiq

Now that we know the basics of Delayed Jobs and Sidekiq, let's dive deeper into their differences and what each brings to the table.

The Features

For basic applications, both Sidekiq and Delayed Job provide a good set of features out of the box.

These include assigning job priorities, named queues, and auto-retry on failures.

Delayed Job also provides a way to configure max run time out of the box (Sidekiq does not).

Sidekiq, on the other hand, provides support for Middleware to update job metadata, skip queuing a job, or execute a job.

Sidekiq supports more callbacks, though some hooks are available for Delayed Job apps. Instead of callbacks, you can use Delayed Job with Active Job (namely, the before_enqueue and around_perform callbacks inbuilt into Rails).

Web UI is another feature that comes out of the box with Sidekiq. This provides historical statistics about jobs and information about workers, currently enqueued and dead jobs. You can perform operations like deleting or running jobs immediately without going through the console.

Delayed Job does not have an inbuilt Web UI, but delayed_job_web gives access to a basic Web UI with similar features to Sidekiq's.

Sidekiq Wins at Performance

Performance-wise, Sidekiq beats Delayed Job quite convincingly. According to Sidekiq's open-source benchmark, it is approximately 30x faster than Delayed Job.

There are two major reasons for this:

Redis is much faster at querying data than traditional databases like Postgres because it stores data in memory as opposed to the disk.
Delayed Job runs a single thread to process jobs, compared to Sidekiq, which uses multiple threads.

While all of this looks great on paper, the differences do not matter much unless you work on a big scale (something like 10k jobs per minute).

The exact number also depends on the average run time of a job. The longer the run time, the less the performance overhead of Delayed Job matters.

If you're worried about the performance of Delayed Job, you can make some performance optimizations. The exact indexes to use will depend on the statistics of your job system.

For example, if you use multiple queues and only one gets a major chunk of jobs, a simple index on the queue column (add_index :delayed_jobs, :queue) can significantly improve performance.

In AppSignal, Sidekiq magic dashboard gets automatically generated and it enables you to monitor queue length, queue latency, job duration, job statuses, memory usage, etc.

Deployment

Both Delayed Job and Sidekiq have a similar deployment strategy for workers.

Using Heroku, you just need to add entries inside your Procfile to start the job processor and run the workers.

For Sidekiq:

worker: bundle exec sidekiq -t 25 -c ${SIDEKIQ_CONCURRENCY:-5} [-q name,priority [-q another_queue,another_priority]]

For Delayed Job:

worker: [QUEUE=x,y,z] bundle exec rails jobs:work

Memory

Here's where things start to get a bit more interesting. Sidekiq has a concurrency option to control how many threads it runs.

Most of the Sidekiq vs. Delayed Job benchmarks mention Sidekiq's very high concurrency of up to 25 threads, which contributes to its super-fast performance.

But in a real setting, you have to limit the threads to something more conservative. The actual number depends on how heavy your application is and what kinds of jobs you perform.

What I have seen in practice is that if you run a worker on 512MB memory (equivalent to standard-1x on Heroku), the number of threads is somewhere between 2 and 5 instead of 25.

'Taming Rails memory bloat' by Mike Perham, the creator of Sidekiq, discusses memory issues in more detail and is well worth a read.

I won't jump into the full discussion, but he recommends that you set MALLOC_ARENA_MAX=2 on all workers that run Sidekiq.

Using jemalloc instead of regular malloc helps too. The exact way to do this depends on the platform you use, but it is pretty simple on Heroku. Just set heroku-buildpack-jemalloc as the first buildpack (ahead of the heroku/ruby buildpack).

Delayed Job Uses Simpler Resources

As we discussed, Delayed Job runs on your existing database instance.

You might need to increase:

the available memory
disk space
max connections

depending on the job load or the number of workers you run. But the only resource you need is the job processor.

On the other hand, Sidekiq requires a Redis instance to handle jobs. If you also use Redis as a cache store, it is recommended that you use a separate instance configured as a "persistent store" for Sidekiq jobs.

Since Redis works best when everything fits in memory, if you have too many jobs (for example, if Sidekiq stops processing them for some time due to an issue in the app), it might take some downtime to clear everything up.

This is especially troublesome if you have Redis on the same server as your app. They will start competing for memory, leading to swapping and eventually destroying your app's performance.

One important point to note about Redis is that it has to be configured with maxmemory-policy noeviction to avoid silent drops of Sidekiq's data. Otherwise, you will find yourself missing jobs that need to be performed, without any trace.

A Side-Note: Paid Upgrades in Sidekiq

If you need extra features, Sidekiq comes with Pro and Enterprise versions.

The most notable addition to Pro is Batch Jobs that can run in parallel, be monitored, and interact as a group, invoking a callback when all jobs are done. Pro also has improved reliability features to ensure that no jobs are dropped silently, even during network problems.

The Enterprise version comes with yet more features. If you are looking for something that a regular Sidekiq installation can't solve, explore the paid Sidekiq features.

In practice, the free version of Sidekiq still works great.
But it is good to know that there are paid options you can upgrade to as needed, instead of switching to a different solution.

Community and Development Status: Sidekiq Has the Edge

There is a huge community behind both Sidekiq and Delayed Job. However, it is not always easy to find quick answers to your questions in StackOverflow or the official documentation.

On the development side, things are not looking very bright for Delayed Job. There was some minor work done on Delayed Job in December 2021 and January 2022, but it doesn't seem like it is getting any major developments going forward. It appears to be in maintenance-only mode, and there are a lot of open issues on Github.

In contrast, Sidekiq is still under active development, and its creator is working full time on it. There are very few open issues, and they get addressed regularly.

Wrap-up: Sidekiq or Delayed Job? It Depends on Your Needs

In this post, we covered two major job processing systems for Rails applications — Sidekiq and Delayed Job — taking a look at some of their pros and cons.

There are different use cases for each. It all depends on the budget and scale of your operation.

If performance and long-term maintainability are of importance, Sidekiq is a no-brainer. On the other hand, if running costs are a concern, Delayed Job can help you there.

Whether you choose Delayed Job or Sidekiq, good luck with your project and happy coding!

👋 If you liked this article, take a look at other Ruby (on Rails) performance articles in our Ruby performance monitoring checklist.

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

Authorization and Policy Scopes for Phoenix Apps

Sapan Diwakar — Tue, 16 Nov 2021 15:09:20 +0000

Authorization (not to be confused with authentication) is vital to every application but often isn't given much thought before implementation. The IETF Site Security Handbook defines authorization as:

The process of granting privileges to processes and, ultimately, users. This differs from authentication in that authentication is the process used to identify a user. Once identified (reliably), the privileges, rights, property, and permissible actions of the user are determined by authorization.

So, in short, authorization is about defining access policies and scoping.

For example, consider a platform like Github.
In very simple terms, it must handle which repositories:

a particular user is allowed to read (this is policy scoping)
the user is allowed to write to (authorization)

If you come from the Rails world, you might be familiar with some gems that provide APIs to handle this, the most popular ones being cancancan and pundit.

In today's post, we'll take a close look at the two critical components of authorization — access policies and scoping. I'll show you how you can roll out your own solution for each in Phoenix and how to leverage the Bodyguard library for quick and easy authorization.

Authorization in Phoenix

There are two parts to authorization that we need to keep in mind:

Access policy — Is this user allowed to perform this operation on this resource?
Policy scope — Which resources is this user allowed to see?

While it is definitely possible to roll out something by hand, it usually makes sense not to reinvent the wheel if well-maintained and tested libraries are available.
Canada and Bodyguard are two of the more popular ones that I have seen in the community.

Let's see what implementation might look like for our own solution and also with Bodyguard. We will use a CMS example similar to what the official Phoenix Context guide uses. This CMS allows users to create pages and share them with everyone. Only the author should be able to edit, update, or delete a page once created, but everyone else should see the page.

Implementing Access Policies

Getting back to our CMS example — when the user is on a page, we need an access policy that decides if the user is allowed to perform an action (say, edit) on the page.

Roll Your Own Access Policy

The following is what the official Phoenix guide suggests. This is also what most of us would do, were we rolling out our own authorization solution:

defmodule Hello.CMS.PageController do
  plug :authorize_page when action in [:edit, :update, :delete]

  defp authorize_page(conn, _) do
    page = CMS.get_page!(conn.params["id"])

    if conn.assigns.current_author.id == page.author_id do
      assign(conn, :page, page)
    else
      conn
      |> put_flash(:error, "You can't modify that page")
      |> redirect(to: Routes.cms_page_path(conn, :index))
      |> halt()
    end
  end
end

The implementation is straightforward. We use the :authorize_page plug for edit, update, or delete actions. In that plug, we allow the action only if the page's author is the same as the current user. Otherwise, we redirect to an index page that shows an error.

Use Bodyguard

We can also implement an access policy using Bodyguard.Policy behavior. Depending on the level of access scoping you need, this behavior could be placed on the controller or directly on the underlying context. I usually like to define a separate Policy module to handle this and then delegate the methods from the behavior's target:

defmodule Hello.CMS.Policy do
  @behaviour Bodyguard.Policy

  alias Hello.Accounts.User

  # Super Admins can do anything
  def authorize(_action, %User{role: :super_admin}, _params), do: true

  # Users can list/get/create anything
  def authorize(action, %User{role: :user}, _params) when action in ~w[index show create]a, do: true

  # Users can edit/update/delete own pages
  def authorize(action, %User{id: id, role: :user} = user, %{author_id: ^id})
    when action in ~w[update edit delete]a,
    do: true

   # Default blacklist
  def authorize(_action, _user, _params), do: false
end

Here, we see that we defined authorize(action, user, params) that returns true/false to permit (or not) the action on the resource. You can also get additional control on the error messages by returning {:error, reason} instead of just false.

The Bodyguard.Policy behavior expects the callbacks to return:

:ok or true to permit an action.
:error, {:error, reason}, or false to deny an action.

Then, on the context or the controller, all you need is to delegate the authorize method to our Policy module and then call Bodyguard.permit:

defmodule Hello.CMS.PageController do
  plug :authorize_page

  defp authorize_page(conn, _) do
    page = CMS.show(conn.params["id"])

    case Bodyguard.permit(__MODULE__, action, user, page) do
      :ok ->
        assign(conn, :page, page)
      {:error, _reason} ->
        conn
        |> put_flash(:error, "You can't access that page")
        |> redirect(to: Routes.cms_page_path(conn, :index))
        |> halt()
    end
  end

  defdelegate authorize(action, user, params), to: Hello.CMS.Policy
end

To authorize an action, we can call Bodyguard.permit(Hello.CMS.PageController, action, user).
Bodyguard.permit/4 also accepts passing a fourth argument's authorization in the actual resource.

This form can be used to authorize actions performed on a single resource (for example, update or delete).

Under the hood, Bodyguard.permit calls authorize on the module we provided as the first argument.

The return value is then normalized into :ok or {:error, reason} (regardless of whether we were returning true/:ok or false/:error/{:error, reason} from that method).

While delegating authorize from the controller works well, there might be cases when you need similar access control in multiple places. For example, the same resource could be accessed from your controller and through an Absinthe Resolver exposed through the GraphQL API.

For such cases, I suggest delegating authorize/3 on the Phoenix context module:

defmodule Hello.CMS do
  # ...
  defdelegate authorize(action, user, params), to: Hello.CMS.Policy
end

Then, when you need to call Bodyguard.permit from your controller (or the Absinthe Resolver), pass in a first argument of that context module:

defmodule Hello.CMS.PageController do
  defp authorize_page(conn, _) do
    page = CMS.show(conn.params["id"])
    case Bodyguard.permit(CMS, action, user, page) do
      :ok ->
        # OK. Render page
      {:error, reason} ->
        # Error. Show flash and redirect
    end
  end
end

It is also very easy to write tests for the above policy. Here's what the tests might look like:

test "allows users to list pages" do
  user = Hello.Accounts.Fixtures.fixture(:user)
  assert :ok = Bodyguard.permit(Hello.CMS, :index, user)
end

test "allows user to update/delete own pages" do
  user = Hello.Accounts.Fixtures.fixture(:user)
  page = page_fixture(user)
  assert :ok = Bodyguard.permit(Hello.CMS, :update, user, page)
end

test "allows user to create pages" do
  user = Hello.Accounts.Fixtures.fixture(:user)
  assert :ok = Bodyguard.permit(Hello.CMS, :create, user)
end

test "does not allow user to update/delete pages of someone else" do
  user1 = Hello.Accounts.Fixtures.fixture(:user)
  user2 = Hello.Accounts.Fixtures.fixture(:user)

  page = page_fixture(user2)

  assert {:error, :unauthorized} = Bodyguard.permit(Hello.CMS, :update, user1, page)
end

test "allows super_admin to do anything" do
  super_admin = Hello.Accounts.Fixtures.fixture(:user_super_admin)
  user = Hello.Accounts.Fixtures.fixture(:user)
  page = page_fixture(user)
  assert :ok = Bodyguard.permit(Hello.CMS, :index, super_admin)
  assert :ok = Bodyguard.permit(Hello.CMS, :create, super_admin)
  assert :ok = Bodyguard.permit(Hello.CMS, :update, super_admin, page)
end

Implementing Policy Scopes

We've now allowed users to access resources based on some attributes. The next part of the puzzle is to handle the listing of resources. As you might have noticed above, we are allowing users to list everything.

But you might have specific business requirements on what a user can and can't list. For example, in the Github example, users can only see public repositories and the repositories that they have access to (e.g., through their organization or team). Similarly, you could set a restriction that users see all published posts but only their own drafts in a CMS.

Roll Your Own Policy Scoping

This just boils down to using the correct queries based on the user and their access rights. For example, a simple implementation inside a context could look like this:

defmodule Hello.CMS do
  def list_pages(%{id: id} = user) do
    Page
    |> where(author_id: ^id)
    |> or_where(state: :published)
    |> Repo.all()
  end
end

It is definitely possible to do this with simple Ecto queries on the accessor methods. However, it usually makes much more sense to centralize these kinds of domain requirements so that future developers don't forget to include one of the requirements while adding a new feature.

Use Bodyguard

With Bodyguard, we can provide default scoping to query items that a user can access. Implement a scope/3 function inside an Ecto.Schema module from the @behaviour Bodyguard.Schema. The function should filter the query down to only include the resources the user is allowed to access. You can also pass custom params when invoking the scoping to provide further filtering.

Here's how it looks in practice:

defmodule Hello.CMS.Page do
  use Ecto.Schema

  alias Hello.Accounts.User

  def scope(query, user, params) do
    scope_published(query, user, params)
  end

  # Signed in users can access published posts or their own posts (in any state)
  defp scope_published(query, %User{role: :user, id: id}, _params) do
    query
    |> where(author_id: ^id)
    |> or_where(state: :published)
  end

  # Super admins can access anything
  defp scope_published(query, %User{role: :super_admin}, _params), do: query

  # Anonymous users can access only published posts
  defp scope_published(query, _user, _params), do: query |> where(state: :published)
end

Now, this can then be used inside your context when querying. For example:

defmodule Hello.CMS do
  def list_pages(user) do
    Page
    |> Bodyguard.scope(user) # <-- defers to Page.scope/3
    |> Repo.all()
  end
end

If we need to add another listing of the pages later, we can simply use the same Bodyguard.scope(query, user) call and know that everything will be appropriately scoped.

Authorization in Phoenix: Further Reading

In this post, we saw how to implement authorization in your Phoenix apps.

We focused on a simple CMS example to explore authorization with — and without — external libraries.

I recommend Dockyard's Authorization Considerations For Phoenix Contexts blog post for a more detailed look at rolling out your authorization solution.

If you are looking for external libraries, check out Bodyguard.
I have been using it in production for a while and can vouch for its customizability in authorization. It stays out of the way when we don't want it and also clarifies operations that would otherwise be scattered inside the context and controller methods.

I hope you've found this a useful guide that's inspired you to dive into policy scoping and authorization in Phoenix apps.

Until next time, happy coding!

P.S. If you'd like to read Elixir Alchemy posts as soon as they get off the press, subscribe to our Elixir Alchemy newsletter and never miss a single post!

Sapan Diwakar is a full-stack developer. He writes about his interests on his blog and is a big fan of keeping things simple, in life and in code. When he’s not working with technology, he loves to spend time in the garden, hiking around forests, and playing outdoor sports.

DEV Community: Sapan Diwakar

Find and Fix N+1 Queries Using AppSignal for a Phoenix App in Elixir

Understanding And Fixing N+1 Queries in Phoenix for Elixir

A Simple Example Using Ecto

Complex Situations Leading to N+1 Queries

Detecting N+1 Queries By Their Impact

Detecting N+1 Queries in Phoenix for Elixir Using AppSignal

Analyzing Elixir Data with AppSignal

Use Slow Queries to Find N+1 Queries

Trace N+1 Queries with the Event Timeline

Addressing Detected N+1 Queries

Wrapping Up

Scaling Your Phoenix App in Elixir with FLAME

Understanding FLAME for Phoenix

FLAME in Action

Install FLAME

Start a FLAME Pool

Configure FLAME Backend

Running Tasks with FLAME

Deploying FLAME

Technical Deep Dive into FLAME

Understanding Closures

Leveraging Files as Processes

Comparing FLAME With Other Approaches

Running Background Tasks on the Same Node

Using Oban for Elixir to Get More Control

Achieving Infinite Scale with Serverless Functions

FLAME: A Summary

Wrapping Up

Deep Diving Into the Erlang Scheduler

Processes in Erlang

Erlang Scheduler Architecture — Preemptive Scheduling

Reductions

Priority

Running on Multiple Cores

Performance and Optimization

Wrapping Up

A Deep Dive into Mutations with Absinthe

A Note on Queries Vs. Mutations in GraphQL

Mutations in GraphQL

Input Objects with Absinthe for Elixir

Defining Mutations in Absinthe

Authorization in Your Elixir App with GraphQL and Absinthe

An Example Using Absinthe Context

Middleware in Absinthe for Elixir

Implement RequireUser Middleware

Chaining Middleware

Wrap Up

Absinthe for Large Elixir Applications

Defining Resolvers for a Large Elixir App

Avoiding N+1 Queries in Elixir

Dataloader to the Rescue!

Use Dataloader Inside the Absinthe Schema

Organizing Your Absinthe Schema with Imports

Wrap Up

An Introduction to Absinthe

GraphQL

GraphQL Schema

GraphQL Query and Mutation

GraphQL API

Setting Up Your Elixir App with GraphQL and Absinthe

Define the Absinthe Schema and Query

Define the Type In Absinthe

Using Scalar Types

Type Modifiers and More

Wrap Up

Under the Hood of Ecto

Ecto's Modules

Repo Module

Monitor Queries Sent to Ecto from Your Elixir Application

Instrumenting Ecto Queries with AppSignal in Your Elixir App

Query Module

ASTs in the Query

Back to Erlang's ETS Table

Schema Module

A Schema Module In Action on an Elixir App

Changeset Module

The cast/4 Changeset

The validate_required/3 Changeset

Wrapping Up

Implement `RequireUser` Middleware

The `cast/4` Changeset

The `validate_required/3` Changeset