DEV Community: Artyom Molchanov

Ash Framework: ways to contact — AshJsonApi, AshGraphQL and AshTypescript

Artyom Molchanov — Fri, 03 Jul 2026 08:21:04 +0000

Building a stable product capable of withstanding high loads across different servers is a complex and resource-intensive task. A programmer can't focus on business logic alone: first you need to set up the database, design the server-side API, and much more.

The complexity grows manyfold when you work solo. You end up implementing the interface yourself on your framework of choice, ensuring the layers stay compatible, packaging the project into Docker images, and deploying it to Kubernetes. Add to that configuring request routing through Nginx and designing the system according to clean-architecture principles — and you get an extremely labor-intensive process.

That's why many languages are actively adopting tools to automate routine work (boilerplate), letting you concentrate on the unique code. In Go, for example, there's the oapi-codegen library: you describe the contract in Swagger format, and the server code is generated from it automatically. This format simplifies frontend–backend integration and makes changing logic less painful — just update the description in the Swagger file and regenerate the service.

Approaches like this — systematizing repetitive tasks — are appearing everywhere. The main goal is to make integration predictable and eliminate the situation where a developer has to rewrite and test the same thing dozens of times just to achieve perfect compatibility. And in this area there's a clear leader — Ash!

ㅤ

🙏 Acknowledgments

I want to express my deep gratitude to Zach Daniel and everyone who responded to my previous article about Ash (Ash Framework: Introduction) and shared it. Your support gave me a huge boost of energy and motivation and confirmed that the Ash community is amazing!

ㅤ

📖 Foreword

In this material I deliberately won't provide a complete practical guide to the topics covered, since I'm counting on your curiosity. As much as I'd like to cover everything, I can't describe the entire practical side of these frameworks in a single article and teach you everything at once. Instead, I'll share information with you and set a direction for reflection — which is the main purpose of this publication. For a deeper dive into how these libraries work, I recommend starting to build your own projects on top of them — that's the approach that once helped me understand their internals best. Remember that your main mentor will be practice, so good luck mastering it!

Important: the goal of this article is by no means to talk you into using Ash everywhere and always!

ㅤ

🧐 What the Ash ecosystem offers

If you're familiar with Elixir and Phoenix, you know the framework already contains built-in mechanisms to simplify development. One of them is LiveView. It lets you drop the classic split into an API backend and a separate JavaScript frontend: the interface is written right inside the application. This speeds up development and is convenient for backend programmers working without a frontend team. For simple and medium projects the LiveView path is a great fit, but when building large-scale systems the code risks turning into "spaghetti," where it's hard to track dependencies between components and to find handlers like def handle_params/3.

But what if you need a solid, standalone frontend, yet you're tired of writing a boilerplate REST interface and wiring up the connection from scratch every time? The answer is to master what Ash has to offer. That's what we'll talk about.

ㅤ

😮 REST with AshJsonApi: a new approach

Standard practice involves pinning down the contract between frontend and backend not only verbally but also in writing — usually via Swagger. It describes the data structures and API methods, after which the documentation is handed to the interface team. Any changes require care so as not to break compatibility. Even the basic setup of this approach costs considerable effort: you need to integrate a generation library, create configurations per the OpenAPI (Swagger) specification, and manually describe the endpoints. If you're rewriting an existing project, the process can easily take more than a workday.

AshJsonApi offers an alternative. The main advantage is that you no longer need to write a specification in YAML/JSON upfront and generate code from it. To get started, all you need is a ready domain of resources and the AshJsonApi extension enabled.

You can create a new project with support for this tool right on the main page of the Ash portal via the builder. If you already have an Ash project, you can add the functionality with a single command:

mix igniter.install ash_json_api

During installation, the system asks clarifying questions (Y/N). You can agree with all the suggestions or study each item and decide for yourself. After installation, a few simple steps remain.

Configuring a resource to work with JSON:API

To make resources available through the API, enable the AshJsonApi.Resource extension. This will let you automatically generate endpoints based on your domain definitions. Add AshJsonApi.Resource to the extensions list and set the resource name in the type parameter:

defmodule CourseHub.Courses.Lesson do
  use Ash.Resource, extensions: [AshJsonApi.Resource]

  # Enable endpoint generation
  json_api do
    type "lesson"
  end

  actions do
    defaults [:read, :create, :destroy, :update]

    action :list_lessons_allowed, :map do
      run fn _input, _ctx ->
        allowed_courses = %{"go" => "Golang", "elixir" => "Elixir", "rust" => "Rust"}
        {:ok, allowed_courses}
      end
    end
  end
end

The type parameter defines the resource name in the JSON:API namespace. It's used primarily for documentation (e.g., in Swagger or Redoc) and lets you group methods by tags.

Next, describe the routes in the domain, specifying the paths and linking them to specific resource actions:

defmodule CourseHub.Courses do
  use Ash.Domain, extensions: [AshJsonApi.Domain]

  json_api do
    routes do
      base_route "/lessons", CourseHub.Courses.Lesson do
        index :read, description: "Get the list of lessons"
        get :read, primary?: true, description: "Get a single lesson"
        post :create, description: "Create a lesson"
        patch :update, description: "Update a lesson"
        delete :destroy, description: "Delete a lesson"

        # Path is relative to base_route; final endpoint: /lessons/allowed
        route :get, "/allowed", :list_lessons_allowed,
          description: "Get the list of allowed lessons"
      end
    end
  end
end

Once you've done this, you get six fully functional endpoints. All the logic is now tied to your actions inside the domain model. Separate Swagger files or manual route definitions aren't needed: a change to the action's logic in the code is automatically reflected in the behavior of the corresponding API endpoint.

Key strengths of AshJsonApi

A unified approach and predictability

The main advantage is the strict consistency of your application. When switching to a different contract type (e.g., GraphQL), you won't have to rewrite your business logic. Because AshJsonApi works on top of your actions, you're insured against the situation where changes in the code aren't reflected in one of the interfaces: all the logic is encapsulated in the action, which you "hand off" to different contracts. This noticeably speeds up development — by my own estimate, a finished product comes together roughly five times faster. To automate the process, you can use the command:

mix ash.patch.extend CourseHub.Courses.Lesson json_api

By specifying the resource's address, you let AshJsonApi automatically generate all the plumbing needed to work with the API.

Working with data: filtering, sorting, and relationships

As a backend developer, I used to spend a lot of time on the routine implementation of filters and sorting, hand-writing SQL with LIMIT, OFFSET, and WHERE. AshJsonApi removes this burden: filtering and ordering happen automatically. The frontend just needs to specify the required fields and conditions right in the request. This dramatically simplifies collaboration between teams: the frontend forms its own data queries without distracting the backend. And all computation happens on the server, so the client bears no extra load — it merely describes the desired shape of the data. The full list of parameters is in the official documentation. An example request:

GET /courses/1?include=lessons&included_page[lessons][limit]=10&included_page[lessons][offset]=20

The request returns information about the course and loads the related lessons with the given pagination. The response comes in application/vnd.api+json format — a standardized specification (more at jsonapi.org) that structures JSON for predictable handling.

An example response:

{
  "data": {
    "id": "1",
    "type": "course",
    "attributes": {
      "title": "My Course!"
    },
    "relationships": {
      "lessons": {
        "data": [
          {"id": "1", "type": "lessons"},
          {"id": "2", "type": "lessons"}
        ],
        "links": {
          "self": "/courses/1/relationships/lessons",
          "related": "/courses/1/lessons",
          "first": "/courses/1?include=lessons&included_page[lessons][limit]=10",
          "next": "/courses/1?include=lessons&included_page[lessons][limit]=10&included_page[lessons][offset]=10",
          "prev": null,
          "last": "/courses/1?include=lessons&included_page[lessons][limit]=10&included_page[lessons][offset]=40"
        },
        "meta": {
          "limit": 10,
          "offset": 0,
          "count": 50
        }
      }
    }
  },
  "included": [
    {
      "id": "1",
      "type": "lessons",
      "attributes": {
        "description": "Lessons about Elixir 1!"
      }
    },
    {
      "id": "2",
      "type": "lessons",
      "attributes": {
        "description": "Lessons about Elixir 2!"
      }
    }
  ]
}

Wrap-up and personal experience

To sum up, I'll share my experience. On my current project, creating the REST endpoints took just 20–30 minutes. Most of the time went into customizing how the documentation is rendered in Redoc — that turned out to be fairly labor-intensive (unlike generating the API itself). If you decide to use Redoc, be prepared to manually rewrite its blocks for a nice presentation of responses and examples.

Otherwise the tool performed excellently: superb flexibility, customizable error handling, fine-grained control over endpoint access. If your goal is to build a convenient and powerful REST API, AshJsonApi is an excellent choice.

ㅤ

🙂‍↕️ AshGraphQL

This library may come with some difficulties: not that many people have worked with GraphQL at all. So first I'll give an introduction — to refresh your memory or learn what it is — and then we'll look at the library itself.

What GraphQL is

GraphQL is a query language for APIs and a runtime for executing them. The client itself describes what data it needs, and the server returns exactly that shape. The contract is a strictly typed schema.

Fundamental principles

Interaction happens through a single endpoint (usually POST /graphql). The logic is built around a graph of types. A query has a hierarchical structure, and the server's response mirrors it exactly. This solves the problems of over-fetching and under-fetching.

Types of operations

Query — read operations (idempotent).
Mutation — data-modifying operations (executed sequentially).
Subscription — subscribing to a stream of real-time events (via WebSocket).

Schema and resolvers

The central element is the schema, described in SDL. It serves as the source of truth and enables introspection. Each field is mapped to a resolver — a function that returns a value. The server traverses the query tree and calls the resolvers for each field.

Difficulties

The N+1 problem. Resolvers work independently, and without optimization (batching) this leads to a multitude of database queries
Caching. Standard HTTP mechanisms (CDN, ETag) don't work, since everything goes through POST. A normalized cache on the client is required
Security. A client can send a deeply nested query that overloads the database. Depth limiting and complexity analysis are needed
Errors. The server almost always returns status 200, and the errors themselves are placed in an errors array alongside partial data. This breaks monitoring based on HTTP status codes
Infrastructure. File uploads, rate limiting, and observability require a separate infrastructure layer

Where it's effective

The technology pays off when there are many diverse clients with complex data requirements. For a single client with simple resources, it's easier to go with REST. For internal service-to-service communication with rigid contracts and minimal latency, gRPC is a better fit.

What AshGraphQL is

Despite GraphQL still being less popular than other approaches, its integration with Ash is done very well. The technology is easy to bring into Ash-based projects.

To get started, add the library to your project:

mix igniter.install ash_graphql

Then, in your schema module, specify the domains you use:

use AshGraphql, domains: [Your.Domain1, Your.Domain2]

Configuring resources and domains

To make a resource available through GraphQL, enable the AshGraphql.Resource extension and describe the base configuration block:

defmodule CourseHub.Courses.Lesson do
  use Ash.Resource,
    extensions: [
      AshGraphql.Resource
    ]

  graphql do
    type :lesson
  end

  # ... rest of the resource logic
end

In the domain module, define the operations (handles) via the AshGraphql.Domain extension:

defmodule CourseHub.Courses do
  use Ash.Domain,
    extensions: [
      AshGraphql.Domain
    ]

  graphql do
    queries do
      get CourseHub.Courses.Lesson, :get_lesson, :read
      read_one CourseHub.Courses.Lesson, :most_popular_lesson, :most_popular
      list CourseHub.Courses.Lesson, :list_lessons, :read
    end

    mutations do
      create CourseHub.Courses.Lesson, :create_lesson, :create
      update CourseHub.Courses.Lesson, :update_lesson, :update
      destroy CourseHub.Courses.Lesson, :destroy_lesson, :destroy
    end
  end
end

These handles can be described not only in the domain module, but also right inside the resource.

In addition, you can create your own actions for custom responses. Example:

graphql do
  type :lesson

  queries do
    action :random_lesson, :random_lesson
  end
end

actions do
  action :random_lesson, {:array, :struct} do
    constraints items: [instance_of: __MODULE__]

    run fn _input, _context ->
      # return a list of structs, as declared in the action type
      Ash.read(__MODULE__)
    end
  end
end

Generating the SDL schema

As with AshJsonApi (where Swagger is generated automatically after edits), the GraphQL schema is updated in a similar way. Specify the path for saving it in use AshGraphql via generate_sdl_file:. The file will be generated automatically on every run of mix ash.codegen (if auto_generate_sdl_file?: true is enabled):

use AshGraphql,
  domains: [Domain1, Domain2],
  generate_sdl_file: "priv/schema.graphql",
  auto_generate_sdl_file?: true

Creating Subscriptions

You can set up receiving data in real time through the subscriptions mechanism. This uses Absinthe configuration:

# in your Absinthe schema file
subscription do
  field :field, :type_name do
    config(fn
      _args, %{context: %{current_user: %{id: user_id}}} ->
        {:ok, topic: user_id, context_id: "user/#{user_id}"}

      _args, _context ->
        {:error, :unauthorized}
    end)

    resolve(fn args, _, resolution ->
      AshGraphql.Subscription.query_for_subscription(
        YourResource,
        YourDomain,
        resolution
      )
      |> Ash.Query.filter(id == ^args.id)
      |> Ash.read(actor: resolution.context.current_user)
    end)
  end
end

Monitoring

For a deeper dive I recommend the official Ash monitoring guide. Here we'll briefly describe the tracing mechanisms and telemetry events that become available with this extension.

You can define your own tracer at the domain level — its settings take precedence over the global config :ash, :tracer parameter:

graphql do
  tracer MyApp.Tracer
end

Traces

The operations of GraphQL resolvers and of the underlying batch data loaders are wrapped in spans with appropriate names. For convenience, they're tagged with the source: :graphql metadata, which lets you filter or annotate this data in your monitoring system.

Telemetry

The AshGraphql module publishes telemetry events, each suffixed with :start and :stop. Start events (:start) carry a system_time measurement, while stop events (:stop) carry system_time and the execution duration. All time values are given in the native time unit.

The list of emitted events:

[:ash, <domain_name>, :gql_mutation] — execution of a mutation. To break down measurements, use the resource_short_name and mutation (or action) metadata
[:ash, <domain_name>, :gql_query] — execution of a query. To break down measurements, use the resource_short_name and query (or action) metadata
[:ash, <domain_name>, :gql_relationship] — resolution of a relationship. To break down measurements, use the resource_short_name and relationship metadata
[:ash, <domain_name>, :gql_calculation] — resolution of a calculation. To break down measurements, use the resource_short_name and calculation metadata
[:ash, <domain_name>, :gql_relationship_batch] — batch resolution of relationships by the data loader. To break down measurements, use the resource_short_name and relationship metadata
[:ash, <domain_name>, :gql_calculation_batch] — batch resolution of calculations by the data loader. To break down measurements, use the resource_short_name and calculation metadata

Verdict

Honestly, I haven't reached for this kind of interaction often, but from the little experience I do have, I'll say one thing — it really is convenient.

ㅤ

😳 AshTypescript — the hidden gem

We've already gotten acquainted with AshJsonApi and AshGraphQL, and it was a useful experience. These two approaches are a kind of industry standard for web development, and they hold no special surprises for seasoned specialists. But Ash has a "trump card" — AshTypescript.

Imagine you want to interact with the frontend with gRPC-level type safety, while keeping an endpoint structure like AshJsonApi and the data-handling flexibility of AshGraphQL. That's exactly what AshTypescript solves.

How it works

Defining the structure. You describe your domain and resources, specifying the actions (actions) and attributes you need
Enabling the extensions. Add AshTypescript.Resource to the resource and AshTypescript.Rpc to the domain
Configuring the resource. In the typescript block inside the resource, set its name for generation

defmodule CourseHub.Courses.Lesson do
  use Ash.Resource,
    domain: CourseHub.Courses,
    extensions: [AshTypescript.Resource] # Enable the extension

  # Set the type name for the generated RPC file
  typescript do
    type_name "Lesson"
  end

  # Standard CRUD actions
  actions do
    defaults [:read, :create, :update, :destroy]
  end

  # Define the resource attributes
  attributes do
    uuid_primary_key :id
    attribute :title, :string, allow_nil?: false
    attribute :description, :string, default: "Some text!"
  end

  # Define the relationship with Course
  relationships do 
    belongs_to :course, CourseHub.Courses.Course
  end 
end

Binding RPC methods. In the domain module you define which methods will be available to the frontend and link them to the resource's actions.

defmodule CourseHub.Courses do
  use Ash.Domain, extensions: [AshTypescript.Rpc]

  # Public RPC methods for the frontend
  typescript_rpc do
    resource CourseHub.Courses.Lesson do
      rpc_action :list_lessons, :read
      rpc_action :create_lesson, :create
      rpc_action :get_lesson, :get
      rpc_action :delete_lesson, :destroy
      rpc_action :update_lesson, :update
    end
  end
end

Generating the code. By running mix ash_typescript.codegen (or the unified mix ash.codegen), you get the generated files at the path from your configuration. The settings live in config/config.exs:

config :ash_typescript,
  ash_domains: [
    Backend.CourseHub
  ],
  output_file: "assets/js/ash_rpc.ts", # Path for saving the generated code
  run_endpoint: "/rpc/run",            # Endpoint for sending requests
  validate_endpoint: "/rpc/validate",  # Endpoint for validating data against the schema
  input_field_formatter: :camel_case,  # Field-name format on input
  output_field_formatter: :camel_case, # Field-name format on output
  require_tenant_parameters: false,    # Multitenancy
  generate_zod_schemas: true,          # Generate Zod schemas
  generate_phx_channel_rpc_actions: false,
  generate_validation_functions: true,
  zod_import_path: "zod",
  zod_schema_suffix: "ZodSchema",
  phoenix_import_path: "phoenix"

Zod is a library for describing and validating the structure of data. It lets you create schemas and automatically validate incoming data against them.

Key advantages of Zod:

TypeScript-oriented — automatically infers types

An intuitive and easy-to-read API

Support for complex validation rules (unions, intersections, refinements)

High performance and a minimal footprint

Starting with newer versions, AshTypescript generates not a single monolithic file but several: besides ash_rpc.ts, you get shared types (ash_types.ts) and Zod schemas (ash_zod.ts), imported from a common place.

In the end, all that's left is to hand the generated files off to the frontend. Client developers simply call methods, e.g. listLessons(), without describing the API by hand. This makes integration incredibly simple and convenient.

Sorting, filtering, and field projection mechanisms

In standard backend development, you have to hand-construct SQL queries for sorting, filtering, and selection in order to avoid transferring excessive data. AshTypescript implements the same capabilities as AshJsonApi — flexibly and type-safely:

// CREATE
const createLessonResponse = await createLesson({
  fields: ["id", "title"],
  input: { title: "Elixir lesson about Ash", priority: "very high!" },
  headers
});

if (!createLessonResponse.success) {
  console.error("Create failed:", createLessonResponse.errors);
  return;
}

const lessonId = createLessonResponse.data.id;

