DEV Community: Sina Rezaei

Beyond Fat Controllers: Using the Facade Pattern in Ruby on Rails

Sina Rezaei — Mon, 12 Oct 2026 07:59:34 +0000

A Rails controller often starts small. A user selects a subscription plan, the application processes a payment, and the subscription becomes active.

Then the requirements grow. You need to handle failed payments, prevent duplicate charges, activate features, and deal with external services that occasionally fail.

Moving each operation into a service object helps, but the controller may still be responsible for coordinating all those services.

The Facade pattern offers a cleaner approach: expose one entry point for a complex workflow while keeping its individual responsibilities separate.

From a Fat Controller to a Facade

Consider a subscription checkout that involves payment processing, subscription activation, and feature provisioning.

class SubscriptionsController < ApplicationController
  def create
    plan = Plan.find(params[:plan_id])

    payment = PaymentProcessor.call(
      user: current_user,
      plan: plan
    )

    if payment.succeeded?
      subscription = current_user.subscriptions.create!(
        plan: plan,
        status: "active"
      )

      FeatureProvisioner.call(subscription)

      redirect_to subscription_path(subscription)
    else
      redirect_to plans_path, alert: "Payment failed"
    end
  end
end

The problem isn't the number of lines. The controller knows too much about the workflow: which operation runs first, what depends on payment success, and what happens next.

As the feature evolves, more conditions and failure scenarios end up in the same action.

Introducing the Facade

We can move that coordination into a dedicated class:

class SubscriptionActivation
  def initialize(
    payment_processor: PaymentProcessor.new,
    subscription_activator: SubscriptionActivator.new,
    feature_provisioner: FeatureProvisioner.new
  )
    @payment_processor = payment_processor
    @subscription_activator = subscription_activator
    @feature_provisioner = feature_provisioner
  end

  def call(user:, plan:, idempotency_key:)
    payment = @payment_processor.call(
      user: user,
      plan: plan,
      idempotency_key: idempotency_key
    )

    return ActivationResult.failure(:payment_failed) unless
      payment.succeeded?

    subscription = @subscription_activator.call(
      user: user,
      plan: plan,
      payment: payment
    )

    @feature_provisioner.call(subscription)

    ActivationResult.success(subscription)
  end
end

The Facade coordinates the workflow without implementing every operation itself. Payment processing, subscription activation, and feature provisioning remain separate responsibilities.

Dependency injection also makes testing easier because each collaborator can be replaced with a test double.

The controller now has a simpler job:

class SubscriptionsController < ApplicationController
  def create
    plan = Plan.find(params[:plan_id])

    result = SubscriptionActivation.new.call(
      user: current_user,
      plan: plan,
      idempotency_key: checkout_attempt.idempotency_key
    )

    if result.success?
      redirect_to subscription_path(result.subscription)
    else
      redirect_to plans_path, alert: "Unable to activate subscription"
    end
  end
end

Here, checkout_attempt represents a persisted checkout attempt whose idempotency key is reused on retries. The result objects and supporting services are application-specific, not built-in Rails classes.

The Detail That Matters: Failure Handling

A Facade organizes a workflow, but it doesn't automatically make that workflow reliable.

Imagine the payment provider confirms a charge, but the database update fails. A database rollback cannot undo a charge made by an external service.

Retries create another risk. If a customer submits checkout twice, the application must avoid charging them twice for the same attempt.

Use a stable idempotency key for payment requests. Stripe documents how idempotent requests help prevent duplicate operations when requests are retried.

External side effects also need careful handling. If feature provisioning happens through another service, a failed request may require a retry or reconciliation process. For workflows where losing an event is unacceptable, a transactional outbox can help ensure that database changes and the corresponding event are recorded together.

These mechanisms solve different problems. The Facade coordinates the steps; idempotency and reliable event delivery protect the workflow when things go wrong.

Testing the Workflow

A useful Facade test verifies the order and conditions of the operations, rather than testing the internals of every collaborator again.

For example, a declined payment should prevent subscription activation:

RSpec.describe SubscriptionActivation do
  it "does not activate a subscription after payment fails" do
    payment_processor = instance_double(PaymentProcessor)
    activator = instance_double(SubscriptionActivator)
    provisioner = instance_double(FeatureProvisioner)

    allow(payment_processor)
      .to receive(:call)
      .and_return(
        instance_double(
          PaymentResult,
          succeeded?: false
        )
      )

    facade = described_class.new(
      payment_processor: payment_processor,
      subscription_activator: activator,
      feature_provisioner: provisioner
    )

    facade.call(
      user: build_stubbed(:user),
      plan: build_stubbed(:plan),
      idempotency_key: "checkout_123"
    )

    expect(activator).not_to have_received(:call)
    expect(provisioner).not_to have_received(:call)
  end
end

This example assumes the application's result objects and test factories are defined accordingly.

When Should You Use a Facade?

A Facade is useful when a single business operation requires several components to work together and callers shouldn't need to know the sequence.

It isn't necessary for every controller action. If an operation is simple, adding another class can create unnecessary indirection. And if the Facade starts implementing every business rule itself, it may simply become another oversized object.

Keep the distinction clear:

Controller: handles the HTTP request and response.
Facade: coordinates the workflow.
Collaborating services: implement their own responsibilities.

The goal isn't to create more classes. It's to make a complicated operation easier to understand, test, and change without spreading its coordination logic throughout the application.

AI Should Propose. Systems Should Verify.

Sina Rezaei — Wed, 07 Oct 2026 05:44:22 +0000

AI Should Propose. Systems Should Verify.

An AI agent can produce the correct action and still have no authority to execute it.

That distinction becomes critical when agents move beyond generating text and start modifying code, calling APIs, changing infrastructure, triggering workflows, or coordinating other agents.

The question is no longer only:

Can the model determine what should happen?

It is also:

What happens between the action the model proposes and the action the system actually executes?

A useful starting point is:

AI proposes. Systems verify. Infrastructure executes.

The Problem With Direct Execution

Consider an AI coding agent working inside a production environment.

The agent receives a task:

Fix the authentication bug and deploy the change.

It analyzes the repository, modifies the code, runs tests, and produces a deployment command.

The code may be correct.

The tests may pass.

The deployment command may be valid.

None of those facts automatically mean the agent should be allowed to deploy to production.

This is the difference between correctness and authority.

A model can correctly determine what should happen while still being unauthorized to perform that action.

If the same component controls reasoning, authorization, and execution, the trust boundary becomes extremely large:

AI decides what to do → AI decides whether it may do it → AI executes it

A safer architecture separates those responsibilities.

Put a Boundary Between Reasoning and Execution

Instead of allowing the model to directly invoke sensitive infrastructure, treat its output as a proposed action.

User Intent
    ↓
AI Agent
    ↓
Proposed Action
    ↓
System Validation
    ↓
Policy Check
    ↓
Execution
    ↓
Post-Execution Verification

The model produces the request.

The surrounding system evaluates it.

The infrastructure executes it only after the required controls have been satisfied.

For example:

{
  "action": "deploy",
  "environment": "production",
  "service": "auth-service",
  "version": "2026.10.04"
}

The control layer can independently check whether the request is structurally valid, whether the target exists, whether the requested operation is permitted, and whether additional controls are required.

The model does not need to make those decisions itself.

Passing Tests Does Not Mean Permission

Imagine the coding agent changes a payment service.

The tests pass.

The security checks pass.

The build succeeds.

The artifact is signed.

The model now proposes:

Deploy to production.

The previous results establish that the software may be technically acceptable.

They do not establish that the current actor is authorized to deploy it.

That gives us an important separation:

Validation → Is this action acceptable as an operation?

Authorization → Is this actor allowed to perform it?

Execution → Perform the approved operation.

These questions belong to different layers.

That separation also makes the architecture easier to audit and change without changing the model's reasoning process.

Powerful Agents Do Not Need Unrestricted Authority

Separating reasoning from execution does not require making the agent weak.

An engineering agent can still have broad capabilities:

inspect repositories
create branches
modify files
run tests
inspect logs
generate deployment plans
propose infrastructure changes

The system can simply apply stronger controls to higher-impact operations such as:

production deployment
credential rotation
database migration
destructive infrastructure changes
financial transactions

The agent remains capable of reasoning about complex operations.

Its capabilities just do not automatically become unrestricted authority.

Think in Actions, Not Just Tools

Another architectural mistake is defining control only around tool access.

For example:

Agent → deploy_tool
Agent → payment_api
Agent → database_api

Tool access is often too coarse.

The more useful question is:

What action is the agent attempting to perform, against which resource, under which constraints?

A control layer can therefore reason about something closer to:

Actor → Action → Resource → Environment → Scope → Context → Policy

Now the system can distinguish between actions that happen to use the same underlying tool.

A deployment API, for example, might be capable of deploying to both staging and production. Access to the API alone does not tell us whether a particular production deployment should be allowed.

The meaningful unit of control is the action and its context, not simply the existence of a tool.

When Agents Start Delegating

The boundary becomes even more important when one agent delegates work to another.

Consider:

User → Orchestrator Agent → Procurement Agent → Payment Service

The procurement agent may determine that a purchase is necessary.

But the fact that the orchestrator requested the purchase does not automatically give the procurement agent unlimited spending authority.

Now the system needs to understand more than the requested action:

Initiator → Delegator → Acting Agent → Action → Resource → Scope

This introduces a deeper authorization problem: how authority is delegated between actors.

That problem deserves its own layer rather than being squeezed into the basic execution model.

A Better Mental Model

Instead of:

User → AI → Everything

think about:

User → Intent → AI Agent → Proposed Action → System Controls → Infrastructure

The AI sits inside the system.

It does not become the system.

That gives the architecture a stable control boundary around a component whose behavior is probabilistic.

The model can change.

The model can be upgraded.

The model can be replaced.

The surrounding execution controls can remain.

The Principle

Giving an AI agent more tools does not automatically mean giving it more authority.

The goal is not to prevent AI from acting.

The goal is to separate the ability to propose an action from the authority to execute it.

AI proposes. Systems verify. Infrastructure executes.

And once agents start acting on behalf of other agents, the next question becomes unavoidable:

Who actually has the authority to perform the action?

What If I'm Not Tired of Coding, Just Tired of Starting?

Sina Rezaei — Mon, 05 Oct 2026 05:15:00 +0000

There is a strange state you can reach as a developer.

You still know how to code.

You still understand the logic. You can still look at a problem and roughly see how you would solve it.