// READ (single)
const getLesson = await getLesson({
  fields: ["id", "title", "description", { course: ["name"] }],
  input: { id: lessonId },
  headers
});

// READ (list)
const lessons = await listLessons({
  fields: ["id", "title"],
  headers
});

// UPDATE
const updateLessonResult = await updateLessson({
  fields: ["id", "title"],
  identity: lessonId,
  input: { title: "Yoo chill im just a vessel!" },
  headers
});

// DELETE
const deleteLessonResponse = await deleteLesson({
  identity: lessonId,
  headers
});

Advantages of using AshTypescript

Guaranteed contract integrity. No need to worry about interface drift, as can happen with "hand-rolled" gRPC. The single source of truth is the .ts-file generator
Automated API creation. No more manually writing methods or endpoints. It's enough to describe the resource and typescript_rpc in the domain and give the methods unique names
Minimized boilerplate. Built-in tools for sorting, filtering, and field selection (select/projections) make the work seamless
Easy integration with other teams. You can hand the generated files (ash_rpc.ts, ash_types.ts, ash_zod.ts) to colleagues — they can start working immediately without spending time studying the documentation

Impressions

When I learned about this way of organizing server–client interaction, I felt a renewed enthusiasm for programming. Hand-writing endpoints is monotonous, and describing schemas for GraphQL takes a lot of time. Declaratively describing actions on the backend and simply calling methods on the frontend, on the other hand, is fast and convenient. This approach removes up to 80% of the excess code and speeds up development manyfold.

ㅤ

🧮 Comparing the three approaches

All three approaches share one foundation — your actions. Only the "storefront" through which the logic faces the outside world changes. Hence the main takeaway: choosing an approach doesn't lock you into it forever — if needed, you can add a second contract on top of the same logic.

Criterion	AshJsonApi (REST / JSON:API)	AshGraphQL	AshTypescript
Contract type	REST per the JSON:API standard	GraphQL schema (SDL)	Generated `.ts` files (RPC)
Source of truth	your actions + OpenAPI autogen	your actions + SDL autogen	your actions + TypeScript autogen
How the client specifies a request	query parameters (`filter`, `sort`, `include`)	a GraphQL query with a field tree	typed calls (`fields`, `filter`, `sort`)
Selection flexibility	high	maximal	high
Industry standard	yes, ubiquitous	yes, but niche	no, specific to the Ash + TS stack
Type safety on the frontend	via codegen from OpenAPI	via codegen from the schema	native, out of the box
Real-time	not out of the box	yes (subscriptions)	yes (Phoenix channels)
HTTP caching	works (GET)	difficult (POST)	depends on the implementation
Entry barrier on the frontend	low	medium/high	low (for TypeScript teams)
Ideal for	public and external APIs	many diverse clients with complex queries	full-stack Elixir + TypeScript

How to choose in practice:

AshJsonApi — when you need familiar REST, a public or external API, caching at the HTTP level, and maximum compatibility with any client. The most "neutral" choice
AshGraphQL — when there are many clients with different, often nested data requirements, and under-/over-fetching (over/under-fetching) is a real hindrance. Be prepared to pay for it with batching against N+1, query-complexity limiting, and a client-side cache
AshTypescript — when both the backend and the frontend are yours, and the frontend is in TypeScript. It gives you end-to-end type safety without a hand-written contract: rename a field in Elixir and you immediately get a compile error in TS

If you're unsure and the client is single and relatively simple — start with AshJsonApi. If you later need GraphQL or type-safe RPC, you'll simply add another contract on top of the same actions without rewriting the logic.

ㅤ

😴 Conclusion

The world of Ash gives you not just a convenient way of working with the database and freedom from boilerplate — it lets you build applications quickly, with quality, and with enjoyment. Fully mastering these methods will take a little more time, but it will pay off more than once and will genuinely help you in your projects. Good luck!

ㅤ

🥴 From the author

Thank you so much for your interest in this article! I hope it helped you understand what AshJsonApi, AshGraphQL, and AshTypescript are and why they're used!

If you enjoyed this article and want more material like it, join me on my Bsky!

Ash Framework: способы взаимодействия — AshJsonApi, AshGraphQL и AshTypescript

Artyom Molchanov — Fri, 03 Jul 2026 07:50:45 +0000

Разработка стабильного продукта, способного держать высокие нагрузки на разных серверах, — задача сложная и ресурсозатратная. Программист не может сфокусироваться только на бизнес-логике: сначала нужно настроить базу данных, спроектировать серверные API и многое другое.

Сложность многократно возрастает при работе в одиночку. Приходится самому реализовывать интерфейс на выбранном фреймворке, обеспечивать совместимость слоёв, собирать проект в образы Docker и разворачивать его в Kubernetes. Добавьте сюда настройку маршрутизации через Nginx и проектирование системы по принципам чистой архитектуры — и получится крайне трудоёмкий процесс.

Поэтому во многих языках активно внедряют инструменты для автоматизации рутины (бойлерплейта), позволяя сосредоточиться на уникальном коде. Например, в Go есть библиотека oapi-codegen: вы описываете контракт в формате Swagger, а по нему автоматически генерируется код сервера. Такой формат упрощает интеграцию фронтенда и бэкенда и делает изменения логики менее болезненными — достаточно обновить описание в Swagger-файле и перегенерировать сервис.

Подобные подходы к систематизации повторяющихся задач появляются повсеместно. Главная цель — сделать интеграцию предсказуемой и исключить ситуацию, когда разработчику приходится десятки раз переписывать и тестировать одно и то же ради идеальной совместимости. И в этой сфере есть свой лидер — Ash!

ㅤ

🙏 Благодарности

Хочу выразить глубокую признательность Заку Даниэлю и всем, кто отреагировал на мою предыдущую статью об Ash (Ash Framework: Знакомство) и поделился ею. Ваша поддержка дала огромный заряд энергии и мотивации и подтвердила, что сообщество Ash — потрясающее!

ㅤ

📖 Предисловие

В этом материале намеренно не будет практическое руководство в полном объёме по указанным темам, так как полагаемся на вашу любознательность. Несмотря на желание охватить всё, я не смогу в одной статье описать всю практическую сторону данных фреймворков и научить вас всему и сразу. Вместо этого я поделюсь с вами информацией и задам направление для размышлений, что и является основной целью данной публикации. Для более глубокого погружения в работу этих библиотек я рекомендую вам начать создавать на их основе собственные проекты — именно такой подход когда-то помог мне лучше всего разобраться в их устройстве. Помните, что главным наставником для вас станет практика, поэтому успехов в её освоении!

Важно: цель статьи — вовсе не уговорить вас использовать Ash повсеместно и постоянно!

ㅤ

🧐 Что предлагает экосистема Ash

Если вы знакомы с Elixir и Phoenix, то знаете, что фреймворк уже содержит встроенные механизмы для упрощения разработки. Один из них — LiveView. Он позволяет отказаться от классического разделения на API-бэкенд и отдельный JavaScript-фронтенд: интерфейс пишется прямо внутри приложения. Это ускоряет разработку и удобно бэкенд-программистам, работающим без фронтенд-команды. Для простых и средних проектов путь с LiveView отлично подходит, но при создании масштабных систем код рискует превратиться в «спагетти», где трудно отслеживать зависимости между компонентами и находить обработчики вроде def handle_params/3.

А как быть, если нужен качественный обособленный фронтенд, но вы устали каждый раз заново писать шаблонный REST-интерфейс и настраивать связь? Ответ — освоить возможности Ash. О них и поговорим.

ㅤ

😮 REST с AshJsonApi: новый подход

Стандартная практика подразумевает фиксацию контракта между фронтендом и бэкендом не только на словах, но и документально — обычно через Swagger. В нём описывают структуры данных и методы API, после чего документация передаётся команде интерфейса. Любые изменения требуют осторожности, чтобы не сломать совместимость. Даже базовая настройка такого подхода стоит немалых усилий: нужно интегрировать библиотеку генерации, создать конфигурации по спецификации OpenAPI (Swagger) и вручную описать конечные точки (endpoints). Если речь о переписывании существующего проекта, процесс легко занимает больше рабочего дня.

AshJsonApi предлагает альтернативу. Главное преимущество — вам больше не нужно предварительно писать спецификацию в YAML/JSON и генерировать из неё код. Для старта достаточно готового домена ресурсов и подключённого расширения AshJsonApi.

Создать новый проект с поддержкой этого инструмента можно прямо на главной странице портала Ash через конструктор. Если проект на Ash уже есть, добавить функциональность можно одной командой:

mix igniter.install ash_json_api

В процессе установки система задаёт уточняющие вопросы (Y/N). Можно соглашаться со всеми предложениями или изучить каждый пункт и решить самостоятельно. После установки останется выполнить несколько простых шагов.

Настройка ресурса для работы с JSON:API

Чтобы ресурсы стали доступны через API, подключите расширение AshJsonApi.Resource. Это позволит автоматически сгенерировать эндпоинты на основе определений домена. Добавьте AshJsonApi.Resource в список extensions и задайте имя ресурса в параметре type:

defmodule CourseHub.Courses.Lesson do
  use Ash.Resource, extensions: [AshJsonApi.Resource]

  # Активация генерации эндпоинтов
  json_api do
    type "lesson"
  end

  actions do
    defaults [:read, :create, :destroy, :update]

    action :list_lessons_allowed, :map do
      run fn _input, _ctx ->
        allowed_courses = %{"go" => "Golang", "elixir" => "Elixir", "rust" => "Rust"}
        {:ok, allowed_courses}
      end
    end
  end
end

Параметр type определяет имя ресурса в пространстве имён JSON:API. Он используется преимущественно для документации (например, в Swagger или Redoc) и позволяет группировать методы по тегам.

Далее опишите маршруты в домене, указав пути и связав их с конкретными действиями ресурса:

defmodule CourseHub.Courses do
  use Ash.Domain, extensions: [AshJsonApi.Domain]

  json_api do
    routes do
      base_route "/lessons", CourseHub.Courses.Lesson do
        index :read, description: "Получение списка лекций"
        get :read, primary?: true, description: "Получение одной лекции"
        post :create, description: "Создание лекции"
        patch :update, description: "Изменение лекции"
        delete :destroy, description: "Удаление лекции"

        # Путь относителен base_route, итоговый эндпоинт: /lessons/allowed
        route :get, "/allowed", :list_lessons_allowed,
          description: "Получение списка разрешённых лекций"
      end
    end
  end
end

Выполнив эти шаги, вы получите шесть полностью функциональных эндпоинтов. Вся логика теперь связана с вашими actions внутри доменной модели. Отдельные Swagger-файлы или ручное определение маршрутов не нужны: изменение логики action в коде автоматически отражается на поведении соответствующего API-эндпоинта.

Ключевые достоинства AshJsonApi

Единый подход и предсказуемость

Основное преимущество — строгая согласованность приложения. При переходе на другой тип контракта (например, GraphQL) не придётся переписывать бизнес-логику. Поскольку AshJsonApi работает поверх ваших actions, вы застрахованы от ситуации, когда изменения в коде не отразились в одном из интерфейсов: вся логика инкапсулирована в action, который вы «раздаёте» разным контрактам. Это заметно ускоряет разработку — по личным оценкам, готовый продукт получается примерно в пять раз быстрее. Для автоматизации можно воспользоваться командой:

mix ash.patch.extend CourseHub.Courses.Lesson json_api

Указав адрес ресурса, вы позволите AshJsonApi автоматически сгенерировать всю обвязку для работы с API.

Работа с данными: фильтрация, сортировка и связи

Как бэкенд-разработчик, я раньше тратил много времени на рутинную реализацию фильтров и сортировок, вручную составляя SQL с LIMIT, OFFSET и WHERE. AshJsonApi избавляет от этого: фильтрация и упорядочивание выполняются автоматически. Фронтенду достаточно указать нужные поля и условия прямо в запросе. Это кардинально упрощает взаимодействие команд: фронтенд формирует запросы к данным самостоятельно, не отвлекая бэкенд. При этом все вычисления происходят на сервере, поэтому клиент не несёт лишней нагрузки — он лишь описывает желаемую схему данных. Полный список параметров есть в официальной документации. Пример запроса:

GET /courses/1?include=lessons&included_page[lessons][limit]=10&included_page[lessons][offset]=20

Запрос возвращает информацию о курсе и подгружает связанные лекции с заданной пагинацией. Ответ приходит в формате application/vnd.api+json — это стандартизированная спецификация (подробнее на jsonapi.org), которая структурирует JSON для предсказуемой работы.

Пример ответа:

{
  "data": {
    "id": "1",
    "type": "course",
    "attributes": {
      "title": "My Course!"
    },
    "relationships": {
      "lessons": {
        "data": [
          {"id": "1", "type": "lessons"},
          {"id": "2", "type": "lessons"}
        ],
        "links": {
          "self": "/courses/1/relationships/lessons",
          "related": "/courses/1/lessons",
          "first": "/courses/1?include=lessons&included_page[lessons][limit]=10",
          "next": "/courses/1?include=lessons&included_page[lessons][limit]=10&included_page[lessons][offset]=10",
          "prev": null,
          "last": "/courses/1?include=lessons&included_page[lessons][limit]=10&included_page[lessons][offset]=40"
        },
        "meta": {
          "limit": 10,
          "offset": 0,
          "count": 50
        }
      }
    }
  },
  "included": [
    {
      "id": "1",
      "type": "lessons",
      "attributes": {
        "description": "Lessons about Elixir 1!"
      }
    },
    {
      "id": "2",
      "type": "lessons",
      "attributes": {
        "description": "Lessons about Elixir 2!"
      }
    }
  ]
}

Заключение и личный опыт

Подводя итог, поделюсь опытом. На текущем проекте создание REST-эндпоинтов заняло всего 20–30 минут. Основное время ушло на кастомизацию отображения документации в Redoc — вот это оказалось довольно трудоёмким (в отличие от генерации самого API). Если решите использовать Redoc, будьте готовы вручную переписывать его блоки ради красивого вывода ответов и примеров.

В остальном инструмент показал себя отлично: великолепная гибкость, кастомизируемая обработка ошибок, тонкое управление доступом к эндпоинтам. Если цель — построить удобный и мощный REST API, AshJsonApi отличный выбор.

ㅤ

🙂‍↕️ AshGraphQL

С этой библиотекой возможны сложности: не так много людей вообще работали с GraphQL. Поэтому сначала дам вводную — освежить память или узнать, что это такое, — а потом посмотрим саму библиотеку.

Что такое GraphQL

GraphQL — это язык запросов для API и рантайм для их исполнения. Клиент сам описывает, какие данные ему нужны, а сервер возвращает ровно эту форму. Контрактом служит строго типизированная схема.

Фундаментальные принципы

Взаимодействие идёт через единый endpoint (обычно POST /graphql). Логика строится вокруг графа типов. Запрос имеет иерархическую структуру, и ответ сервера в точности её повторяет. Это решает проблемы over-fetching и under-fetching.

Виды операций

Query — операции на чтение (идемпотентны).
Mutation — операции на изменение данных (выполняются последовательно).
Subscription — подписка на поток событий в реальном времени (через WebSocket).

Схема и резолверы

Центральный элемент — схема, описываемая на SDL. Она служит источником истины и позволяет проводить интроспекцию. Каждое поле сопоставляется с резолвером — функцией, возвращающей значение. Сервер обходит дерево запроса и вызывает резолверы для каждого поля.

Сложности

Проблема N+1. Резолверы работают независимо, и без оптимизации (батчинга) это приводит к множеству запросов к базе
Кэширование. Стандартные HTTP-механизмы (CDN, ETag) не работают, так как всё идёт через POST. Требуется нормализованный кэш на клиенте
Безопасность. Клиент может отправить глубоко вложенный запрос, перегружающий базу. Нужны ограничение глубины и анализ сложности
Ошибки. Сервер почти всегда возвращает статус 200, а сами ошибки помещаются в массив errors рядом с частичными данными. Это ломает мониторинг, основанный на кодах состояния HTTP
Инфраструктура. Загрузка файлов, rate limiting и наблюдаемость требуют отдельного инфраструктурного слоя

Где эффективен

Технология оправдывает себя при множестве разнообразных клиентов со сложными требованиями к данным. Для одного клиента с простыми ресурсами проще взять REST. Для внутреннего межсервисного взаимодействия с жёсткими контрактами и минимальной задержкой лучше подходит gRPC.

Что представляет собой AshGraphQL

Несмотря на то что GraphQL пока уступает в популярности другим подходам, его интеграция с Ash сделана очень качественно. Технологию легко внедрить в проекты на базе Ash.

Для начала добавьте библиотеку в проект:

mix igniter.install ash_graphql

Затем в модуле схемы укажите используемые домены:

use AshGraphql, domains: [Your.Domain1, Your.Domain2]

Настройка ресурсов и доменов

Чтобы ресурс стал доступен через GraphQL, подключите расширение AshGraphql.Resource и опишите базовый блок конфигурации:

defmodule CourseHub.Courses.Lesson do
  use Ash.Resource,
    extensions: [
      AshGraphql.Resource
    ]

  graphql do
    type :lesson
  end

  # ... остальная логика ресурса
end

В модуле домена определите операции (ручки) через расширение AshGraphql.Domain:

defmodule CourseHub.Courses do
  use Ash.Domain,
    extensions: [
      AshGraphql.Domain
    ]

  graphql do
    queries do
      get CourseHub.Courses.Lesson, :get_lesson, :read
      read_one CourseHub.Courses.Lesson, :most_popular_lesson, :most_popular
      list CourseHub.Courses.Lesson, :list_lessons, :read
    end

    mutations do
      create CourseHub.Courses.Lesson, :create_lesson, :create
      update CourseHub.Courses.Lesson, :update_lesson, :update
      destroy CourseHub.Courses.Lesson, :destroy_lesson, :destroy
    end
  end
end

Описывать эти ручки можно не только в модуле домена, но и прямо внутри ресурса.

Кроме того, вы можете создавать собственные действия для кастомных ответов. Пример:

graphql do
  type :lesson

  queries do
    action :random_lesson, :random_lesson
  end
end

actions do
  action :random_lesson, {:array, :struct} do
    constraints items: [instance_of: __MODULE__]

    run fn _input, _context ->
      # возвращаем список структур, как объявлено в типе действия
      Ash.read(__MODULE__)
    end
  end
end

Генерация схемы SDL

Как и в AshJsonApi (где Swagger генерируется автоматически после правок), схема GraphQL обновляется схожим образом. Пропишите путь для сохранения в use AshGraphql через generate_sdl_file:. Файл будет автоматически генерироваться при каждом запуске mix ash.codegen (если включён auto_generate_sdl_file?: true):

use AshGraphql,
  domains: [Domain1, Domain2],
  generate_sdl_file: "priv/schema.graphql",
  auto_generate_sdl_file?: true

Создание подписок (Subscriptions)

Можно настроить получение данных в реальном времени через механизм подписок. Для этого используется конфигурация Absinthe:

# в файле схемы Absinthe
subscription do
  field :field, :type_name do
    config(fn
      _args, %{context: %{current_user: %{id: user_id}}} ->
        {:ok, topic: user_id, context_id: "user/#{user_id}"}

      _args, _context ->
        {:error, :unauthorized}
    end)

    resolve(fn args, _, resolution ->
      AshGraphql.Subscription.query_for_subscription(
        YourResource,
        YourDomain,
        resolution
      )
      |> Ash.Query.filter(id == ^args.id)
      |> Ash.read(actor: resolution.context.current_user)
    end)
  end
end

Мониторинг

Для глубокого погружения рекомендую официальное руководство по мониторингу Ash. Здесь кратко опишем механизмы трассировки и события телеметрии, которые становятся доступны с этим расширением.

Можно определить собственный трассировщик на уровне домена — его настройки будут иметь приоритет над глобальным параметром config :ash, :tracer:

graphql do
  tracer MyApp.Tracer
end

Трассировка (Traces)

Операции резолверов GraphQL и базовых пакетных загрузчиков данных оборачиваются в диапазоны (spans) с соответствующими именами. Для удобства к ним добавляется метаданное source: :graphql, что позволяет фильтровать или комментировать эти данные в системе мониторинга.

Телеметрия (Telemetry)

Модуль AshGraphql публикует события телеметрии, каждое из которых сопровождается суффиксами :start и :stop. События начала (:start) содержат измерение system_time, а события завершения (:stop) — system_time и длительность выполнения duration. Все временные показатели представлены в нативных единицах времени.

Список генерируемых событий:

[:ash, <имя_домена>, :gql_mutation] — выполнение мутации. Для детализации используйте метаданные resource_short_name и mutation (или action)
[:ash, <имя_домена>, :gql_query] — выполнение запроса. Для детализации используйте метаданные resource_short_name и query (или action)
[:ash, <имя_домена>, :gql_relationship] — разрешение связи. Для детализации используйте метаданные resource_short_name и relationship
[:ash, <имя_домена>, :gql_calculation] — разрешение вычисления. Для детализации используйте метаданные resource_short_name и calculation
[:ash, <имя_домена>, :gql_relationship_batch] — пакетное разрешение связей загрузчиком данных. Для детализации используйте метаданные resource_short_name и relationship
[:ash, <имя_домена>, :gql_calculation_batch] — пакетное разрешение вычислений загрузчиком данных. Для детализации используйте метаданные resource_short_name и calculation

Отзыв

Честно говоря, я нечасто прибегал к такому формату взаимодействия, но из того немногого опыта, что у меня есть, скажу одно — это действительно удобно.

ㅤ

😳 AshTypescript — скрытая жемчужина

Мы уже познакомились с AshJsonApi и AshGraphQL, и это был полезный опыт. Эти два подхода — своего рода индустриальный стандарт веб-разработки, и особых сюрпризов для опытных специалистов в них нет. Но у Ash есть «козырная карта» — AshTypescript.

Представьте, что вы хотите взаимодействовать с фронтендом с типобезопасностью уровня gRPC, сохраняя структуру эндпоинтов как в AshJsonApi и гибкость работы с данными как в AshGraphQL. Именно это и решает AshTypescript.

Принцип работы

Определение структуры. Вы описываете домен и ресурсы, указывая нужные действия (actions) и атрибуты
Подключение расширений. В ресурс добавляется AshTypescript.Resource, а в домен — AshTypescript.Rpc
Настройка ресурса. В блоке typescript внутри ресурса задаётся его имя для генерации

defmodule CourseHub.Courses.Lesson do
  use Ash.Resource,
    domain: CourseHub.Courses,
    extensions: [AshTypescript.Resource] # Подключаем расширение

  # Задаём имя типа для сгенерированного RPC-файла
  typescript do
    type_name "Lesson"
  end

  # Стандартные CRUD-действия
  actions do
    defaults [:read, :create, :update, :destroy]
  end

  # Описываем атрибуты ресурса
  attributes do
    uuid_primary_key :id
    attribute :title, :string, allow_nil?: false
    attribute :description, :string, default: "Какой-то текст!"
  end

  # Описываем связь с Course
  relationships do 
    belongs_to :course, CourseHub.Courses.Course
  end 
end

Привязка RPC-методов. В модуле домена вы определяете, какие методы будут доступны фронтенду, и связываете их с действиями ресурса.

defmodule CourseHub.Courses do
  use Ash.Domain, extensions: [AshTypescript.Rpc]

  # Публичные RPC-методы для фронтенда
  typescript_rpc do
    resource CourseHub.Courses.Lesson do
      rpc_action :list_lessons, :read
      rpc_action :create_lesson, :create
      rpc_action :get_lesson, :get
      rpc_action :delete_lesson, :destroy
      rpc_action :update_lesson, :update
    end
  end
end

Генерация кода. Запустив mix ash_typescript.codegen (или общую mix ash.codegen), вы получите сгенерированные файлы по пути из конфигурации. Настройки лежат в config/config.exs:

config :ash_typescript,
  ash_domains: [
    Backend.CourseHub
  ],
  output_file: "assets/js/ash_rpc.ts", # Путь для сохранения сгенерированного кода
  run_endpoint: "/rpc/run",            # Эндпоинт для отправки запросов
  validate_endpoint: "/rpc/validate",  # Эндпоинт для валидации данных по схеме
  input_field_formatter: :camel_case,  # Формат имён полей на входе
  output_field_formatter: :camel_case, # Формат имён полей на выходе
  require_tenant_parameters: false,    # Мультитенантность
  generate_zod_schemas: true,          # Генерация схем для Zod
  generate_phx_channel_rpc_actions: false,
  generate_validation_functions: true,
  zod_import_path: "zod",
  zod_schema_suffix: "ZodSchema",
  phoenix_import_path: "phoenix"

Zod — библиотека для описания и проверки структуры данных. Она позволяет создавать схемы и автоматически валидировать по ним входящие данные.

Ключевые преимущества Zod:

Ориентированность на TypeScript — автоматически выводит типы

Интуитивно понятный и легко читаемый API

Поддержка сложных правил валидации (объединения типов, пересечения, уточнения)

Высокая производительность и минимальный вес

Начиная с новых версий, AshTypescript генерирует не один монолитный файл, а несколько: помимо ash_rpc.ts появляются общие типы (ash_types.ts) и схемы Zod (ash_zod.ts), которые импортируются из общего места.

В итоге вам остаётся лишь передать сгенерированные файлы на фронтенд. Разработчики клиента просто вызывают методы, например listLessons(), без ручного описания API. Это делает интеграцию невероятно простой и удобной.

Механизмы сортировки, фильтрации и проекции полей

В стандартной серверной разработке приходится вручную конструировать SQL-запросы для сортировки, фильтрации и выборки, чтобы избежать избыточной передачи данных. В AshTypescript реализованы те же возможности, что и в AshJsonApi, — гибко и типобезопасно:

// CREATE
const createLessonResponse = await createLesson({
  fields: ["id", "title"],
  input: { title: "Elixir lesson about Ash", priority: "very high!" },
  headers
});

if (!createLessonResponse.success) {
  console.error("Create failed:", createLessonResponse.errors);
  return;
}

const lessonId = createLessonResponse.data.id;

// READ (single)
const getLesson = await getLesson({
  fields: ["id", "title", "description", { course: ["name"] }],
  input: { id: lessonId },
  headers
});

// READ (list)
const lessons = await listLessons({
  fields: ["id", "title"],
  headers
});

// UPDATE
const updateLessonResult = await updateLessson({
  fields: ["id", "title"],
  identity: lessonId,
  input: { title: "Yoo chill im just a vessel!" },
  headers
});

// DELETE
const deleteLessonResponse = await deleteLesson({
  identity: lessonId,
  headers
});

Преимущества использования AshTypescript

Гарантия целостности контракта. Не нужно беспокоиться о рассинхроне интерфейса, как это бывает с «ручным» gRPC. Единственный источник истины — генератор .ts-файлов
Автоматизация создания API. Отпадает ручное написание методов и эндпоинтов. Достаточно описать ресурс и typescript_rpc в домене и дать методам уникальные имена
Минимизация шаблонного кода. Встроенные инструменты для сортировки, фильтрации и выборки полей (select/проекции) делают работу бесшовной
Простая интеграция с другими командами. Сгенерированные файлы (ash_rpc.ts, ash_types.ts, ash_zod.ts) можно передать коллегам — они начнут работу немедленно, не тратя время на изучение документации

Впечатления

Узнав об этом способе организации взаимодействия между сервером и клиентом, я вновь испытал энтузиазм к программированию. Ручное написание эндпоинтов монотонно, а описание схем для GraphQL отнимает много времени. Декларативное же описание actions на бэкенде и простой вызов методов на фронтенде — это быстро и удобно. Такой подход убирает до 80% лишнего кода и многократно ускоряет разработку.

ㅤ

🧮 Сравнение трёх подходов

У всех трёх способов один фундамент — ваши actions. Меняется только «витрина», через которую логика выходит наружу. Отсюда и главный вывод: выбор способа не запирает вас в нём навсегда — при необходимости можно добавить второй контракт поверх той же логики.

Критерий	AshJsonApi (REST / JSON:API)	AshGraphQL	AshTypescript
Тип контракта	REST по стандарту JSON:API	GraphQL-схема (SDL)	Сгенерированные `.ts`-файлы (RPC)
Источник истины	ваши actions + автоген OpenAPI	ваши actions + автоген SDL	ваши actions + автоген TypeScript
Как клиент задаёт запрос	query-параметры (`filter`, `sort`, `include`)	GraphQL-запрос с деревом полей	типизированные вызовы (`fields`, `filter`, `sort`)
Гибкость выборки	высокая	максимальная	высокая
Индустриальный стандарт	да, повсеместно	да, но нишевый	нет, специфичен для стека Ash + TS
Типобезопасность на фронте	через кодоген из OpenAPI	через кодоген из схемы	нативная, из коробки
Реалтайм	нет из коробки	да (subscriptions)	да (Phoenix channels)
HTTP-кэширование	работает (GET)	затруднено (POST)	зависит от реализации
Порог входа на фронте	низкий	средний/высокий	низкий (для TypeScript-команд)
Идеально для	публичные и внешние API	много разных клиентов со сложными запросами	full-stack Elixir + TypeScript

Как выбирать на практике:

AshJsonApi — когда нужен привычный REST, публичный или внешний API, кэширование на уровне HTTP и максимальная совместимость с любыми клиентами. Самый «нейтральный» выбор
AshGraphQL — когда клиентов много и у них разные, часто вложенные требования к данным, а под-/пере-выборка (over/under-fetching) реально мешает. Готовьтесь платить за это батчингом против N+1, ограничением сложности запросов и клиентским кэшем
AshTypescript — когда и бэкенд, и фронтенд ваши, и фронтенд на TypeScript. Даёт сквозную типобезопасность без ручного контракта: переименовали поле в Elixir — сразу получили ошибку компиляции в TS

Если сомневаетесь и клиент один и относительно простой — начните с AshJsonApi. Если позже понадобится GraphQL или типобезопасный RPC, вы просто добавите ещё один контракт поверх тех же actions, не переписывая логику.

ㅤ

😴 Заключение

Мир Ash даёт не просто удобный формат работы с БД и отсутствие бойлерплейта — он позволяет делать приложения быстро, качественно и с удовольствием. На полное освоение этих методов уйдёт чуть больше времени, но оно окупится не раз и здорово поможет в ваших проектах. Успехов!

ㅤ

🥴 От автора

Спасибо большое за интерес к этой статье! Надеюсь, она помогла разобраться, что представляет собой AshJsonApi, AshGraphQL, AshTypescript и зачем они используются!

Если эта статья пришлась вам по душе и хочется ещё материалов такого плана, присоединяйтесь ко мне в моём телеграм-канале, где выкладываю обзоры книг, публикации по Elixir, переводы технической литературы и интересные новости!

[Boost]

Artyom Molchanov — Tue, 09 Jun 2026 13:27:15 +0000

Alexey Bolshakov

Jun 9

Forth made neural networks suffer

#ai #programming #forth #toolchain

18 min read

[Boost]

Artyom Molchanov — Tue, 09 Jun 2026 09:05:14 +0000

Alexey Bolshakov

Jun 9

Forth заставил страдать нейросети

#ai #programming #forth #toochain

4 min read

[Boost]

Artyom Molchanov — Tue, 19 May 2026 09:17:52 +0000

Alexey Bolshakov

May 18

FMix: пакетный менеджер для Forth

#forth #opensource #tooling #ai

3 min read

Ash Framework: Introduction

Artyom Molchanov — Sat, 04 Apr 2026 08:18:54 +0000

When a newcomer starts with Elixir and Phoenix, they are almost always introduced to Ecto first. You create schemas, write changesets, and move queries into contexts. This approach is flexible, but as the project grows, a serious problem begins to emerge 😟

Business logic starts to spread across dozens of files. Eventually, confusion arises about where to place request handling code and how to make sense of the existing mess. After a year or two, it becomes difficult to understand where the “right” place for code is, and new developers spend weeks just getting up to speed with the project.

Ash Framework was created precisely to solve this pain 💪

Important clarification: Ash is not a replacement for Phoenix and not a new web framework. It is a powerful declarative layer that organizes business logic and data on top of the existing ecosystem.

ㅤ

📖 Preface

It’s important to understand that the goal of this article is not to convince you to use Ash everywhere and all the time!

Personally, I love Ash because it allows you to gather all necessary logic in a single space, where it belongs. This tool significantly simplifies work, reducing boilerplate code and freeing you from the tedious implementation of standard CRUD.

If you’re ready to get acquainted with such a tool but plan to use it only when truly justified—read on without hesitation. Ash is not a universal cure-all, but rather a convenient set of useful tools.

ㅤ

🚀 What is Ash?

Ash is a framework for fast and efficient application development in Elixir. Its goal is to simplify launching new projects and make maintaining existing solutions convenient, ensuring excellent performance and stability even after long periods of active development.

The key idea of Ash is:

Precisely define the structure of your business logic, and let Ash handle all the rest (database migrations, API interface creation, data validation, access control, form generation).

The framework integrates beautifully with popular tools like Phoenix, PostgreSQL, GraphQL, and LiveView.

ㅤ

🔑 Key Abstractions in Ash

Everything in Ash is built around three main concepts:

Resource — description of a single business entity
Action — an operation that can be performed on a resource
Domain — logical grouping of resources within one business area

Let’s break down each concept in detail!

ㅤ

🧩 What is a Resource?

Resource is one module where a single business entity of your application (User, Lesson, Order, Post, Payment, etc.) is fully described.

Everything related to this entity is collected in one place:

Data structure (fields)
Relationships with other entities
Operations that can be performed (CRUD + custom)
Validation rules
Authorization (who can do what)
Computed fields
Indexes and constraints
Storage settings in the database

A Resource in Ash unifies in one module what in classic Elixir/Phoenix is usually spread across several parts: Ecto Schema, Changesets, Context functions, as well as authorization logic and computed fields.

ㅤ

Resource — The Heart of Ash

Ash is built around the idea of Resource-Oriented Design. You describe what an entity is and what can be done with it—and Ash generates the rest: SQL queries, APIs, forms, migrations, validation, etc.

ㅤ

Complete Example of a Modern Resource

defmodule CourseHub.Courses.Lesson do
  use Ash.Resource,
    otp_app: :course_hub,
    domain: CourseHub.Courses,
    data_layer: AshPostgres.DataLayer

  # ==================== STORAGE ====================
  postgres do
    table "lessons"
    repo CourseHub.Repo
  end

  # ==================== FIELDS (Attributes) ====================
  attributes do
    uuid_primary_key :id

    attribute :title, :string do
      public? true
      allow_nil? false
      constraints min_length: 3, max_length: 200
    end

    attribute :description, :string, public?: true
    attribute :content, :string, public?: true

    attribute :status, :atom do
      public? true
      default? :draft
      constraints one_of: [:draft, :published, :archived]
    end

    create_timestamp :inserted_at
    update_timestamp :updated_at
  end

  # ==================== RELATIONSHIPS ====================
  relationships do
    belongs_to :author, CourseHub.Accounts.User do
      public? true
      allow_nil? false
    end

    has_many :comments, CourseHub.Courses.Comment do
      public? true
    end

    many_to_many :tags, CourseHub.Courses.Tag do
      public? true
      through CourseHub.Courses.LessonTag
      source_attribute_on_join_resource :lesson_id
      destination_attribute_on_join_resource :tag_id
    end
  end

  # ==================== ACTIONS ====================
  actions do
    defaults [:create, :read, :update, :destroy]

    # Custom read
    read :published do
      filter expr(status == :published)
      pagination offset?: true, countable: true
      prepare build(sort: [inserted_at: :desc])
    end

    # Custom create with logic
    create :publish do
      argument :reason, :string
      change set_attribute(:status, :published)
    end

    # Fully custom action
    action :calculate_reading_time, :integer do
      argument :content, :string, allow_nil?: false
      run fn input, _context ->
        minutes = String.length(input.arguments.content) |> div(500) |> max(1)
        {:ok, minutes}
      end
    end
  end

  # ==================== COMPUTED FIELDS ====================
  calculations do
    calculate :reading_time_minutes, :integer do
      calculation fn records, _context ->
        Enum.map(records, fn lesson ->
          (String.length(lesson.content || "") / 500) |> Float.ceil() |> trunc()
        end)
      end
    end
  end

  # ==================== INDEXES ====================
  identities do
    identity :unique_title_per_author, [:title, :author_id]
  end

  # ==================== AUTHORIZATION ====================
  policies do
    policy action_type(:read) do
      authorize_if always()
    end

    policy action(:update) do
      authorize_if expr(author_id == ^actor(:id))
    end
  end
end

ㅤ

Main Sections of Resource

Section	Describes	Analog in Classic Elixir/Phoenix
`attributes`	Fields and their types + validation	Ecto Schema + fields
`relationships`	Relationships with other resources	Ecto associations
`actions`	All possible operations (CRUD + custom)	Context functions + Changesets
`calculations`	Computed fields (on the fly)	Virtual fields / functions
`aggregates`	Aggregates (count, sum, avg, etc.)	Queries with group_by
`identities`	Unique indexes	Ecto unique constraints
`policies`	Authorization rules	Manual permission checks
`postgres`	PostgreSQL storage settings	Migrations

ㅤ

Key Features of Resource

Everything in one file — a huge plus for understanding the entity.
Introspection — Ash can read all information about a resource at runtime (fields, actions, policies). This is used for API generation, forms, admin panels.
Declarativeness — you describe what should be there, not how to implement it.
Extensibility — you can add your own changes, preparations, validations, notifiers.
Embedded Resources — you can create resources stored not in a separate table but as JSON/Map within another resource.

ㅤ

When to Create a New Resource?

Almost always when a new business entity appears (a table or even a complex JSON object).

ㅤ

🛠️ More About Actions

Action is an explicitly declared operation that can be performed on a resource.
All data interaction in Ash goes only through Actions. You cannot simply take a record and change it manually—you always call an action.

This replaces:

Regular functions in Phoenix Contexts
Changesets in Ecto
Controllers and service layers

ㅤ

Five Types of Actions

	Action Type	What It Does?	In Transaction?	Returns?
✨	`create`	Creates a new record	Yes	New resource record
🔍	`read`	Reads one record or a list	No (can be enabled)	Record or list of records
✏️	`update`	Updates an existing record	Yes	Updated record
🗑️	`destroy`	Deletes a record	Yes	Deleted record
⚡	`action` (Generic)	Any custom business logic	No (can be enabled)	Any value

ㅤ

Complete Example of All Action Types

defmodule CourseHub.Courses.Lesson do
  use Ash.Resource, ...

  actions do
    # 1. Standard CRUD (defaults)
    defaults [:create, :read, :update, :destroy]

    # 2. Custom Read
    read :published do
      filter expr(status == :published)
      pagination offset?: true, countable: true, default_limit: 20
      prepare build(sort: [inserted_at: :desc], load: [:author, :comment_count])
    end

    read :for_user do
      argument :user_id, :uuid, allow_nil?: false
      filter expr(author_id == ^arg(:user_id))
    end

    # 3. Custom Create
    create :publish do
      argument :reason, :string, allow_nil?: true

      # Changes (changes)
      change set_attribute(:status, :published)
      change set_attribute(:published_at, &DateTime.utc_now/0)
      change {CourseHub.Changes.NotifySubscribers, topic: "new_lessons"}

      # Hooks
      after_action fn _changeset, lesson, _context ->
        {:ok, lesson}
      end
    end

    # 4. Custom Update
    update :archive do
      accept [:archive_reason]
      change set_attribute(:status, :archived)
      change set_attribute(:archived_at, &DateTime.utc_now/0)
    end

    # 5. Generic Action (fully custom)
    action :calculate_reading_time, :integer do
      argument :content, :string, allow_nil?: false
      argument :words_per_minute, :integer, default?: 200

      run fn input, _context ->
        minutes = String.length(input.arguments.content) 
                  |> div(input.arguments.words_per_minute) 
                  |> max(1)
        {:ok, minutes}
      end
    end
  end
end

ㅤ

How to Call Actions

# Through Domain (recommended way)
CourseHub.Courses.publish!(lesson, %{reason: "Готово"})
CourseHub.Courses.read!(CourseHub.Courses.Lesson, :published)
# Or with Ash.Query / Ash.Changeset for complex cases
query = Ash.Query.for_read(Lesson, :published)
Ash.read!(query)

ㅤ

Main Capabilities of Actions

1. `argument` — Input Parameters

Allows passing data into an action and validating it.

argument :title, :string, allow_nil?: false, constraints: [min_length: 5]
argument :published_at, :datetime, default?: &DateTime.utc_now/0
argument :user_id, :uuid, allow_nil?: false

2. `accept` — Which Attributes Can Be Changed

Limits the list of fields that can be modified during create or update. Very useful for security.

create :register do
  accept [:email, :password, :name]
end

update :update_profile do
  accept [:name, :bio, :avatar_url]
end

3. `change` — Data Transformations

The most powerful and frequently used part of Actions. Here the main business logic happens.

create :publish do
  argument :reason, :string

  change set_attribute(:status, :published)
  change set_attribute(:published_at, &DateTime.utc_now/0)

  change {CourseHub.Changes.NotifySubscribers, topic: "lessons"}

  change fn changeset, _context ->
    Ash.Changeset.change_attribute(changeset, :slug, generate_slug(changeset))
  end
end

4. `prepare` — Query Preparation (mainly for `read`)

Allows pre-configuring the query: sorting, preloading relations, additional filters.

read :published do
  filter expr(status == :published)

  prepare build(
    sort: [inserted_at: :desc],
    load: [:author, :comments],
    limit: 20
  )
end

5. Hooks (before/after)

Allows executing code before or after an action.

create :publish do
  before_action fn changeset, _context ->
    validate_business_rules(changeset)
  end

  after_action fn _changeset, lesson, _context ->
    LessonNotifier.publish_event(lesson)
    {:ok, lesson}
  end

  after_transaction fn
    {:ok, lesson}, _context -> broadcast_new_lesson(lesson)
    {:error, _}, _ -> :ok 
  end
end

6. `transaction?` — Transaction Management

Determines whether the action should be wrapped in a database transaction.

action :transfer_money, :boolean do
  argument :from_account_id, :uuid
  argument :to_account_id, :uuid
  argument :amount, :decimal

  transaction? true

  run fn input, _context ->
    # complex operation with multiple records
    {:ok, true}
  end
end

7. `pipe_through` — Reusing Logic

Allows creating common pipelines and attaching them to different actions (very useful for DRY).

# In Resource
pipelines do
  pipeline :ensure_admin do
    change ensure_actor_role(:admin)
    validate actor_role(:admin)
  end
end

create :create_admin_content do
  pipe_through :ensure_admin
  accept [:title, :content]
end

update :update_admin_content do
  pipe_through :ensure_admin
  accept [:title, :content]
end

ㅤ

Why Actions Are Awesome?

Full typing and introspection — Ash knows everything about an action at runtime (used for GraphQL, forms, admin panels).
Declarativeness — code reads like business documentation.
Reusability — one action can be used in LiveView, API, Background Job, Tests.
Security — authorization policies are tied to specific actions.
Testability — easy to test individual actions.

ㅤ

Comparison with Classic Elixir/Phoenix

Approach	Where is logic?	Number of files	Clarity
Ecto + Context	Context + Changeset	4–8	Medium
Ash Actions	In one Resource	1	High

Actions are where all your business logic lives.

ㅤ

🏢 What is a Domain?

Domain is a logical container that groups related Resources.
It is similar to Phoenix Context, but much more powerful. If Resource describes one entity (like User, Lesson, Order), then Domain is a "module" or "bounded context" (in DDD terms) that brings together several entities of one business area.

Example:

Accounts — domain for users, profiles, authorization.
Courses — domain for courses, lessons, tests, enrollments.
Billing — domain for payments, subscriptions, invoices.
Therapy — domain for therapy sessions, conversations, messages.

ㅤ

Three Main Goals of Domain

Grouping Resources Organizing the project. Instead of all resources being scattered, they are explicitly grouped into logical units.
Centralized Code Interface Domain allows defining convenient wrapper functions for calling resource actions.
Shared Settings and Cross-Cutting Concerns Here you can set behavior that applies to all resources in the domain (timeouts, default pagination, authorization, etc.).

ㅤ

How Domain Looks in Practice

defmodule CourseHub.Courses do
  use Ash.Domain, otp_app: :course_hub

  # 1. Grouping resources
  resources do
    resource CourseHub.Courses.Course
    resource CourseHub.Courses.Lesson
    resource CourseHub.Courses.Quiz
    resource CourseHub.Courses.Enrollment
  end

  # 2. Code Interface — convenient functions
  define :get_lesson, action: :read, args: [:id], get?: true
  define :list_published_courses, action: :published
  define :enroll_user, action: :create, resource: CourseHub.Courses.Enrollment

  # 3. Shared settings
  execution do
    timeout :timer.seconds(30)
    default_page_size 20
  end

  # Enabling AshAdmin (admin panel)
  admin do
    show? true
  end
end

ㅤ

Why Do You Need Domain?

Organization and boundaries. Clearly separates different parts of the application (like bounded contexts in DDD). Accounts doesn't know about Billing without explicit relations.
Convenient public API. Instead of Ash.read!(CourseHub.Courses.Lesson, ...), you write beautifully:

CourseHub.Courses.get_lesson!(lesson_id)
CourseHub.Courses.list_published_courses!()

Centralized management. You can disable authorization for the entire domain in dev mode, set common policies, notifiers, etc.
Introspection and extensions. Many Ash extensions (GraphQL, JsonApi, Phoenix) work at the domain level.
Testing and isolation. Easier to test one business area as a whole.

ㅤ

Best Practices When Working with Domains

One resource — one domain. A resource cannot belong to multiple domains simultaneously.
How many domains to make?
- Small project → 1–3 domains.
- Medium/large → one per major business area (Accounts, Core, Billing, Notifications, etc.). This helps with scaling and understanding architecture.
Code Interface — a very powerful feature. You can define not only simple wrappers but also those with preset filters, loads, etc.

ㅤ

Comparison: Domain vs Resource

Aspect	Resource	Domain
What it describes	One entity	Group of entities
Where logic lies	Attributes, actions, policies	Grouping + shared settings
Code call	Through domain	Public app interface
Analog in Phoenix	Schema + Context (partially)	Phoenix Context
Quantity per project	Many (one per table)	Few (per business area)

ㅤ

Why Domain Is Especially Useful?

Project grows >10–15 resources.
Complex authorization (policies) needed.
Doing GraphQL / JSON:API / Admin panel.
Team development — everyone needs to understand boundaries.

ㅤ

⚔️ Ash + Phoenix vs Ecto + Phoenix

Aspect	Phoenix + Ecto (classic) 😐	Phoenix + Ash 🔥	Who wins?
Business logic organization	Scattered across Context, Changeset, separate modules	Everything in one Resource	Ash
CRUD operations	Write manually: create, read, update, delete + boilerplate	`defaults [:create, :read, :update, :destroy]` — done ✨	Ash
Authorization	Manual checks / Bodyguard / scopes	Declarative Policies (secure by default) ⚡	Ash
Computed fields	Virtual fields + functions in Context	Calculations — auto-loaded and cached	Ash
Number of files per entity	3–6+ files (Schema + Context + Changeset + Policy)	One file — Resource	Ash
API generation	Absinthe / GraphQL manually + lots of code	`AshGraphql` or `AshJsonApi` — add extension and done	Ash
LiveView forms	Phoenix.Component + manual validation	`AshPhoenix.Form` — forms know everything themselves	Ash
Multi-tenancy	Write yourself (or use schemas)	Built into Policies (attribute-based or context-based)	Ash
Maintainability after 2–3 years	Medium (logic spreads)	High (everything declarative and in one place)	Ash
Development speed	Normal at start	Much faster after learning curve 🚀	Ash
Flexibility	Maximum (full control)	Very high + can escape to pure Ecto when needed	Draw
Learning curve	Easier for beginners	Steeper but pays off in large projects	Ecto

ㅤ

What to Choose in 2026?

Pros of Ash 🔥:

Declarativeness → "Describe the domain — Ash does the rest."
Boilerplate reduction by orders of magnitude ("I write code 3–5 times faster").
Automatic generation of GraphQL, JSON:API, Admin panel, authentication.
Authorization policies and multi-tenancy out of the box.
Excellent maintainability in the long run (exactly what production dreams of). Pros of classic Phoenix + Ecto 😐:
Full control over every byte of code.
Simpler for very small projects and pet projects.
No extra abstraction (if you love "bare" Elixir).
Easier for Elixir beginners. When to choose what?
Small pet project or experiment → pure Phoenix + Ecto.
Medium/large project, SaaS, long-lived app → Phoenix + Ash (huge time and nerve savings).
Want both → you can safely mix in one project (Ash and regular Ecto coexist perfectly).

ㅤ

😴 Conclusion

Ash is not just a library but a shift in approach to Elixir development. It especially shines in medium and large projects where clean architecture, development speed, and long-term maintainability are important.
Of course, it has a learning curve and may be excessive for very simple pet projects. But if you're tired of spreading logic and want a clear declarative structure—Ash gives a very pleasant sense of control over your code.

ㅤ

🙏 From the Author

Thank you very much for your interest in this article! I hope it helped you understand what Ash is and why it's used.
If you liked this article and want more materials like this—join me on my Telegram channel, where I post book reviews, Elixir publications, technical literature, and interesting news!

Ash Framework: Знакомство

Artyom Molchanov — Sat, 04 Apr 2026 08:05:54 +0000

Когда новичок приходит в Elixir и Phoenix, ему почти всегда первым делом показывают Ecto. Создаём схемы, пишем changeset’ы, выносим запросы в контексты. Подход гибкий, но с ростом проекта начинает проявляться серьёзная проблема 😟

Бизнес-логика расползается по десяткам файлов. В итоге возникает путаница относительно того, куда именно поместить код обработки запросов и как разобраться в существующем беспорядке, а через год-два сложно понять, где находится «правильное» место для кода, а новые разработчики тратят недели на погружение в проект

Ash Framework создан именно для решения этой боли 💪

Важное уточнение: Ash — это не замена Phoenix и не новый веб-фреймворк. Это мощный декларативный слой, который организует бизнес-логику и данные поверх существующей экосистемы.

ㅤ

📖 Предисловие

Важно понимать, что цель этой статьи вовсе не состоит в том, чтобы уговорить вас использовать Ash повсеместно и постоянно!

Сам я люблю Ash именно из-за того, что он даёт возможность собрать всю необходимую логику в едином пространстве, где ей самое место. Этот инструмент значительно упрощает работу, уменьшая количество шаблонного кода и освобождая от утомительной реализации стандартных CRUD.

Если готовы ознакомиться с таким инструментом, но собираетесь прибегать к нему лишь тогда, когда это действительно оправдано — смело читайте дальше. Ash — это не универсальное лекарство от всех проблем, а всего лишь удобный набор полезных инструментов.

ㅤ

🚀 Что такое Ash?

Ash — это фреймворк для быстрой и эффективной разработки приложений на Elixir. Его цель заключается в облегчении запуска новых проектов и обеспечении удобства поддержки существующих решений, гарантируя отличную производительность и стабильность даже после длительного периода активной разработки.

Ключевая идея Ash звучит так:

Точно сформулируй структуру своей бизнес-логики, а всю остальную работу (миграция базы данных, создание API-интерфейсов, валидация данных, управление доступом, оформление форм) возьмет на себя Ash

Фреймворк прекрасно взаимодействует с такими популярными инструментами, как Phoenix, PostgreSQL, GraphQL и LiveView.

ㅤ

🔑 Ключевые абстракции Ash

Всё в Ash строится вокруг трёх основных понятий:

Resource (Ресурс) — описание одной бизнес-сущности
Action (Действие) — операция, которую можно выполнить над ресурсом
Domain (Домен) — логическая группа ресурсов одной бизнес-области

Давайте разберём каждую концепцию подробно!

ㅤ

🧩 Что такое Ресурс?

Resource — это один модуль, в котором полностью описана одна бизнес-сущность вашего приложения (Пользователь, Урок, Заказ, Пост, Платёж и т.д.).

В нём в одном месте собрано всё, что касается этой сущности:

Структура данных (поля)
Связи с другими сущностями
Операции, которые можно выполнять (CRUD + кастомные)
Правила валидации
Авторизация (кто и что может делать)
Вычисляемые поля
Индексы и ограничения
Настройки хранения в базе

Resource в Ash объединяет в одном модуле то, что в классическом Elixir/Phoenix обычно разносится по нескольким частям: Ecto Schema, Changesets, Context-функции, а также логика авторизации и вычисляемые поля.

ㅤ

Resource — сердце Ash

Ash построен вокруг идеи Resource-Oriented Design. Ты описываешь что представляет собой сущность и что с ней можно делать — а Ash сам генерирует остальное: SQL-запросы, API, формы, миграции, валидацию и т.д.

ㅤ

Полный пример современного Resource

defmodule CourseHub.Courses.Lesson do
  use Ash.Resource,
    otp_app: :course_hub,              # Привязка к приложению
    domain: CourseHub.Courses,         # В каком домене живёт
    data_layer: AshPostgres.DataLayer  # Где храним данные

  # ==================== ХРАНЕНИЕ ====================
  postgres do
    table "lessons"
    repo CourseHub.Repo
  end

  # ==================== ПОЛЯ (Attributes) ====================
  attributes do
    uuid_primary_key :id

    attribute :title, :string do
      public? true               # видно в API и формах
      allow_nil? false
      constraints min_length: 3, max_length: 200
    end

    attribute :description, :string, public?: true
    attribute :content, :string, public?: true

    attribute :status, :atom do
      public? true
      default? :draft
      constraints one_of: [:draft, :published, :archived]
    end

    create_timestamp :inserted_at
    update_timestamp :updated_at
  end

  # ==================== СВЯЗИ (Relationships) ====================
  relationships do
    belongs_to :author, CourseHub.Accounts.User do
      public? true
      allow_nil? false
    end

    has_many :comments, CourseHub.Courses.Comment do
      public? true
    end

    many_to_many :tags, CourseHub.Courses.Tag do
      public? true
      through CourseHub.Courses.LessonTag
      source_attribute_on_join_resource :lesson_id
      destination_attribute_on_join_resource :tag_id
    end
  end

  # ==================== ДЕЙСТВИЯ (Actions) ====================
  actions do
    defaults [:create, :read, :update, :destroy]

    # Кастомное чтение
    read :published do
      filter expr(status == :published)
      pagination offset?: true, countable: true
      prepare build(sort: [inserted_at: :desc])
    end

    # Кастомное создание с логикой
    create :publish do
      argument :reason, :string
      change set_attribute(:status, :published)
    end

    # Полностью кастомное действие
    action :calculate_reading_time, :integer do
      argument :content, :string, allow_nil?: false
      run fn input, _context ->
        minutes = String.length(input.arguments.content) |> div(500) |> max(1)
        {:ok, minutes}
      end
    end
  end

  # ==================== ВЫЧИСЛЯЕМЫЕ ПОЛЯ ====================
  calculations do
    calculate :reading_time_minutes, :integer do
      calculation fn records, _context ->
        Enum.map(records, fn lesson ->
          (String.length(lesson.content || "") / 500) |> Float.ceil() |> trunc()
        end)
      end
    end
  end

  # ==================== ИНДЕКСЫ ====================
  identities do
    identity :unique_title_per_author, [:title, :author_id]
  end

  # ==================== АВТОРИЗАЦИЯ ====================
  policies do
    policy action_type(:read) do
      authorize_if always()
    end

    policy action(:update) do
      authorize_if expr(author_id == ^actor(:id))
    end
  end
end

ㅤ

Основные разделы Resource

Раздел	Что описывает	Аналог в обычном Elixir/Phoenix
`attributes`	Поля и их типы + валидация	Ecto Schema + поля
`relationships`	Связи с другими ресурсами	Ecto associations
`actions`	Все возможные операции (CRUD + кастомные)	Context-функции + Changesets
`calculations`	Вычисляемые поля (на лету)	Virtual fields / функции
`aggregates`	Агрегаты (count, sum, avg и т.д.)	Запросы с group_by
`identities`	Уникальные индексы	Ecto unique constraints
`policies`	Правила авторизации	Ручная проверка прав
`postgres`	Настройки хранения в PostgreSQL	Миграции

ㅤ

Ключевые особенности Resource

Всё в одном файле — огромный плюс для понимания сущности.
Introspection — Ash может в runtime читать всю информацию о ресурсе (поля, действия, политики). Это используется для генерации API, форм, админок.
Декларативность — ты описываешь что должно быть, а не как это реализовать.
Расширяемость — можно добавлять свои changes, preparations, validations, notifiers.
Embedded Resources — можно создавать ресурсы, которые хранятся не в отдельной таблице, а как JSON/Map внутри другого ресурса.