But opening the editor feels difficult.

Not writing the code.

Just starting.

And I think that's an interesting distinction.

Maybe sometimes we say:

"I'm tired of coding."

when the real problem is:

"I don't know what I want to build anymore."

Those are not the same problem.

I can build it. But what is "it"?

Give me a real problem and things become easier.

An API needs to receive orders.

A database needs to store them.

A service needs to process them.

A UI needs to expose the result.

Now there is something to push against.

Architecture starts appearing. Trade-offs become visible. You can make decisions.

But give a developer an empty repository and say:

"Build something."

That's different.

Suddenly, knowing five languages doesn't tell you what the first commit should be.

You don't have a programming problem anymore.

You have a direction problem.

And I don't think we talk about that enough.

The first step can be the real problem

One of the interesting things in the discussion around burnout is that people don't always describe the same obstacle.

For some, the answer is rest.

For others, it is finding something interesting again.

Someone even described opening a project, changing one variable, closing it, and repeating that for a few days. The important part wasn't the variable. It was getting past the first few seconds of opening the editor.

That made me think.

What if "starting" is its own problem?

You can have the skill.

You can have the time.

You can even have a project.

And still not cross that tiny gap between:

I should code

and

I'm actually coding.

Maybe the project is the missing piece

There is another possibility.

Maybe the solution isn't another productivity trick.

Maybe there simply isn't a problem worth solving right now.

A developer can be perfectly capable of building something and still have no reason to build it.

And "just make a side project" doesn't really solve that.

What kind of project?

A game?

A SaaS?

A CLI tool?

A portfolio project?

Something useful?

Something technically impressive?

Something completely stupid but fun?

The moment you ask those questions, you realize that "build something" isn't actually a small instruction.

It's a huge one.

Skills can survive when motivation doesn't

This is probably the part I find most interesting.

You don't necessarily forget programming because you stop coding for a while.

You may still remember the syntax.

You may still understand the architecture.

You may still be able to solve the problem once somebody gives you one.

But the connection between "I can build this" and "I want to build this" can disappear.

And maybe that's why some developers don't need another tutorial.

They need something that makes them curious again.

A problem.

An idea.

A person asking for something.

An open-source issue.

An old project that suddenly looks interesting again.

Anything that gives the technical ability somewhere to go.

So how do you start again?

Honestly, I don't think there is one universal answer.

Sometimes the answer might be rest.

Sometimes it might be stepping away from the editor.

Sometimes it might be writing an idea on paper before writing code.

Sometimes it might simply be finding a problem that makes you think:

"Wait... I could actually build that."

And maybe that's the more useful question than:

"How do I become productive again?"

Maybe it's:

"What would make me want to build something again?"

Have you ever reached a point where you still had the skills, but couldn't bring yourself to start?

Was the problem the coding itself, the lack of ideas, or simply having nothing that felt worth building?

Getting to Know Yourself: Understanding self in Ruby

Sina Rezaei — Fri, 02 Oct 2026 09:42:40 +0000

self is one of those Ruby keywords that looks easy until you meet it in real code.

You see it in a setter:

self.name = normalized_name

Then in a class method:

def self.from_cents(...)

Then somewhere inside a DSL or instance_eval, and suddenly the question isn't really:

What does self mean?

The better question is:

Who is self right here?

That small change makes Ruby's object model much easier to follow.

The setter case is where it starts to matter

Consider a model-like object:

class Customer
  attr_accessor :name, :email

  def initialize(name:, email:)
    @name = name
    @email = email
  end

  def normalize
    self.name = name.strip.downcase
    self.email = email.strip.downcase
  end

  def contact
    "#{name} <#{email}>"
  end
end

customer = Customer.new(
  name: "Maya",
  email: "MAYA@EXAMPLE.COM "
)

customer.normalize

puts customer.contact

There is something easy to miss here:

self.name = name.strip.downcase

Why not:

name = name.strip.downcase

Because those two lines are doing different things.

The second one is a local variable assignment.

The first one calls the name= setter on the current object.

Ruby lets us call the getter without explicitly writing the receiver:

name

But assignment creates an ambiguity. When we write:

self.name = ...

we are making the receiver explicit.

In other words:

self.name = "Maya"

means:

Call name= on the object I'm currently working with.

That object is self.

And notice something important.

We didn't create self.

We didn't assign it.

Ruby already knew what self was when normalize started running.

That is the first useful clue.

self is less about a special keyword and more about the object currently receiving the work.

Most of the time, Ruby hides it from you

Take a slightly more realistic object:

class Invoice
  def initialize(customer, total)
    @customer = customer
    @total = total
    @status = :open
  end

  def close
    return false unless valid_for_closing?

    mark_as_paid
    notify_customer
    true
  end

  private

  def valid_for_closing?
    @total.positive? && @status == :open
  end

  def mark_as_paid
    @status = :paid
  end

  def notify_customer
    puts "Invoice notification sent to #{@customer}"
  end
end

Inside close, Ruby sees:

mark_as_paid
notify_customer

You could make the receiver explicit:

self.mark_as_paid
self.notify_customer

But normally there is no reason to.

The receiver is already there.

It is self.

So when Ruby evaluates:

mark_as_paid

the useful mental model is:

self.mark_as_paid

The receiver is implicit.

This is one of those Ruby features that makes code pleasant to read, but it can also hide an important detail.

The receiver isn't missing.

It is invisible.

And that becomes interesting when we start asking when Ruby changes that context.

There are scope gates for `self`

This is where I find it useful to stop thinking about every Ruby construct as if it creates a new self.

It doesn't.

A block is a good example.

Consider:

class Report
  def initialize(rows)
    @rows = rows
  end

  def failed_rows
    failures = []

    @rows.each do |row|
      next unless row[:status] == :failed

      failures << {
        id: row[:id],
        reason: row[:error]
      }
    end

    failures
  end
end

Inside the block:

@rows.each do |row|

row is the block's local value.

It is not self.

And the block does not automatically replace the surrounding self.

So inside that block, self is still the Report instance.

This gives us a useful mental distinction:

Not every nested piece of Ruby code is a new self scope.

A block can introduce local variables and control flow without automatically changing the receiver.

But structures such as:

class ...
module ...
def ...

create important boundaries in how Ruby evaluates code and what self refers to.

And then there are APIs that deliberately change it.

For this article, I'll call these boundaries scope gates. That's a mental model, not an official Ruby term.

The useful idea is simply:

A block is not automatically a self gate. Context-changing constructs and APIs are.

Once you see that, some Ruby behavior that initially feels inconsistent becomes much easier to predict.

And now we can look at the class side.

The same keyword can point at the class

Consider a factory-style class method:

class Invoice
  def initialize(customer, total)
    @customer = customer
    @total = total
  end

  def self.from_cents(customer, cents)
    new(customer, cents / 100.0)
  end

  def summary
    "#{@customer}: $#{format('%.2f', @total)}"
  end
end

invoice = Invoice.from_cents("Maya", 12500)

puts invoice.summary

This line:

def self.from_cents

can look like special Ruby grammar.

It isn't really a separate universe.

The important part is still the receiver.

While Ruby evaluates the body of the class definition, self refers to the Invoice class object.

So:

def self.from_cents

is essentially saying:

Define from_cents on the object currently referenced by self.

And in this context, that object is Invoice.

That is why this works:

Invoice.from_cents(...)

The class itself is an object, and that object can receive method calls.

Now compare the two situations:

invoice.summary

Here the receiver is an Invoice instance.

Invoice.from_cents(...)

Here the receiver is the Invoice class object.

Nothing about the keyword changed.

The context did.

That distinction is much more useful than memorizing "instance method versus class method" as two unrelated Ruby features.

Rails makes this even more visible

You see the same idea constantly in Rails models.

For example:

class Subscription < ApplicationRecord
  scope :active, -> {
    where(status: :active)
  }

  def self.for_customer(customer)
    active.where(customer: customer)
  end

  def cancel!
    update!(
      status: :cancelled,
      cancelled_at: Time.current
    )
  end
end

There are several receivers involved here.

When you call:

subscription.cancel!

the receiver is the subscription instance.

Inside cancel!, the call to:

update!(...)

is being sent to that instance.

But:

Subscription.for_customer(customer)

is sent to the Subscription class object.

And Rails adds another interesting layer with scope.

The block passed to scope is not simply "a new self." The surrounding Ruby context and the way Rails evaluates the scope both matter.

This is why a useful question when reading Rails code is not just:

What method is this?

but:

What object is receiving this method here?

That question scales much better when the code gets more dynamic.

Then `instance_eval` deliberately moves the context

Now we can make the context change explicit.

Consider a configuration object:

class Configuration
  def initialize
    @values = {}
  end

  def [](key)
    @values[key]
  end

  def values
    @values.dup
  end
end

config = Configuration.new

config.instance_eval do
  @values[:environment] = "production"
  @values[:region] = "eu-west"
  @values[:logging] = :verbose
end

puts config[:environment]
puts config[:region]

Why can this block access:

@values

directly?

Because instance_eval evaluates the block with the receiver as self.

Before entering the block, self referred to the surrounding context.

Inside:

config.instance_eval do

self becomes config.

That is a deliberate context change.

And this is where the earlier idea of scope gates becomes useful.

The block itself didn't inherently create a new self.

instance_eval did.

Ruby gives the programmer an explicit mechanism for saying:

Evaluate this code as if this object is the current receiver.

That is a very different thing from simply passing a block around.

`instance_exec` takes the same idea one step further

There is a subtle difference between instance_eval and instance_exec that becomes important when designing DSLs.

Suppose we want to configure an object, but we also want to pass information into the block:

class Endpoint
  def initialize
    @settings = {}
  end

  def settings
    @settings
  end
end

endpoint = Endpoint.new

method = :post
path = "/users"

endpoint.instance_exec(method, path) do |http_method, route|
  @settings[:method] = http_method
  @settings[:path] = route
  @settings[:authenticated] = true
end

puts endpoint.settings

The important part is:

endpoint.instance_exec(method, path) do |http_method, route|

instance_exec changes self to endpoint, just like the context-changing idea we saw with instance_eval.

But it also lets us pass arguments into the block.

So inside the block we have both:

self

pointing at endpoint, and:

http_method
route

coming from the outside.

That combination is useful when building expressive APIs.

It lets a DSL control the execution context without losing the ability to feed the block data.

And suddenly a pattern like:

resource :users do
  method :get
  path "/users"