ㅤ

Когда создавать новый Resource?

Практически всегда, когда появляется новая бизнес-сущность (таблица или даже сложный JSON-объект).

ㅤ

🛠️ Подробнее об Actions (Действиях)

Action (Действие) — это явно объявленная операция, которую можно выполнить над ресурсом.

Всё взаимодействие с данными в Ash идёт только через Actions. Нельзя просто взять запись и изменить её вручную — всегда вызываешь действие.

Это заменяет:

Обычные функции в Context’ах Phoenix
Changesets в Ecto
Контроллеры и сервисные слои

ㅤ

Пять типов Actions

	Тип действия	Что делает?	В транзакции?	Что возвращает?
✨	`create`	Создаёт новую запись	Да	Новую запись ресурса
🔍	`read`	Читает одну запись или целый список	Нет (можно включить)	Запись или список записей
✏️	`update`	Обновляет существующую запись	Да	Обновлённую запись
🗑️	`destroy`	Удаляет запись	Да	Удалённую запись
⚡	`action` (Generic)	Любая кастомная бизнес-логика	Нет (можно включить)	Любое значение (что угодно)

ㅤ

Полный пример всех типов Actions

defmodule CourseHub.Courses.Lesson do
  use Ash.Resource, ...

  actions do
    # 1. Стандартные CRUD (defaults)
    defaults [:create, :read, :update, :destroy]

    # 2. Кастомное Read
    read :published do
      filter expr(status == :published)
      pagination offset?: true, countable: true, default_limit: 20
      prepare build(sort: [inserted_at: :desc], load: [:author, :comment_count])
    end

    read :for_user do
      argument :user_id, :uuid, allow_nil?: false
      filter expr(author_id == ^arg(:user_id))
    end

    # 3. Кастомное Create
    create :publish do
      argument :reason, :string, allow_nil?: true

      # Изменения (changes)
      change set_attribute(:status, :published)
      change set_attribute(:published_at, &DateTime.utc_now/0)
      change {CourseHub.Changes.NotifySubscribers, topic: "new_lessons"}

      # Хуки
      after_action fn _changeset, lesson, _context ->
        # side-effect после успешного создания
        {:ok, lesson}
      end
    end

    # 4. Кастомное Update
    update :archive do
      accept [:archive_reason]                    # какие поля можно менять
      change set_attribute(:status, :archived)
      change set_attribute(:archived_at, &DateTime.utc_now/0)
    end

    # 5. Generic Action (полностью кастомное)
    action :calculate_reading_time, :integer do
      argument :content, :string, allow_nil?: false
      argument :words_per_minute, :integer, default?: 200

      run fn input, _context ->
        minutes = String.length(input.arguments.content) 
                  |> div(input.arguments.words_per_minute) 
                  |> max(1)
        {:ok, minutes}
      end
    end
  end
end

ㅤ

Как вызывать Actions

# Через домен (рекомендуемый способ)
CourseHub.Courses.publish!(lesson, %{reason: "Готово"})

CourseHub.Courses.read!(CourseHub.Courses.Lesson, :published)

# Или с Ash.Query / Ash.Changeset для сложных случаев
query = Ash.Query.for_read(Lesson, :published)
Ash.read!(query)

ㅤ

Основные возможности Actions

1. `argument` — входные параметры

Позволяет передавать данные в действие и валидировать их.

argument :title, :string, allow_nil?: false, constraints: [min_length: 5]

argument :published_at, :datetime, default?: &DateTime.utc_now/0

argument :user_id, :uuid, allow_nil?: false

2. `accept` — какие атрибуты можно менять

Ограничивает список полей, которые разрешено изменять при create или update. Очень полезно для безопасности.

create :register do
  accept [:email, :password, :name]   # только эти поля можно передать
end

update :update_profile do
  accept [:name, :bio, :avatar_url]
end

3. `change` — трансформации данных

Самая мощная и часто используемая часть Actions. Здесь происходит основная бизнес-логика.

create :publish do
  argument :reason, :string

  # Встроенные изменения
  change set_attribute(:status, :published)
  change set_attribute(:published_at, &DateTime.utc_now/0)

  # Кастомный change-модуль
  change {CourseHub.Changes.NotifySubscribers, topic: "lessons"}

  # Анонимная функция
  change fn changeset, _context ->
    Ash.Changeset.change_attribute(changeset, :slug, generate_slug(changeset))
  end
end

4. `prepare` — подготовка запроса (в основном для `read`)

Позволяет заранее настроить запрос: сортировку, предзагрузку связей, дополнительные фильтры и т.д.

read :published do
  filter expr(status == :published)

  prepare build(
    sort: [inserted_at: :desc],
    load: [:author, :comments, :reading_time_minutes],
    limit: 20
  )
end

5. Хуки (before/after)

Позволяют выполнить код до или после выполнения действия.

create :publish do
  before_action fn changeset, _context ->
    # проверка перед выполнением
    validate_business_rules(changeset)
  end

  after_action fn _changeset, lesson, _context ->
    # side-effect после успешного создания
    LessonNotifier.publish_event(lesson)
    {:ok, lesson}
  end

  after_transaction fn 
    {:ok, lesson}, _context -> broadcast_new_lesson(lesson)
    {:error, _}, _ -> :ok 
  end
end

6. `transaction?` — управление транзакцией

Определяет, нужно ли оборачивать действие в базу данных транзакцию.

action :transfer_money, :boolean do
  argument :from_account_id, :uuid
  argument :to_account_id, :uuid
  argument :amount, :decimal

  transaction? true   # будет выполнено в одной транзакции

  run fn input, _context ->
    # сложная операция с несколькими записями
    {:ok, true}
  end
end

7. `pipe_through` — переиспользование логики

Позволяет создавать общие пайплайны и подключать их к разным действиям (очень полезно для DRY).

# В Resource
pipelines do
  pipeline :ensure_admin do
    change ensure_actor_role(:admin)
    validate actor_role(:admin)
  end
end

create :create_admin_content do
  pipe_through :ensure_admin
  accept [:title, :content]
end

update :update_admin_content do
  pipe_through :ensure_admin
  accept [:title, :content]
end

ㅤ

Почему Actions — это круто?

Полная типизация и introspection — Ash знает всё о действии в runtime (используется для GraphQL, форм, админок)
Декларативность — код читается как документация бизнеса
Повторное использование — одно действие можно использовать в LiveView, API, Background Job, Tests
Безопасность — политики авторизации привязываются к конкретным действиям
Тестируемость — легко тестировать отдельные действия

ㅤ

Сравнение с классическим Elixir/Phoenix

Подход	Где логика?	Кол-во файлов	Понятность
Ecto + Context	Context + Changeset	4–8	Средняя
Ash Actions	В одном Resource	1	Высокая

Actions — это то место, где живёт вся бизнес-логика твоего ресурса

ㅤ

🏢 Что такое Domain (Домены)?

Domain (Домен) — это логический контейнер, который объединяет группу связанных Resources (ресурсов).

Он похож на Phoenix Context, но гораздо мощнее. Если Resource — это описание одной сущности (как User, Lesson, Order), то Domain — это «модуль» или «bounded context» (в терминах DDD), который собирает вместе несколько сущностей одной бизнес-области.

Пример:

Accounts — домен для пользователей, профилей, авторизации
Courses — домен для курсов, уроков, тестов, enrollments
Billing — домен для платежей, подписок, инвойсов
Therapy — домен для терапии, разговоров, сообщений (из реальных примеров)

ㅤ

Три главные цели Domain

Группировка ресурсов

Организация проекта. Вместо того чтобы все ресурсы были разбросаны, они явно лежат в логических группах.
Централизованный Code Interface

Domain позволяет определять удобные функции-обёртки для вызова действий ресурсов.
Общие настройки и cross-cutting concerns

Здесь можно задать поведение, которое применяется ко всем ресурсам домена (таймауты, пагинация по умолчанию, авторизация и т.д.).

ㅤ

Как выглядит Domain на практике

defmodule CourseHub.Courses do
  use Ash.Domain, otp_app: :course_hub

  # 1. Группировка ресурсов
  resources do
    resource CourseHub.Courses.Course
    resource CourseHub.Courses.Lesson
    resource CourseHub.Courses.Quiz
    resource CourseHub.Courses.Enrollment
  end

  # 2. Code Interface — удобные функции
  define :get_lesson, action: :read, args: [:id], get?: true
  define :list_published_courses, action: :published
  define :enroll_user, action: :create, resource: CourseHub.Courses.Enrollment

  # 3. Общие настройки
  execution do
    timeout :timer.seconds(30)        # глобальный таймаут
    default_page_size 20
  end

  # Включение AshAdmin (админка)
  admin do
    show? true
  end
end

ㅤ

Зачем нужен Domain?

Организация и границы. Чётко разделяет разные части приложения (как bounded contexts в DDD). Accounts не знает про Billing без явного отношения
Удобный публичный API. Вместо Ash.read!(CourseHub.Courses.Lesson, ...) ты пишешь красиво:

  CourseHub.Courses.get_lesson!(lesson_id)
  CourseHub.Courses.list_published_courses!()

Централизованное управление. Можно отключить авторизацию для всего домена в dev-режиме, задать общие политики, notifiers и т.д.
Introspection и расширения. Многие расширения Ash (GraphQL, JsonApi, Phoenix и т.д.) работают на уровне домена
Тестирование и изоляция. Легче тестировать одну бизнес-область целиком

ㅤ

Лучшие практики при работе с доменом

Один ресурс — один домен. Ресурс не может принадлежать нескольким доменам одновременно.
Сколько доменов делать?
- Маленький проект → 1–3 домена.
- Средний/большой → по одному на крупную бизнес-область (Accounts, Core, Billing, Notifications и т.д.). Это помогает в масштабировании и понимании архитектуры.
Code Interface — очень мощная фича. Ты можешь определять не только простые обёртки, но и с предустановленными фильтрами, load'ами и т.д.

ㅤ

Сравнение: Domain vs Resource

Аспект	Resource	Domain
Что описывает	Одну сущность	Группу сущностей
Где лежит логика	Атрибуты, действия, политики	Группировка + общие настройки
Вызов кода	Через домен	Публичный интерфейс приложения
Аналог в Phoenix	Schema + Context (частично)	Phoenix Context
Количество на проект	Много (по одной на таблицу)	Мало (по бизнес-областям)

ㅤ

Почему Domain особенно полезен?

Проект растёт > 10–15 ресурсов
Нужна сложная авторизация (policies)
Делаешь GraphQL / JSON:API / Admin-панель
Командная разработка — всем нужно понимать границы

ㅤ

⚔️ Ash + Phoenix vs Ecto + Phoenix

Аспект	Phoenix + Ecto (классика) 😐	Phoenix + Ash 🔥	Кто выигрывает?
Организация бизнес-логики	Разбросана по Context, Changeset, отдельным модулям	Всё в одном Resource — атрибуты, действия, политики, связи	Ash (всё на виду)
CRUD-операции	Пишешь вручную: create, read, update, delete + boilerplate	`defaults [:create, :read, :update, :destroy]` — и готово ✨	Ash (1 строка)
Авторизация	Ручные проверки / Bodyguard / scopes	Декларативные Policies (secure by default) ⚡	Ash (автоматика)
Вычисляемые поля	Virtual fields + функции в Context	Calculations — автоматически подгружаются и кэшируются	Ash
Количество файлов на сущность	3–6+ файлов (Schema + Context + Changeset + Policy)	1 файл — Resource	Ash
Генерация API	Absinthe / GraphQL вручную + много кода	`AshGraphql` или `AshJsonApi` — добавил расширение и готово	Ash
LiveView формы	Phoenix.Component + ручная валидация	AshPhoenix.Form — формы сами знают всё	Ash
Multi-tenancy	Пишешь сам (или используешь схемы)	Встроено в Policies (attribute-based или context-based)	Ash
Поддерживаемость через 2–3 года	Средняя (логика расползается)	Высокая (всё декларативно и в одном месте)	Ash
Скорость разработки	Нормальная на старте	Значительно быстрее после кривой обучения 🚀	Ash (после обучения)
Гибкость	Максимальная (полный контроль)	Очень высокая + можно escape в чистый Ecto когда нужно	Ничья
Кривая обучения	Легче для новичков	Круче, но окупается в большом проекте	Ecto

Что стоит выбрать в 2026 году?

Плюсы Ash 🔥

Декларативность → «Опиши домен — остальное Ash выведет сам»
Сокращение шаблонного кода (часто встречаются отзывы о Ash вроде: «я создаю программы, используя в 3–5 раз меньше строк»)
Автоматическая генерация GraphQL, JSON:API, Admin-панели, аутентификации
Политики авторизации и multi-tenancy из коробки
Отличная поддерживаемость на длинной дистанции (именно то, о чём мечтают в продакшене)

Плюсы классического Phoenix + Ecto 😐

Полный контроль над каждым байтом кода
Проще для совсем маленьких проектов и пет-проектов
Нет дополнительной абстракции (если ты любишь «голый» Elixir)
Легче для новичков в Elixir

Когда выбирать что?

Маленький пет-проект или эксперимент → бери чистый Phoenix + Ecto
Средний/крупный проект, SaaS, долгоживущее приложение → Phoenix + Ash (экономия времени и нервов огромная)
Хочешь и то, и другое → можно спокойно миксовать в одном проекте (Ash и обычный Ecto отлично уживаются)

ㅤ

😴 В заключение

Ash — это не просто библиотека, а изменение подхода к разработке на Elixir. Он особенно хорошо заходит в проектах среднего и крупного размера, где важны чистота архитектуры, скорость разработки и долгосрочная поддерживаемость.

Конечно, у него есть кривая обучения, и в совсем простых пет-проектах он может быть избыточен. Но если вы устали от расползающейся логики и хотите чёткой, декларативной структуры — Ash дарит очень приятное ощущение контроля над кодом.

ㅤ

🥴 От автора

Спасибо большое за интерес к этой статье! Надеюсь, она помогла разобраться, что представляет собой Ash и зачем он используется.

Если эта статья пришлась вам по душе и хочется ещё материалов такого плана, присоединяйтесь ко мне в моём телеграм-канале, где выкладываю обзоры книг, публикации по Elixir, переводы технической литературы и интересные новости!

[Boost]

Artyom Molchanov — Thu, 19 Mar 2026 17:05:36 +0000

Alexey Bolshakov

Mar 19

AD9833 DDS Generator Board

#dds #microchips #stm8 #microcontroller

5 min read

[Boost]

Artyom Molchanov — Sun, 15 Mar 2026 13:11:26 +0000

Sagiv ben giat

Mar 12

The Internet Is Getting Quieter - Who Will Feed the Next Generation of AI?

#ai #knowledgesharing #stackoverflow #opinion

5 min read

BEAM: In Plain English

Artyom Molchanov — Thu, 25 Sep 2025 07:00:03 +0000

Imagine a universe where billions of messages, calls, and financial transactions happen every second. Each message reaches its recipient flawlessly, phone calls remain uninterrupted, and funds are transferred instantly. What ensures such impeccable performance? No, it's not magic—it's virtual machines—the unsung heroes of digital infrastructure.

Among them stands out one remarkable machine — BEAM. Created decades ago, it looks like an invention from a distant future. It powers stable operations for giants like WhatsApp, Discord, financial services, and IoT systems. Even after all these years since its inception, BEAM continues to impress with its performance and reliability.

This article is not intended as an in-depth exploration into the inner workings of BEAM or its implementation details. We won't delve into byte code flow or provide specific internal code snippets here. Instead, this piece aims to give you a general understanding of what BEAM does, why it's important, and how it can benefit your business under heavy loads. For those who want to dive deeper into BEAM’s internals, I recommend reading the book — The BEAM Book: Understanding the Erlang Runtime System.

In today's era characterized by rapid development of real-time technologies, artificial intelligence, and mass parallel user connections, BEAM excels at providing high response speed, reliability even during failures, and quick adaptation to increasing load, making it an optimal solution for complex challenges. But let's start with the basics!

What Is a Virtual Machine? 🤔

Imagine writing a program that needs to run everywhere—on laptops, smartphones, servers, smart speakers, etc. How do you ensure compatibility across different operating systems and hardware configurations? The answer lies in using a virtual machine (VM). It's a special execution environment that interprets your code, acting as a bridge between your application and the underlying device. The VM takes intermediate code (like Java bytecode) and translates it into instructions suitable for each platform, freeing you from worrying about memory management or multithreading intricacies. In essence, a virtual machine serves as a universal adapter enabling your code to run anywhere!

Additionally, many virtual machines come equipped with useful tools such as automatic garbage collection, built-in performance optimizations, and data protection mechanisms. These features make app development significantly easier and more efficient. Without VMs, creating modern projects ranging from mobile games to large-scale cloud services would be much harder.

Why Are Virtual Machines Needed? 🌟

Virtual machines aren't just developer conveniences but powerful tools for building versatile, reliable, and scalable solutions. Let's explore their key advantages through practical examples:

Cross-platform Compatibility 📱💻

Write once, run anywhere. An example is a banking app written in Java running seamlessly both on bank servers and client Android phones thanks to JVM. This saves time and resources, especially valuable in enterprise-level development involving diverse platforms.
Resource Management 🧹

Virtual machines handle resource allocation, including memory control (via garbage collection), threading, and hardware interaction. For instance, in the Erlang VM (BEAM), each process gets isolated memory areas, preventing issues caused by individual process crashes. Such architecture minimizes bugs and simplifies coding tasks, relieving developers from manually managing memory allocation and deallocation.
Security 🔒

By isolating executable code from the OS, virtual machines create secure sandboxes protecting against potential threats posed by harmful programs. This feature is crucial in environments like AWS Lambda or Google Cloud Functions, where thousands of code fragments from various users execute simultaneously on shared hardware.
Optimization ⚡

Many VMs dynamically optimize code execution while applications are running. One prominent example is Just-In-Time compilation (JIT), which makes browser engines like V8 incredibly fast. Starting with version OTP 24, BEAM introduced its own JIT mechanism, further enhancing performance. These techniques prove invaluable when dealing with repetitive computations common in highly loaded web apps.
Support for Complex Systems 🌐

Some VMs are specifically designed to support concurrency, distributed computing, and fault tolerance. For example, popular game server infrastructures, like those powering League of Legends, rely heavily on BEAM, efficiently handling millions of concurrent player connections with minimal latency and high reliability.

Thus, virtual machines allow developers to focus directly on product functionality rather than low-level technicalities, accelerating development processes and reducing costs.

Popular Virtual Machines: Who's Who? 🦸‍♂️

JVM (Java Virtual Machine): Used for Java, Kotlin, Scala. Ideal for large business systems (banking solutions), web servers (Spring Framework), and Android platforms.

Pros: Extensive ecosystem (huge library availability), Just-In-Time compilation technology.
Cons: High initial RAM usage, comparatively slow startup times.
Fact: Adopted by nearly 90% of Fortune 500 companies worldwide.