end

starts looking less magical.

The DSL designer may be combining:

a receiver that becomes self
a block that defines the configuration
arguments or yielded values
method dispatch through that context

The syntax is the surface.

The context is the machinery underneath.

This is why Ruby DSLs can feel strange

Once you start thinking in terms of context, Ruby DSLs become less mysterious.

You might see code that looks almost like configuration:

resource :users do
  path "/users"
  method :get
  authentication :required
end

The interesting question isn't only:

What does resource do?

It is also:

What is self while this block is being evaluated?

Maybe the DSL is yielding to a builder object.

Maybe it is using instance_eval.

Maybe it is using instance_exec because it needs both a changed receiver and arguments.

Maybe it is delegating method calls.

The surface syntax can look almost identical while the underlying execution model is very different.

That's why self becomes particularly useful when reading metaprogramming-heavy Ruby.

Instead of getting stuck on the syntax, look for the receiver.

Then look for the context.

Then look for the point where that context changes.

So, who is `self`?

I don't think of self as a definition I need to memorize anymore.

I think of it as a signpost.

When I see:

self.name = value

I ask:

Which object is receiving this assignment?

When I see:

def self.build

I ask:

What is self while Ruby is evaluating this class body?

When I see:

something.instance_eval do

I ask:

Did Ruby just change the receiver for this block?

When I see:

something.instance_exec(data) do |value|

I ask two questions:

What is self now?

and:

What data was passed into this context?

And when I see a Ruby DSL that seems to have methods appearing out of nowhere, I ask:

Who is self here, and where did that context come from?

That question usually gets me closer to the actual behavior than simply remembering what the keyword means.

Because self isn't really the interesting part.

Context is.

Once you start reading Ruby through that lens, self becomes less of a keyword to memorize and more of a way to locate yourself inside Ruby's object model.

And I'm curious how other Ruby developers approach this.

Do you consciously think about self while reading Ruby code, or has it become one of those things you only notice when the context suddenly changes?

OAuth 2.0 Device Flow: How Authentication Works When the Device Can't Handle the Login

Sina Rezaei — Thu, 24 Sep 2026 14:03:49 +0000

Authentication is straightforward when a user has a browser, keyboard, and screen.

A laptop can open a login page. A phone can redirect the user to an identity provider. But what happens when the device is a Smart TV, game console, CLI tool, or another device that is not well suited for entering credentials?

This is where the OAuth 2.0 Device Authorization Grant, commonly called Device Flow, becomes useful.

Instead of asking the device to handle the login itself, Device Flow lets the user authenticate on another device while the original device waits for the result.

The basic idea

The device starts the authentication process and receives a set of temporary values from the authorization server.

The user then opens a verification URL on a phone or computer, enters a short code, and completes authentication there.

The original device does not need to display or process the full login interface.

The flow looks roughly like this:

Device
   |
   |  Device Authorization Request
   v
Authorization Server
   |
   |  device_code + user_code
   v
Device
   |
   |----------------------> User's Browser / Phone
   |                         |
   |                         | Login + consent
   |                         v
   |                    Authorization Server
   |
   |  Poll Token Endpoint
   v
Authorization Server
   |
   |  Access Token
   v
Device

The important part is that the device and the user's browser do not have to be the same device.

What the device receives

The device first sends a request to the authorization server's device authorization endpoint.

The response typically contains values such as:

{
  "device_code": "4fJ8...",
  "user_code": "WDJB-MJHT",
  "verification_uri": "https://example.com/device",
  "expires_in": 600,
  "interval": 5
}

The important fields are:

device_code: identifies the authentication request and is used by the device when requesting tokens.
user_code: a short code the user enters on another device.
verification_uri: where the user goes to authenticate.
expires_in: how long the authorization request remains valid.
interval: how often the device should poll the token endpoint.

The device_code and user_code serve different purposes.

The device keeps the device_code. The user normally only sees the user_code.

The user finishes authentication somewhere else

The device can now display something like:

Open:
https://example.com/device

Enter code:
WDJB-MJHT

The user opens the URL on a phone or computer, enters the code, signs in, and approves the requested access.

Nothing special has to happen on the original device while this is taking place.

It simply waits.

The device polls for the token

After receiving the device authorization response, the device starts polling the token endpoint.

For example:

POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:device_code
&device_code=4fJ8...
&client_id=my-device

If the user has not finished authentication yet, the authorization server can return:

{
  "error": "authorization_pending"
}

The device waits and tries again.

It should not continuously hammer the server. The server can also return:

{
  "error": "slow_down"
}

which tells the client to increase the polling interval.

Once the user has successfully authenticated and granted access, the response contains the token:

{
  "access_token": "eyJ...",
  "token_type": "Bearer",
  "expires_in": 3600
}

The device can then use that access token to call the protected API.

What can happen while the device waits?

The device needs to handle more than just success and authorization_pending.

Common responses include:

Response	Meaning
`authorization_pending`	The user has not finished yet
`slow_down`	Poll less frequently
`expired_token`	The device authorization request expired
`access_denied`	The user rejected the request

This is important because Device Flow is inherently asynchronous.

The device cannot assume that authentication will finish immediately, or even finish successfully.

Why use a separate user code?

You might wonder why the user does not simply enter the long device_code.

The answer is usability.

A device_code is intended to be handled by the device and can be long or difficult to type. The user_code is designed for humans and is usually much shorter.

That separation also lets the authorization server associate the human-friendly code with the underlying authorization request without exposing the device's internal identifier as the thing the user has to type.

Security still matters

Device Flow solves an authentication-interface problem, but it does not remove the security requirements around authentication.

The verification endpoint should protect against things such as:

brute-force attempts against short user codes
excessive requests
reuse of expired or already-consumed codes
unauthorized access to the authorization request
overly long-lived device codes

User codes should have limited lifetimes and a sufficiently large search space. Once a code has been successfully consumed, it should not remain usable.

The server also needs to handle concurrent requests safely. Two requests attempting to consume the same authorization state should not both be able to obtain authorization.

Device Flow vs. PKCE

Device Flow and Authorization Code Flow with PKCE solve related but different problems.

PKCE is useful when the client can redirect the user through a browser but needs protection against authorization-code interception.

Device Flow is useful when the device itself is not a practical place to perform the browser-based login.

A CLI application is a good example:

CLI
 |
 | "Go to this URL and enter this code"
 v
Browser
 |
 | Login + consent
 v
Authorization Server
 |
 v
CLI receives token

Trying to force a full browser login experience into a terminal would make the client unnecessarily complicated.

Device Flow moves that responsibility to a device that is actually good at it.

Where Device Flow makes sense

You will commonly see this pattern with:

Smart TVs
game consoles
command-line applications
media players
IoT devices
devices with limited input capabilities
applications where the authentication device and usage device are different

The common characteristic is not necessarily weak hardware.

It is that the device is a poor place to perform interactive authentication.

A practical implementation checklist

When implementing Device Flow, make sure the client:

stores the device_code securely
displays the verification URI and user code clearly
respects the polling interval
handles authorization_pending and slow_down
stops when the request expires
handles user denial
securely stores the resulting access token

The authorization server should, at minimum:

expire device authorization requests
rate-limit verification and token endpoints
prevent user-code guessing and abuse
ensure authorization state cannot be reused incorrectly
issue tokens only after the required user authorization has completed

The bigger engineering idea

Device Flow is a useful example of a broader engineering principle.

A component does not have to perform every part of a process itself.

A Smart TV is good at displaying content, but terrible at typing a password with a remote control. A CLI is excellent for commands, but not necessarily for interactive web authentication.

Instead of forcing the device to do something badly, Device Flow gives each part of the system a job it is better suited to perform:

Device       → starts the request and waits
Browser      → handles interactive authentication
Server       → manages authorization and tokens
Device       → uses the resulting access token

That separation is what makes the flow practical.

OAuth 2.0 Device Flow is therefore less about adding another authentication screen and more about moving authentication to the place where it can be performed properly.

Navigating the Landscape of Development: Building a Sustainable Future

Sina Rezaei — Fri, 24 Nov 2023 13:24:43 +0000

When people hear sustainable development, software engineering probably isn't the first thing that comes to mind.

Usually, we picture renewable energy, electric cars, green buildings, or a company presentation full of words like impact, future, and responsibility.

But there is another side of sustainability that developers and architects deal with every day.

It's what happens when your application gets 10x 4 more infrastructure?

Does a database query suddenly become 20 times more expensive?

Are you keeping machines running when nobody is using them?

Are you storing years of data that nobody reads?

And perhaps the uncomfortable one: did the system become more complicated simply because the team kept adding things?

That's where sustainability becomes an engineering problem rather than a marketing concept.

For me, sustainable software is mostly about building systems that don't constantly need more resources just to keep doing the same job.

1. Economic Sustainability: Fix the System Before Buying More Infrastructure

One of the easiest ways to waste money in software is to treat infrastructure as the solution to every performance problem.

The application is slow?

Add CPU.

Database is struggling?

Buy a bigger instance.

Traffic increased?

Add more servers.

Memory usage is high?

Throw RAM at it.

Sometimes that's exactly the right decision. But sometimes you're just paying more to hide a bad design.

AWS's Well-Architected Framework treats cost optimization and performance efficiency as separate but connected architectural concerns. Its guidance specifically recommends considering cost during architectural decisions, right-sizing resources, and continuously reviewing the resources that drive infrastructure spending.

A simple example is a database query.

Imagine something like:

SELECT *
FROM orders
WHERE customer_id = 18472
ORDER BY created_at DESC;

If customer_id isn't indexed properly, the application might still work perfectly with 500 records.

Then the database gets millions of rows.

Suddenly the same innocent-looking query becomes a production problem.

You can increase the database size, or you can ask a much better question:

Why is the database doing this much work in the first place?

Adding the right index, changing the query, reducing unnecessary columns, or redesigning how the data is accessed can sometimes remove the bottleneck without buying a larger machine.

That's sustainable architecture in a very practical sense.

You're making the system do less work.

Don't confuse scalability with throwing hardware at the problem

There's nothing inherently wrong with horizontal scaling, containers, serverless functions, or managed infrastructure.

The problem starts when infrastructure becomes a substitute for engineering.

A lightweight service that scales from 2 instances to 20 because demand actually increased is one thing.

A service that needs 20 instances because every request triggers unnecessary database calls is another.

The difference is architectural.

The same idea applies to serverless systems. Serverless isn't automatically "green", and containers aren't automatically efficient either. The actual workload matters.