V8 (JavaScript Engine): Powering Node.js and modern browsers. Optimized for web environments.

Pros: Exceptional performance for client-side websites.
Con: Not well suited for long-term server-based solutions, where BEAM shines.

CLR (.NET Common Language Runtime): Supports languages within the .NET family, notably C#. Strongly integrated with Microsoft technologies (Azure).

Pros: Seamless integration with Windows platforms.
Con: Limited cross-platform capabilities compared to JVM.

BEAM (Erlang VM): Designed for Erlang, Elixir, and other compatible languages (LFE, Alpaca). Best suited for highly scalable, resilient, and concurrent systems, excelling in messaging, telecommunications, and fintech.

Pros: Capable of handling millions of simultaneous processes with minimal delays.
Con: Smaller toolkit and framework libraries, though actively growing (Phoenix, Nerves frameworks).

Comparison Table:

VM	Strengths	Weaknesses	Use Cases
JVM	Versatility, extensive ecosystem	Memory consumption, startup lag	Enterprise, Android
V8	Speed for web clients	Unsuitable for backend servers	Node.js, Browsers
CLR	Integration with Microsoft tech	Dependence on MS ecosystem	.NET, Azure
BEAM	Concurrency, resilience	Fewer libraries & frameworks	Real-time, Telecom

By 2025, with the rise of IoT and streaming data, BEAM has become particularly relevant for real-time applications.

Deeper Look Into BEAM 🌌

BEAM is a virtual machine engineered for programming languages like Erlang, Elixir, and others (such as LFE). Initially developed in the 1990s by Ericsson for telecommunication purposes, where reliability and capacity to manage massive traffic were critical, today BEAM forms the backbone of numerous high-performance services. It handles billions of daily messages (as seen in WhatsApp), supports millions of online gamers simultaneously (products like League of Legends), and keeps real-time chat services (Discord) functioning smoothly. As the need for high throughput, low latency, and robustness grows, BEAM proves indispensable in 2025 more than ever before.

History of BEAM: From Telco to Global Platforms 📜

Originally, BEAM stood for "Bogdan's Erlang Abstract Machine" named after Bogumil Hausman ("Bogdan"), who created its first iteration. However, over time, it became associated with another author—"Björn's Erlang Abstract Machine", reflecting contributions made by Björn Gustavsson, who maintains the current implementation. Both contributors played significant roles in shaping the system while working at Ericsson.