A badly designed function running millions of unnecessary operations is still badly designed, even if it happens to be running in a serverless platform.

Reuse before rewrite

There's another form of sustainability that gets less attention: the codebase itself.

Not every old module needs to be rewritten.

Sometimes refactoring a painful component is enough.

A full rewrite means rebuilding behavior, tests, integrations, deployment pipelines, monitoring, edge cases, and all the strange little things the original system learned over the years.

Sometimes you absolutely should rewrite.

But "let's rewrite everything" shouldn't be the default response to technical debt.

A sustainable codebase is one that can evolve without requiring the team to burn down the entire house every few years.

2. Social Sustainability: The System Has Humans in the Loop

Here's something easy to forget when talking about architecture:

The people maintaining the system are part of the system.

If only one developer understands how authentication, payments, deployment, and database migrations work, you don't have a resilient architecture.

You have a knowledge bottleneck.

And eventually that bottleneck becomes a production risk.

Imagine a developer leaves the company.

Nobody knows why a particular service exists.

Nobody knows why a specific queue has a strange retry policy.

Nobody knows why deleting one database column breaks an unrelated reporting system.

The documentation says:

"Legacy logic. Don't touch."

That's not documentation.

That's a warning label.

Reduce knowledge silos

Good architecture isn't only about separating services.

It's also about making the system understandable.

Clear boundaries, useful documentation, sensible naming, tests, diagrams where they actually help, and explicit ownership all reduce the amount of tribal knowledge required to work on a system.

Domain-Driven Design can help here because it encourages teams to make business boundaries explicit instead of allowing everything to slowly become one giant blob of shared logic.

You don't need DDD everywhere.

A small application doesn't need a 40-page architecture document.

But when the domain becomes complicated, making the boundaries visible can save a lot of pain later.

Architecture should be discussable

Another useful practice is the architecture decision record, RFC, or similar design-review process.

The important part isn't the acronym.

It's the habit of writing down:

What are we trying to solve?
What options did we consider?
What are the trade-offs?
Why did we choose this approach?
What could make us change the decision later?

That creates something much more valuable than a diagram nobody reads six months later.

It creates context.

And context is extremely useful when the original author isn't in the room anymore.

3. Accessibility Is Also Part of Sustainability

There is another human side that often gets left out of the conversation: accessibility.

A system that works beautifully for one group of users but becomes difficult or impossible to use for others isn't particularly sustainable from a product perspective.

The W3C's WCAG framework organizes accessibility around four principles: perceivable, operable, understandable, and robust.

That translates into very practical engineering decisions.

Can someone navigate the interface with a keyboard?

Does the form provide useful error messages?

Do buttons and controls have meaningful labels?

Does the application still work with assistive technologies?

Does the interface remain usable when the screen is zoomed?

These aren't just "frontend polish" issues.

They affect whether a product remains usable as its audience grows and as devices, browsers, and user needs change.

4. Environmental Sustainability: Software Still Runs on Physical Machines

This is where the conversation gets interesting.

Software feels abstract.

It's code.

It's APIs.

It's containers.

It's a Git repository.

But eventually, every instruction ends up running on physical hardware.

CPU cycles consume electricity.

Memory consumes electricity.

Storage consumes electricity.

Networking consumes electricity.

Data centers also require cooling and other infrastructure.

The Green Software Foundation's current work frames software sustainability around things such as energy efficiency, carbon efficiency, carbon awareness, hardware efficiency, and measurement.

So a useful question isn't simply:

"Is my application green?"

A better question is:

"How much physical work does my software require to deliver one unit of useful work?"

That changes how you look at optimization.

A database query is not just a database query

Suppose an endpoint loads 50,000 database rows, processes them in application memory, and finally returns 20 records.

It works.

But why did the application process 50,000 records to return 20?

Maybe the filtering belongs in the database.

Maybe pagination is missing.

Maybe the query needs an index.

Maybe the API is returning fields the client doesn't need.

The improvement isn't about making the code look prettier.

You're reducing actual work.

And that can mean less CPU time, less memory pressure, less I/O, less network traffic, and potentially less infrastructure.

That's a much more interesting definition of optimization.

Caching is useful, but it isn't magic

Caching can be another example.

If thousands of users request the same expensive piece of data, repeatedly calculating it or hitting the database for every request doesn't make much sense.

A cache such as Redis can reduce repeated computation and database traffic.

But caching everything isn't sustainable either.

Now you have another system to operate.

You have memory consumption.

You have cache invalidation.

You have synchronization problems.

You have stale-data decisions.

So the question shouldn't be:

"Can we add Redis?"

It should be:

"Where is repeated work happening, and is caching actually the cheapest way to remove it?"

That's a very different architectural conversation.

5. Measure the Work Instead of Guessing

One of the most useful developments in green software engineering is the move toward measurement.

The Green Software Foundation's Software Carbon Intensity specification, for example, provides a methodology for measuring the carbon impact of software and explicitly considers energy, hardware, and carbon intensity rather than treating "green" as a vague label.

You don't necessarily need to calculate a carbon score for every API endpoint tomorrow.

But the underlying idea is valuable:

measure something.

For example:

CPU time per request
memory usage
database queries per request
data transferred per request
storage growth
average response size
infrastructure utilization
energy consumption where measurable