Before BEAM emerged, there was another virtual machine called JAM (Joe's Abstract Machine)—the first interpreter for the Erlang language. Developed by Joe Armstrong alongside Mike Williams in C, detailed insights are found in the developers' blog.

Therefore Bogumil (“Bogdan”) Hausman created TEAM (Turbo Erlang Abstract Machine). It compiled the Erlang code to C code, which was then compiled to native code using GCC.

Today, BEAM finds widespread use in finance (Klarna), advertising (AdRoll), notification systems (Pinterest), and Internet of Things (IoT) deployments (Nerves). With advancements such as Just-In-Time compiler introduction in OTP 24 and type improvement enhancements in Elixir v1.15+, BEAM remains a viable choice. Future plans include closer alignment with WebAssembly for supporting web applications.

What's So Great About BEAM? 🚀

BEAM distinguishes itself among other virtual machines due to unique characteristics essential for scalable and demanding applications. Below are its main advantages, supported by concrete figures and comparisons with similar solutions:

Fast and Lightweight Processes ⚡

Process creation in BEAM takes only microseconds, consuming approximately 2.5 KB per process, allowing millions of instances to coexist on a single machine. Compared to Java threads requiring megabytes of memory, BEAM offers superior efficiency.

🧠 While asynchronous tasks in Rust are lightweight too, BEAM surpasses in building distributed solutions due to its actor model, isolated processes with negligible overhead, auto-failure recovery via supervisors, and hot code swapping without downtime.
Actor Model 🎭

Processes behave independently, exchanging messages without sharing resources or causing blocking. Unlike Java threads, this greatly simplifies concurrent processing. Imagine a chat messenger like Discord where each room acts as an independent process freely accepting new messages regardless of other activities. Performance is impressive: BEAM can process roughly 100k messages per second on a single core.
Let It Crash Philosophy 💥

BEAM embraces the principle of “let it crash”: if a process fails, it simply stops executing. Yet, thanks to careful design, failure goes largely unnoticed by end-users. Consider managing a busy restaurant where someone suddenly leaves mid-shift. Typically, chaos ensues, disrupting service. In BEAM, however, there's a supervisor-like manager immediately spawning a replacement process. Customers continue receiving orders promptly, unaware of any interruption.

☎️ This philosophy proved effective back in the '90s when Ericsson used BEAM to maintain large telecommunication stations. If a component crashed, the overall system remained operational without disruption.
Hot Code Reloading 🔄

Applications can update themselves without halting ongoing operations. BEAM holds two versions of software modules simultaneously, switching almost instantaneously. In contrast, Java transitions require additional effort and may cause temporary delays. Successful implementations include payment gateway Klarna, updating continuously without a single second of downtime, ensuring continuous shopping experiences for customers.
Distributed Systems 🌐

Individual nodes connect into unified clusters through network links. This setup enhances fault tolerance and horizontal scaling. Take Pinterest notifications: thousands of new servers easily join existing clusters, boosting total output without compromising individual node performance. Scalability extends to tens of thousands of nodes with minimal request latencies.
Low Latency ⏱

Incremental garbage collection minimizes delays. The Phoenix framework, built atop BEAM, handles thousands of requests with millisecond-level responses. Other languages like Python occasionally experience longer pauses due to their garbage collection models, whereas BEAM consistently performs under heavy loads with low latency.
Just-In-Time Compilation 🚀

Starting with OTP 24, BEAM introduces Just-In-Time compilation, improving computational-intensive task speeds by up to 20–30%. Although BEAM primarily focuses on concurrency, this optimization dramatically increases execution speed for computation-heavy tasks. Parsing JSON files now happens faster thanks to enhanced compiler optimizations.

Inside BEAM: How Does It Work? 🛠

1. Scheduler: Maestro of Multitasking 🎻

The scheduler in BEAM operates like a conductor leading an orchestra. Thousands of musicians (processes) play together, each needing their turn to perform. Nobody plays for too long—otherwise, music turns chaotic.

📖 Real-world Example: A single WhatsApp server handled millions of active connections simultaneously. Implementing this feat using conventional OS threads would have been impossible, yet BEAM manages it gracefully with its unique scheduling scheme.

How It Works:

There is one scheduler per CPU core. On an eight-core server, eight schedulers operate.
Every process receives a fixed number of steps ("reductions") before yielding control to another process.
Processes fall into two queues: ready-for-execution and waiting-for-resources.
Load balancing employs task stealing mechanics to redistribute workload evenly.
Time-wheel structure stores active timers for efficient timing operations.

📌 Common Issue: Long-running Built-In Functions (BIFs) executed without yielding control can block scheduler activity.

2. Garbage Collection: Keeping Memory Clean 🧹

The garbage collector (GC) in BEAM works similarly to a diligent janitor silently cleaning tables in a bustling city full of restaurants. Each process has its dedicated storage area ("heap"). When unused objects fill a heap, cleanup occurs locally, leaving other processes unaffected.

BEAM implements generational garbage collection: newer elements ("young generation") frequently cleaned because they tend to die quickly, while older generations are checked less often.

📌 Common Issue: Accumulation of long-lived objects can lead to increased resource consumption. Monitor parameters like high_water carefully.

Large binary data (files, images) resides separately outside the GC zone, avoiding unnecessary bloat.

📖 Real-world Example: Discord manages millions of active channels on BEAM. Even if one particular chat accumulates transient data, the cleanup mechanism swiftly removes it without impacting other chats’ performance.

Algorithm Overview:

Heap and stack expand towards each other until meeting, triggering cleanup.
Two types of cycles exist: minor (frequent young-generation cleanups) and major (infrequent old-generation cleanups).
Data copying technique moves values between two memory zones ("from space" → "to space").

✨ Carefully monitor memory growth dynamics in your processes. Rapidly expanding sizes might indicate presence of long-living objects requiring architectural adjustments.

3. Register-Based Architecture: Faster and More Efficient 🧠

BEAM utilizes register-based architecture. Registers act as small, fast-access memory regions storing intermediate results of calculations. Each register holds specific values participating in computational operations. By keeping data close to the processor, registers enable swift access and high-performance operation.

Example: Simple addition (add(A, B) resulting value stored in registers X0 and X1).

Operational Principles:

Registers X (up to 1024): Store function arguments.
Registers Y: Local variables.
Instructions like move and call, direct memory addressing allowed. JIT compilation substantially improves performance.

📌 Common Issue: Overflowing registers — pay attention to function size and optimization strategies.

✨ Performance Tips: Minimize stack usage, utilize registers effectively for intermediate result storage.

4. Supervisors and Fault-Tolerance: Let It Crash! 💥

In typical systems, a failing process means disaster. In BEAM, however, this event aligns with the development philosophy.

Consider electrical networks: A vast grid where one substation breaks down. Normally, entire neighborhoods lose power. In BEAM, automated switches disconnect the faulty element and reconnect reserve units instantly, preserving normalcy throughout the city.

Supervisors form hierarchical structures. When child processes crash, parent supervisors decide whether to restart affected components individually or collectively.

Such architecture guarantees automatic restoration of system integrity.

Mechanisms involved: tree-structured supervision, one-for-one strategy, state monitoring (running, garbage collection).

📌 Common Issue: Ignoring supervisor role, opting for custom solutions instead of proven OTP libraries.

✨ Developer Advice: Design applications tolerant of errors, leave failure-handling logic to specialized supervisor mechanisms.

5. Dynamic Code Loading and Distributed Systems 🌍

BEAM allows live updates to running applications. Similar to a musician changing instruments mid-performance invisibly to listeners.

Two module versions reside simultaneously: Old handles ongoing requests, new accepts fresh ones. Updates occur transparently without stopping the application.
Code Replacement: Achieved via command :code.load_file(Module). Follow proper update rules to avoid disruptions.
Distribution: Check remote node availability using net_adm:ping(Node), leverage Mnesia database. Clustering examples exist in Kubernetes environments utilizing BEAM-powered virtual machines.
Scaling: Utilize OTP tools for cluster-wide node monitoring.

6. Scalability: BEAM Network Across Thousands of Nodes 🌐

BEAM isn't merely a standalone node but a connected network behaving as a unified whole. Individual network members interact seamlessly, forming a coherent distributed infrastructure.

Key benefits of this approach:

Deploy clusters spanning multiple servers, enabling transparent communication between processes.
Particularly beneficial in IoT systems and microservices architectures, where message delivery automatically distributes across appropriate servers.

📖 Real-world Case Study: Pinterest applied this technology to deliver notifications. As traffic grew, adding extra servers scaled the system effortlessly.

BEAM in 2025: Why Should You Pay Attention? 🚀

Handling Massive Traffic: WhatsApp manages millions of simultaneous connections.
Scalable Microservices: Effortless deployment and management in Kubernetes.
Real-time Operations: Phoenix provides lightning-fast chat communications.
Reliability and Resilience: Proven in big players like Klarna.
IoT and AI: Nerves for IoT devices, TensorFlow compatibility via port mechanisms.
Future Development: Enhanced performance through JIT compilation, WebAssembly support for web apps.

📖 Success Story: Pinterest reduced notification delay by 50%, leveraging BEAM.

BEAM — The Future That's Already Here! 🌌

As we stand in 2025, Elixir and Erlang occupy niche positions among commonly used development tools, drawing little public attention. Personally, I believe this situation is unfair given the truly amazing and innovative possibilities offered by these technologies. Despite the learning curve and project complexity, the rewards promise to be substantial!

Embrace the world of Elixir/Erlang, launch a new project, and experience the true power of the BEAM virtual machine! ✨

Final Note from the Author

Thank you very much for taking interest in this article! Hopefully, it helped clarify what BEAM is and why it's so widely adopted. Initially, I planned to write something more advanced and filled with technical details, but realized I'd struggle to top the comprehensive guide provided in the book The BEAM Book: Understanding the Erlang Runtime System. Thus, I've opted for a simpler explanation.

BEAM: Простыми словами

Artyom Molchanov — Thu, 25 Sep 2025 06:58:34 +0000

Представьте вселенную, где ежесекундно происходят миллиарды сообщений, звонков и финансовых операций. Каждое послание достигает адресата, звонки продолжаются бесперебойно, а средства поступают моментально. Что обеспечивает такую безупречную работу? Нет, это не волшебство, а именно виртуальные машины — незаметные герои цифровой инфраструктуры.

Среди них есть одна выдающаяся машина — BEAM. Созданная еще в прошлом веке, она выглядит как разработка из далекого будущего. Именно она поддерживает стабильную работу таких гигантов, как WhatsApp, Discord, финансовые сервисы и IoT системы. Даже спустя десятилетия после своего появления, BEAM продолжает поражать своей производительностью и надежностью.

Цель этой статьи вовсе не в подробном погружении в механизмы работы BEAM и внутренние детали реализации. Здесь мы не будем разбираться, куда уходят байты или приводить конкретные внутренние фрагменты кода. Эта статья предназначена лишь для общего понимания сути технологии, её назначения и возможностей, полезных для вас и вашего бизнеса в условиях больших нагрузок. Для тех, кто желает глубже изучить внутреннее устройство BEAM, рекомендую книгу — The BEAM Book: Understanding the Erlang Runtime System на английском языке. (А вот русскоязычная версия вскоре появится в моём телеграм-канале)

Сегодня, когда эпоха характеризуется бурным развитием технологий реального времени, искусственного интеллекта и массового параллельного подключения пользователей, BEAM выделяется своей способностью обеспечивать высокую скорость отклика, надежность даже при отказах и быструю адаптацию к росту нагрузки, превращаясь в оптимальное решение для сложных задач. Но, начнём с основ!

Что такое виртуальная машина? 🤔

Представь себе написание программы, которую ты хочешь запустить абсолютно на всём — будь то ноутбук, смартфон, сервер или даже умная колонка. Как добиться совместимости с разными операционными системами и железом? Решение простое — использовать виртуальную машину (ВМ). Она представляет собой специальную среду выполнения, которая интерпретирует твой код, действуя как мостик между твоим приложением и конкретным устройством. ВМ берет промежуточный код (например, байт-код Java) и преобразует его в инструкции, подходящие именно этой платформе, освобождая тебя от забот о деталях работы памяти или многопоточности. Проще говоря, виртуальная машина — это своего рода универсальный переходник, позволяющий твоему коду запускаться повсеместно!

Кроме того, виртуальные машины часто имеют полезные инструменты, такие как автоматический сборщик мусора, встроенные оптимизации производительности и средства защиты данных. Благодаря этому разработка приложений становится значительно легче и эффективнее. Без ВМ создание современных проектов, начиная от мобильных игр и заканчивая крупными облачными сервисами, было бы намного сложнее.

Зачем нужны виртуальные машины? 🌟

Виртуальные машины — это не просто комфорт разработчиков, а мощный инструмент для создания универсальных, надежных и легко расширяемых решений. Рассмотрим основные преимущества виртуальных машин на понятных примерах:

Кроссплатформенность 📱💻

Написал код один раз — работает везде. Например, банковское приложение на Java запускается на сервере банка и на Android-смартфоне клиента благодаря JVM. Это экономит время и ресурсы, особенно в enterprise-разработке, где команды работают с разными платформами.
Управление ресурсами 🧹

Виртуальная машина берет на себя контроль над оперативной памятью (например, посредством сборки мусора), многопоточностью и взаимодействием с техникой. Так, в VM Erlang (BEAM) каждому процессу выделяется отдельная область памяти, что позволяет избежать проблем с утечками даже при падении отдельных процессов. Такая архитектура снижает риск возникновения багов и существенно облегчает написание кода, поскольку разработчикам больше не приходится самостоятельно заботиться о выделении и освобождении памяти.
Безопасность 🔒

За счет изоляции исполняемого кода от операционной системы, виртуальные машины создают своего рода песочницу, защищающую систему от потенциально опасных действий программы. Эта функция незаменима в облаках вроде AWS Lambda или Google Cloud Functions, где на одной машине одновременно выполняются тысячи фрагментов кода от разных пользователей.
Оптимизация ⚡

Многие виртуальные машины способны динамически оптимизировать исполнение программного кода прямо во время работы приложения. Яркий пример — механизм Just-in-time компиляции (JIT). Именно благодаря ему браузерные движки типа V8 делают JavaScript невероятно быстрым, а среда BEAM начиная с версии OTP 24 заметно повышает производительность при помощи собственного механизма JIT. Такие технологии полезны там, где программа многократно повторяется, как, например, в высоконагруженных веб-приложениях.
Поддержка сложных систем 🌐

Некоторые виртуальные машины специально спроектированы для обеспечения конкурентности, распределения нагрузки и устойчивости к сбоям. Так, сервера популярной игры League of Legends основаны именно на BEAM, что позволяет эффективно обрабатывать миллионы одновременных подключений игроков с минимальными задержками и высоким уровнем надежности.

Таким образом, виртуальные машины помогают разработчикам сосредоточиться непосредственно на создании функциональности продукта, а не на низкоуровневых технических аспектах, ускоряя процессы разработки и снижая расходы.

Популярные виртуальные машины: Кто есть? 🦸‍♂️

JVM (Java Virtual Machine): Используется для Java, Kotlin, Scala. Отлично подходит для крупных бизнес-систем (например, банковские решения), веб-серверов (Spring Framework) и платформ Android.

Преимущества: обширная инфраструктура (огромное количество готовых библиотек), технология Just-In-Time компиляции.
Недостатки: большие начальные затраты оперативной памяти и сравнительно долгий запуск приложений.
Факт: Решение применяется в большинстве (около 90%) крупнейших мировых корпораций (Fortune 500).

V8 (JavaScript Engine): Основана в Node.js и современных браузерах. Оптимизировано для работы в веб-пространстве.

Преимущества: высокая производительность для клиентской части сайта.
Недостаток: плохо приспособлена для долговременных серверных решений, где преимущество на стороне BEAM.

CLR (.NET Common Language Runtime): Поддерживает языки семейства .NET, включая C#. Хорошо интегрируется с технологиями от Microsoft (например Azure).

Преимущества: тесная совместимость с Windows-платформой.
Недостаток: ограниченная кросс-платформенность по сравнению с JVM.

BEAM (Erlang VM): Работает с языками Erlang, Elixir, LFE. Лучше всего справляется с высоко нагруженными системами, ориентированными на масштабируемость, устойчивость и параллельность обработки запросов. Прекрасно подходит для мессенджеров, телекоммуникационных сервисов и финансовых технологий.

Преимущества: поддерживает миллионы параллельных процессов одновременно, минимизирует задержки выполнения операций.
Недостаток: меньший объем библиотеки инструментов и фреймворков, хотя активно развивается (например Phoenix, Nerves).

Сравнение в таблице:

ВМ	Сильные стороны	Слабые стороны	Применение
JVM	Универсальность, экосистема	Память, запуск	Enterprise, Android
V8	Скорость для веб	Не для серверов	Node.js, браузеры
CLR	Интеграция с Microsoft	Привязка к экосистеме	.NET, Azure
BEAM	Конкурентность, отказоустойчивость	Экосистема, численные расчёты	Реальное время, телеком

В 2025 году, с ростом IoT и стриминга данных, BEAM особенно актуальна для реального времени.

Подробнее о BEAM 🌌

BEAM представляет собой виртуальную машину, предназначенную для работы с языками программирования Erlang, Elixir и рядом других (например, LFE, Alpaca). Изначально она была создана в 1990-е годы в компании Ericsson специально для телекоммуникаций, где крайне важны устойчивость к сбоям и способность выдерживать огромные нагрузки. Сейчас BEAM лежит в основе многих высоконагруженных сервисов: она обслуживает миллиарды сообщений ежедневно (как WhatsApp), поддерживает миллионы пользователей онлайн-игр одновременно (например, продукты Riot Games) и обеспечивает бесперебойную работу чат-сервисов реального времени (таких как Discord). В условиях современного мира, где критически важными становятся высокая производительность, минимальное время отклика и надежность, в 2025 году BEAM демонстрирует свою незаменимость сильнее, чем когда бы то ни было ранее.

История BEAM: От телекома к глобальным платформам 📜

Изначально аббревиатура BEAM расшифровывалась как «Bogdan’s Erlang Abstract Machine» в честь Богумила "Богдана" Хаусмана, который создал первую её версию. Однако сейчас название часто связывают с именем другого автора — «Björn’s Erlang Abstract Machine», поскольку именно Бьёрн Густавссон разработал и поддерживает актуальную реализацию. Оба специалиста внесли значительный вклад в развитие системы, трудясь в компании Ericsson.

До появления BEAM существовала другая виртуальная машина — JAM (Joe’s Abstract Machine), ставшая первым интерпретатором языка программирования Erlang. Она была создана Джо Армстронгом совместно с Майком Уильямсом на языке C (подробности можно найти в блоге разработчиков).

Поэтому Богумил («Богдан») Хаусман создал TEAM (Турбо-Эрланг-Абстрактную-машину). Она компилировала код Эрланга в Си-код, который затем компилировался в нативный код с помощью GCC.

На сегодняшний день BEAM активно применяется в финансовом секторе (например, Klarna), рекламной индустрии (AdRoll), системах уведомлений (Pinterest) и сфере Интернета вещей (Nerves). Благодаря внедрению технологии Just-In-Time компилятора в версии OTP 24 и развитию языка Elixir до уровня 1.15+, включающего улучшение работы с типизацией, BEAM продолжает оставаться актуальным решением. В будущем планируется ещё большее сближение с технологией WebAssembly для поддержки веб-приложений.

Почему BEAM — это круто? 🚀

BEAM отличается от прочих виртуальных машин своими уникальными характеристиками, особенно полезными для масштабируемых и нагруженных приложений. Рассмотрим основные преимущества вместе с конкретными примерами, цифрами и сравнением с аналогичными решениями:

Быстрые и лёгкие процессы ⚡
Создание процессов в BEAM занимает всего несколько микросекунд, занимая около ~2.5 КБ оперативной памяти каждый процесс, что позволяет одновременно запустить миллионы экземпляров на одной машине. В отличие от потоков Java Virtual Machine, потребляющих целые мегабайты памяти.

🧠 Асинхронные задачи в Rust также легковесны, однако BEAM значительно удобнее для построения распределённых решений благодаря встроенной модели акторов, изолированные процессы с минимальными накладными расходами, автоматическую отказоустойчивость через супервизоры и горячую замену кода без остановки системы.
Модель акторов 🎭
Процессы здесь ведут себя как самостоятельные акторы, обменивающиеся сообщениями друг с другом без общих ресурсов и блокировки. Это значительно упрощает работу по сравнению с потоками Java Virtual Machine. Например, представим себе мессенджер вроде Discord, где каждая отдельная комната чата функционирует как независимый процесс, свободно принимающий новые сообщения независимо от других процессов. Производительность впечатляет: виртуальная машина BEAM способна обработать около ста тысяч сообщений всего за одну секунду на одном ядре.
Философия «пусть падает» 💥
BEAM основывается на принципе «let it crash»: когда какой-либо процесс ломается, он просто прекращает свою работу. Однако, благодаря продуманному подходу, такое событие практически незаметно для пользователей. Допустим, вы управляете большим рестораном, и вдруг кто-то из сотрудников уходит посреди смены. Обычно такая ситуация привела бы к хаосу среди клиентов, но в BEAM действует своего рода супервайзер («менеджер»), который моментально запускает замену сбойного процесса новым экземпляром. И клиент продолжает получать заказ вовремя, даже не заметив заминки.

☎️ История показывает, насколько эффективна эта философия: ещё в девяностые годы прошлого века компания Ericsson использовала BEAM для поддержания работоспособности крупных телекоммуникационных станций. Если один из компонентов падал, система продолжала функционировать бесперебойно.
Горячая замена кода 🔄
Система позволяет обновлять программы, не останавливая работающую систему. BEAM держит одновременно две версии программного модуля, переключаясь между ними почти мгновенно. Для сравнения, в Java такой переход требует больше усилий и зачастую вызывает кратковременные задержки.

📖 Пример из практики: Торговая площадка Klarna, которая обновляется без единой секунды простоя, позволяя клиентам совершать покупки непрерывно.
Распределённые системы 🌐
Отдельные узлы BEAM соединяются в единую распределённую систему через сетевые соединения. Такой подход обеспечивает высокую отказоустойчивость и лёгкость горизонтального масштабирования.

📖 Пример из практики: в Pinterest тысячи новых серверов легко подключаются к существующему кластеру, увеличивая общую производительность без потери производительности отдельных частей. Масштабируемость достигает десятков тысяч узлов с минимальной задержкой обработки запросов.
Низкая задержка ⏱
За счёт инкрементальной сборки мусора BEAM сводит задержки к минимуму. Фреймворк Phoenix, построенный поверх BEAM, способен обрабатывать тысячи запросов с минимальным временем отклика, измеряемым в миллисекундах. Другие языки программирования, такие как Python, иногда испытывают длительные паузы из-за своей модели сбора мусора, тогда как BEAM уверенно справляется с большими нагрузками, сохраняя низкую задержку.
JIT-компиляция 🚀
Начиная с версии OTP 24, BEAM поддерживает технологию Just-In-Time компиляции, ускоряя выполнение интенсивных вычислительных операций примерно на 20–30%. Хотя основной фокус BEAM всё равно остаётся на параллельной обработке, новая оптимизация существенно повышает скорость выполнения ресурсоёмких задач. Например, парсинг JSON-файлов теперь выполняется заметно быстрее благодаря улучшенной оптимизации компилятором.

Внутренности BEAM: Как это работает? 🛠

1. Планировщик: Дирижёр многозадачности 🎻

Планировщик BEAM — это как дирижёр в оркестре. У него тысячи музыкантов (процессов), и каждому нужно время, чтобы сыграть свою партию. Никто не играет слишком долго — иначе музыка превратится в хаос.

📖 Пример из практики: Один сервер WhatsApp с использованием BEAM одновременно обслуживал миллионы подключений. Такое было бы невозможно реализовать через обычные потоки операционной системы, однако BEAM справляется с этой задачей благодаря своей уникальной схеме планирования процессов.

Механизм работы:

Количество планировщиков соответствует числу ядер процессора. Например, на восьмиядерном сервере действует восемь планировщиков.
Каждый процесс получает определённое количество шагов выполнения («редукций»), после чего управление передаётся другому процессу.
Процессы распределяются по двум очередям: готовых к выполнению (ready) и ожидающих ресурсов (waiting).
Реализована технология перераспределения нагрузок («краже задач») для балансировки активности.
Используется структура типа «колеса времени»: массив временных интервалов для хранения активных таймеров с целью снижения накладных расходов.

📌 Типичная ошибка: Долгие встроенные функции (BIFs), выполняемые без передачи управления, способны заблокировать работу планировщика.

2. Сборка мусора: Чистота в памяти 🧹

Сборщик мусора (GC) в среде выполнения BEAM действует подобно аккуратному дворнику, незаметно обходящему рестораны большого города BEAM и аккуратно собирающему грязную посуду, освобождая пространство на столах.

Каждый отдельный процесс имеет свою собственную зону хранения («кучу»). Когда память конкретного процесса заполняется ненужными объектами, уборка проводится именно там, не затрагивая работу остальных процессов.

BEAM применяет методику поколений (generational garbage collection): часто очищаются недавно созданные элементы («молодое поколение»), поскольку они имеют короткий срок жизни, тогда как старшие поколения проверяются гораздо реже.

📌 Типичная ошибка: длительное накопление долгоживущих объектов может привести к повышенному потреблению ресурсов, отслеживайте параметр high_water.

Объёмные двоичные данные (файлы, изображения) располагаются обособленно от основной зоны сборки мусора, предотвращая её чрезмерное заполнение.

📖 Пример из практики: Discord обслуживает миллионы активных каналов на платформе BEAM. Даже если один конкретный чат накапливает временные данные, система очистки мгновенно избавляется от них, абсолютно не влияя на производительность других чатов.

Алгоритм работы:

Стек и куча расширяются навстречу друг другу до тех пор, пока не встретятся. Тогда запускается процедура уборки.
Существуют два типа циклов сбора мусора: молодой (частый, минорный) и старый (редкий, полный).
Используется техника копирования данных между двумя зонами памяти ("from space" → "to space"), обеспечивая эффективную обработку совместно используемых элементов. Ключевые параметры мониторинга: gen_gcs, high_water.

✨ Внимательно наблюдайте за динамикой роста областей памяти ваших процессов. Быстро увеличивающиеся размеры могут свидетельствовать о наличии объектов с длительным жизненным циклом, что требует пересмотра архитектуры вашего приложения.

3. Архитектура на основе регистров: быстрее и эффективнее 🧠

Машина BEAM основана на регистровой модели работы. Регистровая машина работает через использование набора регистров — специальных быстродействующих областей памяти, предназначенных для хранения промежуточных результатов вычислений. Каждый регистр хранит определённое значение, которое участвует в операции обработки данных. Регистры позволяют быстрее обращаться к данным и обеспечивают высокую производительность выполнения операций, поскольку данные уже находятся в быстрой памяти процессора.

Примеры: Простое вычисление суммы двух чисел (add(A, B) → результат в регистрах X0 и X1).

Принцип функционирования:

Регистры X (до 1024 штук): Хранят аргументы функций.
Регистры Y: Для локальных переменных.
Используются инструкции типа move и call, поддерживается прямая адресация памяти. Технология JIT существенно повышает производительность.

📌 Типичная ошибка: Переполнение регистров — важно следить за размером функций и корректностью оптимизации.

✨ Советы по улучшению производительности: Уменьшайте использование стека, активно задействуйте регистры для хранения промежуточных значений.

4. Супервизоры и отказоустойчивость: Пусть падает! 💥

В обычной среде крах процесса означает бедствие. Но в виртуальной машине BEAM это заложено в философию разработки.

Возьмём аналогию электрической сети: Есть большая электрическая сеть. В ней одна подстанция «вырубилась». В обычном случае — весь район без света. В BEAM же стоит автоматика: неисправная подстанция отключается, а система мгновенно подключает резервную. Город даже не моргнёт лампочкой.

Супервизор формируют древовидную структуру. Когда дочерний процесс выходит из строя, узел супервизора определяет стратегию действий: восстановить лишь пострадавший элемент либо целую группу процессов разом.

Подобная архитектура обеспечивает автоматическое восстановление работоспособности всей системы.

Механизм работы: дерево супервизоров, стратегии типа one_for_one, состояния выполнения (running, сбор мусора).

📌 Типичная ошибка: игнорирование роли супервизора, использование неподходящих инструментов вроде самодельных решений вместо проверенных библиотек OTP.

✨ Советы разработчикам: пишите приложения так, чтобы ошибки были простительны, а логика обработки сбоев оставляйте специализированным механизмам супервизора.

5. Динамическая загрузка кода и распределенные системы 🌍

Платформа BEAM позволяет обновлять код прямо на лету, когда приложение активно функционирует. Подобно тому, как музыкант переключается на другой инструмент посреди выступления, абсолютно незаметно для аудитории.

В BEAM одновременно хранятся две версии каждого модуля: одна старая продолжает обрабатывать существующие запросы, другая новая принимает новые задачи. Таким образом исправляются ошибки и добавляются функции без остановок работы приложения.
Замена кода: выполняется командой :code.load_file(Module). Важно соблюдать правила обновления, иначе возможны сбои.
Распределенность: Проверяется доступность удаленных нод через команду net_adm:ping(Node), база данных поддерживается системой Mnesia. Пример реализации — кластеры в Kubernetes с использованием виртуальных машин на основе BEAM.
Масштабирование: Использование инструментов из набора OTP для мониторинга состояния узлов сети.

6. Масштабируемость: BEAM-сеть на тысячи узлов 🌐

BEAM представляет собой не единый узел, а целую взаимосвязанную сеть, функционирующую как единое целое. Каждый отдельный элемент сети способен взаимодействовать с остальными узлами так, словно они являются частью единой распределённой инфраструктуры.

Вот несколько преимуществ такой архитектуры:

Вы можете развернуть кластер из множества серверов, позволяя процессам обмениваться сообщениями между собой прозрачно и эффективно.
Особенно полезно это в системах Internet of Things (IoT) и микросервисных архитектурах, когда доставка сообщений автоматически распределяется BEAM'ом среди нужных серверов.

📖 Пример из практики: компания Pinterest применила эту технологию для отправки уведомлений своим пользователям. По мере роста нагрузки всё, что потребовалось сделать, — добавить дополнительные сервера в кластер.

BEAM в 2025 году: почему стоит обратить внимание? 🚀

Большие объёмы трафика: WhatsApp обслуживает миллионы подключений одновременно.
Масштабируемые микросервисы: простое развертывание и управление в Kubernetes.
Работа в режиме реального времени: Phoenix обеспечивает мгновенные чат-коммуникации.
Надежность и отказоустойчивость: проверена крупными финансовыми компаниями вроде Klarna.
Интернет вещей и машинное обучение: Nerves для устройств IoT и совместимость с TensorFlow через механизм портов.
Перспективы развития: оптимизация производительности благодаря JIT-компиляции и поддержка WebAssembly для веб-приложений.

📖 Пример из практики: Pinterest снизил задержку доставки уведомлений на 50% именно благодаря платформе BEAM.

BEAM — будущее, которое уже здесь! 🌌

На сегодняшний день, в 2025 году, технологии Elixir и Erlang занимают скромное место среди используемых инструментов разработки и не получают должного внимания общественности. Но лично я считаю, что такая ситуация весьма незаслуженна, потому что предлагаемые ими возможности действительно удивительны и оригинальны. Хотя путь освоения и развития проектов на этой платформе может показаться непростым, результат обещает быть потрясающим!

Откройте для себя мир Elixir/Erlang, окунитесь в разработку нового проекта и ощутите всю мощь виртуальной машины BEAM! ✨

От автора

Спасибо большое за интерес к этой статье! Надеюсь, она помогла разобраться, что представляет собой BEAM и зачем она используется. Изначально планировал сделать материал сложнее и добавить больше технических подробностей, однако понял, что вряд ли смогу превзойти книгу The BEAM Book: Understanding the Erlang Runtime System, поэтому решил изложить всё простыми словами.

Speeding up Elixir: integration with native code (NIF, Ports, etc.)

Artyom Molchanov — Wed, 21 May 2025 08:59:32 +0000

⚠️ Important: Before introducing new languages into your project, ensure that your existing Elixir code has been optimized first. In many cases, proper optimization can significantly improve application performance and sometimes yield better results than adding another programming language.

Elixir and Erlang when are excellent languages for developing scalable and fault-tolerant systems. However, there may come times when you need to extract maximum performance or utilize libraries available only in other languages. If you're facing such situations or simply want to explore how to combine two favorite programming languages, this article is for you!

🔍 Search When You Need Native Code Integration

Before diving into technical details, it's important to understand when native code integration should be considered:

1. Compute-intensive Tasks

The BEAM virtual machine excels at concurrency but isn't designed for heavy computations. Consider integrating native code if your bottleneck involves CPU-bound operations:

🧮 Mathematical Calculations—Linear algebra or matrix operations
🔐 Cryptography—Encryption/decryption of large datasets
🎨 Media Processing—Images, videos, audio
🧠 Machine Learning—Model inference, vector operations

2. Hardware Interaction

When low-level access to hardware is required:

📟 Embedded Systems—Raspberry Pi, microcontrollers (Note: While Nerves exists in Elixir, it might fall short)
🎮 Specific Drivers—Unconventional devices
📊 GPU Computing—CUDA, OpenCL

3. Reusing Existing Codebases

🏛️ Proven Libraries on C/C++
📚 Ecosystem Advantages from other languages (e.g., Python for ML)
🔧 Avoid Reinventing the Wheel

4. Profiling and Bottlenecks

Typical signs indicating it's time to consider native code:

# Before Optimization - 1000ms
defmodule SlowModule do
  def process_data(data) do
    # Potential bottleneck candidate for native optimization
    Enum.reduce(data, 0, fn x, acc -> complex_calculation(x) + acc end)
  end

  defp complex_calculation(x) do
    # Imagine CPU-heavy calculations here
    # That don't scale well within BEAM
  end
end

# Exhausted all possible optimizations in Elixir and still slow?
# Perhaps it's time to introduce native code!

Native extensions transform Elixir into an all-purpose tool where BEAM handles everything except critical computations. This opens doors to ML, hardware, video processing, and more speed-critical tasks.

Balance Comparison of Integration Methods

Choosing the right method of integration is crucial for project success. Here's a comparative table of methods with their pros and cons:

Method	Speed	BEAM Safety	Implementation Complexity	Language Support	Communication Overhead	Asynchronicity	Ideal Use Cases использования
NIF	⚡⚡⚡⚡⚡	❌ Dangerous	🔧🔧🔧 Medium	C, C++	None (direct call)	❌ Blocks scheduler	Microservices, lengthy CPU-bound tasks
Dirty NIF	⚡⚡⚡⚡	⚠️ Conditionally Safe	🔧🔧🔧 Medium	C, C++	None (direct call)	✅ Doesn't block primary scheduler	Long computational tasks (>1ms)
Port	⚡⚡	✅✅ Completely Safe	🔧 Simple	Any	High (IPC)	✅ Process isolation	Python, Go, Bash-scripts
Port Driver	⚡⚡⚡⚡	✅ Safe	🔧🔧🔧🔧 Complex	C, C++	Low	✅ Dedicated thread	Video/audio processing
gRPC	⚡⚡	✅✅ Completely Safe	🔧🔧 Medium	Any with gRPC support	Moderate (network)	✅ Separate service	Microservice architecture
Rustler	⚡⚡⚡⚡	✅ Safe	🔧🔧 Medium	Rust	None (direct call)	✅ Supports asynchronous APIs	Alternative to C NIF
Zigler	⚡⚡⚡⚡⚡	✅ Safe	🔧🔧 Medium	Zig	None (direct call)	✅ Safer than standard NIFs	Alternative to C in NIF

Visual Comparison by Key Metrics

Speed:               Safety:               Simplicity:
NIF         █████    Port        █████     Port        █████
Dirty NIF   ████     Dirty NIF   ███       gRPC        ████
Rustler     ████     Rustler     ████      Rustler     ████
Zigler      █████    Zigler      ████      Zigler      ████
Port Driver ████     Port Driver ████      NIF         ███
Port        ██       gRPC        █████     Port Driver █
gRPC        ██       NIF         █         Dirty NIF   ███

Mechanisms Behind Integration

ㅤ

🧠 NIFs — Maximal Performance

Native Implemented Functions (NIFs) offer the fastest way to integrate native code, albeit being the riskiest option. They execute directly in the BEAM scheduler's thread, ensuring lightning-fast execution due to zero overhead.

How Do NIFs Work?

Compilation: Native code (C/Rust/Zig) compiles into a dynamic library (.so, .dll)
Loading: BEAM loads the library during module startup via :erlang.load_nif/2
Direct Execution: Functions run in the same thread as the calling Elixir code

✅ Benefits

Blazing Speed: Calls take approximately 0.1–1 µs (~100–1000× faster than Ports)
Access to BEAM API: Direct interaction with Erlang terms
No Serialization: No encoding/decoding costs
Distribution: Library ships alongside the OTP app

❌ Drawbacks

Risk of VM Crash: Errors in NIF terminate the entire BEAM instance
Scheduler Blocking: Long-running NIFs freeze multithreading
Debugging Difficulty: Memory leaks hard to detect
Platform Dependency: Requires compilation per target architecture

Dirty NIFs — Safer Alternative

With Erlang/OTP 20+, we have Dirty NIFs, which execute in dedicated thread pools, allowing longer computations without blocking the BEAM scheduler.

// Defining a Dirty NIF
static ErlNifFunc nif_funcs[] = {
    {"long_computation", 1, long_computation_nif, ERL_NIF_DIRTY_CPU}
};

Tip: Use ERL_NIF_DIRTY_CPU for CPU-bound ops and ERL_NIF_DIRTY_IO for I/O-bound ones

🔌 Ports — Complete Isolation

Ports provide a safe mechanism for interacting with external programs through standard I/O streams (stdin/stdout). It's the safest form of integration since the external program runs in its own OS process.

How Do Ports Work?

Launch: Elixir spawns an external program as a separate OS process
Communication: Data exchange occurs over stdin/stdout
Isolation: Failure of the external program doesn't affect BEAM

✅ Benefits

Full Safety: Isolation ensures BEAM stability
Language Agnosticism: Works with any programming language
Ease of Debugging: External program can be tested independently
Dependency-Free: No specific BEAM-compatible libraries needed

❌ Downsides

High Overheads: Approximately 100–500 µs per invocation
Serialization Required: Needs conversion of data (usually to JSON)
Blocking Calls: By default blocks the caller process

🚗 Port Drivers — Goldilocks Zone

Port Drivers are high-performance alternatives to Ports, though they require greater complexity. These drivers are written in C and embedded directly into BEAM’s address space, running in separate threads.

How Do Port Drivers Work?

Load: BEAM loads the C library into its memory space
Thread Allocation: Each driver operates in its own thread
Asynchronous Operation: Data exchanges occur via message queues

✅ Benefits

Performance: Significantly faster than regular ports
Safety: Lower risk compared to NIFs
Async Capability: Non-blocking operation supported
Convenience: No need to spawn additional processes

❌ Disadvantages

Complexity: Requires knowledge of Erlang C API
Limited Scope: Only works with C/C++
Less Documentation: Few examples and guides available

🐊 Zigler — Wrapper Around NIFs for Zig

Zigler is a library enabling writing native extensions using the Zig programming language. It integrates the Zig compiler directly into the Elixir compilation cycle, allowing direct coding in Zig inside Elixir modules.

✅ Benefits

Minimal overhead for native calls
Memory safety without garbage collection
Direct access to low-level operations
Simpler compilation compared to other native extensions
Hot reloading capability

❌ Disadvantages

Zig is relatively young with a smaller community
Higher entry barrier for Elixir developers
Limited ecosystem of libraries compared to Rust

🦀 Rustler — Wrapping NIFs for Rust

Rustler is a library for creating native extensions in Erlang/Elixir using Rust. It provides a safe binding between Rust and Erlang/Elixir, facilitating writing NIFs in Rust.

✅ Benefits

Memory safety enforced at compile-time
High performance for computationally intensive tasks
Rich ecosystem of Rust packages (crates)
Protection against crashes in native code (protects BEAM from crashing)
Parallel execution without blocking the BEAM scheduler

❌ Disadvantages

Complicated build process and dependency management
Requires familiarity with two different programming paradigms
Possible compatibility issues across versions
Potential bottlenecks at runtime boundaries

🌐 Global gRPC and Similar Protocols

For more advanced scenarios involving external services, especially in microservice architectures, protocols like gRPC provide structured and scalable ways of integration.

✅ gRPC Benefits for Elixir

Contract Schema: Strong typing via Protocol Buffers
Bidirectional Streaming: Supports streaming both ways
Cross-platform: Supports multiple languages
Performance: More efficient than REST/JSON

❗️ An example using gRPC was omitted due to its extensive nature. For detailed info about gRPC in Elixir, see elixir-grpc.

🧪 Practical Examples of Integration

📚 The goal of this article is to give an overview of available native integration methods. Deep implementations and edge cases are omitted to maintain balance between theory and practical application.

Exploring Criteria for Choosing Integration Methods

Before moving onto examples, let's define key factors influencing our choice:

Performance: How fast does the call execute?
Safety: Risk level for BEAM stability
Implementation Complexity: Ease of implementation
Language Support: Suitability of the chosen language with BEAM

⚙️ C — Maximum Performance Using NIF and Port Drivers

Optimal Methods:

NIF — for instantaneous operations (<1ms)
Port Drivers — for long-lasting or async tasks

Why Choose This Approach?
C offers seamless compatibility with BEAM, making it ideal for:

Critically performant tasks
Low-level operations (hardware, GPU)
Integrating pre-existing C libraries

Example 1: Fast NIF for Hashing (Best Suited for C)

// hash_nif.c
#include <erl_nif.h>
#include <openssl/sha.h>

static ERL_NIF_TERM sha256_nif(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) {
    ErlNifBinary input;
    if (!enif_inspect_binary(env, argv[0], &input)) {
        return enif_make_badarg(env);
    }

    unsigned char hash[SHA256_DIGEST_LENGTH];
    SHA256(input.data, input.size, hash);

    ErlNifBinary output;
    enif_alloc_binary(SHA256_DIGEST_LENGTH, &output);
    memcpy(output.data, hash, SHA256_DIGEST_LENGTH);

    return enif_make_binary(env, &output);
}

static ErlNifFunc nif_funcs[] = {
    {"sha256", 1, sha256_nif}
};

ERL_NIF_INIT(Elixir.CryptoNif, nif_funcs, NULL, NULL, NULL, NULL)

Elixir Part:

defmodule CryptoNif do
  @on_load :load_nif
  def load_nif do
    :erlang.load_nif(Path.expand("./hash_nif"), 0)
  end

  def sha256(_data), do: raise "NIF not loaded!"
end

Compiling C Source:
You'll need the OpenSSL library installed:

# For Ubuntu/Debian
sudo apt-get install libssl-dev

# For CentOS/RHEL
sudo yum install openssl-devel

# For macOS (with Homebrew)
brew install openssl
Compile the C source:


gcc -shared -fPIC -o hash_nif.so hash_nif.c \
  -I /usr/lib/erlang/erts-15.2.7/include \ # Path depends on your system
  -I /usr/include/openssl \
  -L /usr/lib/openssl \
  -lssl -lcrypto

Result:

iex(1)> CryptoNif.sha256("test")
<<159, 134, 208, 129, 136, 76, 125, 101, 154, 47, 234, 160, 197, 90, 208, 21, 163, 191, 79, 27, 43, 11, 130, 44, 209, 93, 108, 21, 176, 240, 10, 8>>

Example 2: Port Driver for String Reversal

// reverse_driver.c
#include "erl_driver.h"
#include <string.h>

typedef struct {
    ErlDrvPort port;
} DriverData;

static void reverse_and_send(ErlDrvData drv_data, char* buf, ErlDrvSizeT len) {
    DriverData* d = (DriverData*)drv_data;

    for (ErlDrvSizeT i = 0; i < len / 2; i++) {
        char temp = buf[i];
        buf[i] = buf[len - 1 - i];
        buf[len - 1 - i] = temp;
    }

    driver_output(d->port, buf, len);
}

static ErlDrvData driver_start(ErlDrvPort port, char* command) {
    DriverData* d = (DriverData*)driver_alloc(sizeof(DriverData));
    d->port = port;
    return (ErlDrvData)d;
}

static void driver_stop(ErlDrvData drv_data) {
    DriverData* d = (DriverData*)drv_data;
    driver_free(d);
}

static ErlDrvEntry driver_entry = {
    .init = NULL,
    .start = driver_start,
    .stop = driver_stop,
    .output = reverse_and_send,
    .ready_input = NULL,
    .ready_output = NULL,
    .driver_name = "reverse_driver",
    .finish = NULL,
    .handle = NULL,
    .control = NULL,
    .timeout = NULL,
    .outputv = NULL,
    .ready_async = NULL,
    .flush = NULL,
    .call = NULL,
    .extended_marker = ERL_DRV_EXTENDED_MARKER,
    .major_version = ERL_DRV_EXTENDED_MAJOR_VERSION,
    .minor_version = ERL_DRV_EXTENDED_MINOR_VERSION,
    .driver_flags = 0,
    .handle2 = NULL,
    .process_exit = NULL,
    .stop_select = NULL
};


DRIVER_INIT(reverse_driver) {
    return &driver_entry;
}

Elixir Part:

defmodule ReverseString do
  def start() do
    :ok = :erl_ddll.load_driver('./', 'reverse_driver')
    Port.open({:spawn, 'reverse_driver'}, [:binary])
  end

  def reverse(port, string) when is_binary(string) do
    true = Port.command(port, string)
    receive do
      {^port, {:data, result}} -> result
    after
      1000 -> {:error, :timeout}
    end
  end

  def stop(port) do
    Port.close(port)
  end
end

Compiling C Source:

gcc -std=gnu99 -shared -fPIC -o reverse_driver.so reverse_driver.c \
    -I/usr/lib/erlang/erts-15.2.7/include/ # Path depends on your system

Result:

iex(1)> port = ReverseString.start
#Port<0.6>
iex(2)> ReverseString.reverse(port, "hello")
"olleh"

🦀 Rustler — Security and Performance with Rustler

Optimal Method: Rustler (specialized wrapper for NIF)

Why Rustler?

Full memory safety
Convenient macros for working with BEAM terms
Automatic error handling
Async task support

Example: Parallel Data Processing

Add Rustler to mix.exs (Current version is 0.36.1):

  defp deps do
    [
      {:rustler, "~> 0.36.1"}
    ]
  end

Create Rust Project Inside Elixir:

mix deps.get
mix rustler.new

This is the name of the Elixir module the NIF module will be registered to.
Module name > RustUtils
This is the name used for the generated Rust crate. The default is most likely fine.
Library name (rustutils) > (Enter)

// lib.rs
use rayon::prelude::*;

#[rustler::nif]
fn parallel_double(input: Vec<i64>) -> Vec<i64> {
    input.par_iter().map(|&x| x * 2).collect()
}

rustler::init!("Elixir.RustUtils");

Elixir Part:

defmodule RustUtils do
  use Rustler, otp_app: :rust_utils, crate: "rustutils"

  def parallel_double(_list), do: :erlang.nif_error(:not_loaded)
end

Result:

RustUtils.parallel_double([1, 2, 3])
# => [2, 4, 6]

3. 🐍 Python — Effortless Integration Through Ports

Optimal Method: Ports

Why Ports?

Total process isolation
Easy debugging
Access to Python ecosystem
Handles long operations (like ML models)

Example: Creating Your Own Model and Integrating TensorFlow

Build the Model:

# create_model.py
import tensorflow as tf
import numpy as np

model = tf.keras.Sequential([
    tf.keras.layers.Dense(1, input_shape=(3,), use_bias=False)
])

model.set_weights([np.array([[1.0], [1.0], [1.0]])])

model.save("my_model.h5")
print("✅ Model saved to my_model.h5")

#tensorflow_port.py
import sys
import json
import numpy as np
import tensorflow as tf
import os

os.environ['TF_CPP_MIN_LOG_LEVEL'] = '3'
tf.get_logger().setLevel('ERROR')

model = tf.keras.models.load_model('my_model.h5')

def predict(data):
    try:
        if isinstance(data, str):
            data = json.loads(data)

        input_array = np.array(data, dtype=np.float32).reshape(1, 3)
        prediction = model.predict(input_array)
        return json.dumps({"status": "success", "result": prediction.tolist()})
    except Exception as e:
        return json.dumps({"status": "error", "message": str(e)})

if __name__ == "__main__":
    for line in sys.stdin:
        line = line.strip()
        if not line:
            continue

        try:
            response = predict(line)
            sys.stdout.write(response + "\n")
            sys.stdout.flush()
        except Exception as e:
            error = json.dumps({"status": "error", "message": str(e)})
            sys.stdout.write(error + "\n")
            sys.stdout.flush()

Elixir Part:

defmodule TensorflowPort do
  @timeout 5_000

  def start do
    Port.open(
      {:spawn, "python3 tensorflow_port.py"},
      [:binary, :use_stdio, :exit_status, :stderr_to_stdout, {:line, 1024}]
    )
  end

  def predict(port, input_data) do
    input_data
    |> Jason.encode!()
    |> then(&Port.command(port, &1 <> "\n"))

    wait_for_response(port)
  end

  defp wait_for_response(port) do
    receive do
      {^port, {:data, {:eol, line}}} ->
        case Jason.decode(line) do
          {:ok, %{"status" => "success", "result" => result}} -> {:ok, result}
          {:ok, %{"status" => "error", "message" => msg}} -> {:error, msg}
          _ -> wait_for_response(port)
        end

      {^port, {:exit_status, status}} ->
        {:error, "Python process exited with status #{status}"}
    after
      @timeout -> {:error, :timeout}
    end
  end
end

Result:

To run the script, enter the Python environment and launch iex -S mix.

(venv)
iex(1)> port = TensorflowPort.start
#Port<0.10>
iex(2)> TensorflowPort.predict(port, [1,2,3])
{:ok, [[6.0]]}

4. 🦫 Go — Efficiency Through CGO or gRPC

Optimal Methods:

CGO wrappers for NIF — best for max performance
gRPC — suitable for complex interactions and microservices

CGO Wrapper for Go Code (Suitable for Performance)

// fib.go
package main

import "C"

func GoFib(n C.int) C.int {
    a, b := 0, 1
    for i := 0; i < int(n); i++ {
        a, b = b, a+b
    }
    return C.int(a)
}

func main() {}

C Wrapper:

// c_src/go_nif.c
#include <erl_nif.h>
#include "libfib.h"

static ERL_NIF_TERM go_fib_nif(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) {
    int n;
    if (!enif_get_int(env, argv[0], &n)) {
        return enif_make_badarg(env);
    }
    return enif_make_int(env, GoFib(n));
}

static ErlNifFunc nif_funcs[] = {
    {"go_fib", 1, go_fib_nif}
};

ERL_NIF_INIT(Elixir.NifGo, nif_funcs, NULL, NULL, NULL, NULL)

Elixir part:

defmodule NifGo do
  @on_load :load_nif

  def load_nif do
    nif_path = Path.expand("priv/go_nif", File.cwd!())

    # Preload Go library
    :erlang.load_nif(Path.expand("priv/libfib", File.cwd!()), 0)

    # Load main NIF library
    :erlang.load_nif(nif_path, 0)
  end

  def go_fib(_n), do: raise("NIF not loaded!")
end

Compile:

go build -buildmode=c-shared -o priv/libfib.so fib.go

gcc -shared -fPIC \
    -I/usr/lib/erlang/erts-15.2.7/include/ \ # Path varies based on your system
    -I./priv \
    -o priv/go_nif.so \
    c_src/go_nif.c \
    ./priv/libfib.so \
    -Wl,-rpath,'$ORIGIN'

LD_LIBRARY_PATH=./priv iex -S mix

Run:

iex(1)> NifGo.go_fib(3)
2

⚠️ If you'd rather avoid dealing with CGO, opt for gRPC or Ports instead. They're safer, although slower.

5. 🐊 Zig — Integration Via Zigler

Optimal Method: Zigler (wrapper for Zig-based NIFs)

Why Zigler?

Minimum overhead for native calls
Memory safety without garbage collection
Direct access to low-level operations
Simplified compilation relative to other native extensions
Hot-reloading capabilities

Example: Quick Binary Data Handling

Add Zigler to mix.exs:

def deps do
  [
    {:zigler, "~> 0.13.2", runtime: false}
  ]
end

lib/nif_zig.ex:

defmodule NifZig do
  use Zig, otp_app: :zigler

  ~Z"""
  pub fn string_count(string: []u8) i64 {
    return @intCast(string.len);
  }

  pub fn list_sum(array: []f64) f64 {
    var sum: f64 = 0.0;
    for(array) | item | {
      sum += item;
    }
    return sum;
  }
  """
end

Result:

iex(3)> NifZig.string_count("hello")
5
iex(4)> NifZig.list_sum([1.2,2.3,3.4,4.5])
11.4

Language	Optimal Method	Alternatives	When To Use
C	NIF, Port Drivers	Ports	Maximum performance
Rust	Rustler (NIF)	-	Safety + performance
Python	Ports	gRPC	Integration with ML/scientific tools
Go	C-обёртки (NIF), gRPC	Ports	Leveraging Go ecosystem
Zig	Zigler (NIF)	-	Modern alternative to C

Final Thoughts

Integrating Elixir with native code unlocks new possibilities for developers, combining BEAM's strengths (scalability, reliability) with the performance and libraries of other languages. We've explored various integration techniques: NIF, Dirty NIF, Ports, Port Drivers, Rustler, Zigler, and gRPC, along with their optimal usage scenarios.

Remember, choosing an integration method should align with your project's requirements regarding performance, security, and ease of development.

Author's Notes

Thank you for reading this article! I hope you've found it insightful learning about ways to integrate other languages into Elixir. Among these options, I found Port Drivers particularly challenging, as crafting one turned out to be quite an adventure, requiring hours of trial-and-error to find the correct approach. Overall, however, integrating other languages into Elixir proved neither difficult nor boring—it was actually fun!

If you spot inaccuracies or have interesting additions, please share them in the comments section. Constructive feedback is always appreciated 😎