Even a simple metric can expose waste.

If version B performs the same business operation with half the database queries and 30% less compute, you've got evidence.

Now optimization becomes engineering instead of storytelling.

6. Carbon Awareness Changes the Question

There's an interesting concept in green software that goes beyond simply making software more efficient: carbon awareness.

Not all electricity has the same carbon intensity at every location or every moment.

The Green Software Foundation describes carbon-aware computing as doing more when electricity is cleaner and less when it is more carbon-intensive.

That creates some interesting possibilities.

Imagine you have a batch workload that doesn't need to finish immediately:

generating large reports
processing analytics
training certain models
rebuilding indexes
running backups
processing large datasets

If the workload can safely move to a different time or region, the system could potentially run it when the electricity supply has a lower carbon intensity.

The Carbon Aware SDK is one example of tooling built around this idea, including choosing when or where workloads run based on emissions data.

Obviously, you don't apply this to everything.

A payment API can't simply tell a customer:

"Sorry, the grid looks dirty right now. Try again tomorrow."

Real-time systems have real-time requirements.

That's where architectural trade-offs matter.

7. Sustainability Is Mostly About Trade-offs

This is probably the part I find most interesting.

There isn't a universal architecture that is simultaneously:

cheapest
fastest
simplest
most reliable
most secure
easiest to maintain
and lowest-carbon

You usually have to choose.

AWS itself describes Well-Architected as a framework built around six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. The framework explicitly recognizes that architectural decisions involve trade-offs based on business context.

For example, keeping extra infrastructure running may cost more, but it can make a mission-critical system more resilient.

Compressing everything may reduce bandwidth, but CPU usage can increase.

Aggressive caching may reduce database work, but increase memory usage.

Moving a workload to a cleaner region may reduce carbon impact, but introduce latency or compliance issues.

So "sustainable" doesn't mean blindly minimizing one number.

It means understanding the system well enough to make deliberate trade-offs.

Bottom Line

For me, sustainable software development comes down to a pretty simple idea:

Don't make the system work harder than it needs to.

That applies to infrastructure.

It applies to databases.

It applies to network traffic.

It applies to storage.

It applies to architecture.

And it even applies to the people maintaining the code.

If a system needs more servers every time the user count increases, ask why.

If the database is doing millions of unnecessary operations, investigate.

If nobody understands a critical service except one person, fix the knowledge bottleneck.

If you're storing data nobody will ever use again, question it.

If a workload can move to a cleaner time or location without affecting the business, maybe let it.

Sustainability isn't a green badge you attach to an architecture diagram.

It's what happens when engineers start treating resources, people, infrastructure, and long-term maintainability as part of the same system.

And honestly, that's probably a better definition of good engineering anyway.

Update Note

Originally published in 2023. Updated in October 2026 with deeper coverage of system architecture, cloud efficiency, green software engineering, accessibility, carbon awareness, measurement, and real-world engineering trade-offs.

DEV Community: Sina Rezaei

Beyond Fat Controllers: Using the Facade Pattern in Ruby on Rails

From a Fat Controller to a Facade

Introducing the Facade

The Detail That Matters: Failure Handling

Testing the Workflow

When Should You Use a Facade?

AI Should Propose. Systems Should Verify.

AI Should Propose. Systems Should Verify.

The Problem With Direct Execution

Put a Boundary Between Reasoning and Execution

Passing Tests Does Not Mean Permission

Powerful Agents Do Not Need Unrestricted Authority

Think in Actions, Not Just Tools

When Agents Start Delegating

A Better Mental Model

The Principle

What If I'm Not Tired of Coding, Just Tired of Starting?

I can build it. But what is "it"?

The first step can be the real problem

Maybe the project is the missing piece

Skills can survive when motivation doesn't

So how do you start again?

Getting to Know Yourself: Understanding self in Ruby

The setter case is where it starts to matter

Most of the time, Ruby hides it from you

There are scope gates for self

The same keyword can point at the class

Rails makes this even more visible

Then instance_eval deliberately moves the context

instance_exec takes the same idea one step further

This is why Ruby DSLs can feel strange

So, who is self?

OAuth 2.0 Device Flow: How Authentication Works When the Device Can't Handle the Login

The basic idea

What the device receives

The user finishes authentication somewhere else

The device polls for the token

What can happen while the device waits?

Why use a separate user code?

Security still matters

Device Flow vs. PKCE

Where Device Flow makes sense

A practical implementation checklist

The bigger engineering idea

Navigating the Landscape of Development: Building a Sustainable Future

1. Economic Sustainability: Fix the System Before Buying More Infrastructure

Don't confuse scalability with throwing hardware at the problem

Reuse before rewrite

2. Social Sustainability: The System Has Humans in the Loop

Reduce knowledge silos

Architecture should be discussable

3. Accessibility Is Also Part of Sustainability

4. Environmental Sustainability: Software Still Runs on Physical Machines

A database query is not just a database query

Caching is useful, but it isn't magic

5. Measure the Work Instead of Guessing

6. Carbon Awareness Changes the Question

7. Sustainability Is Mostly About Trade-offs

Bottom Line

Update Note

There are scope gates for `self`

Then `instance_eval` deliberately moves the context

`instance_exec` takes the same idea one step further

So, who is `self`?