mir-backend-beam-phoenix

Solid

Make It Right (Phoenix module). Phoenix + LiveView + Ecto + Plug + PostgreSQL specific reliability augmentation. Chains: mir-backend (generic gates) -> mir-backend-beam (BEAM runtime) -> this (Phoenix/LiveView/Ecto/Plug library mechanics). Adds the mechanical footguns the framework-agnostic tiers omit: LiveView per-connection process memory, with streams vs temporary_assigns for large collections; the async-assign APIs (assign_async/4, start_async/4 + handle_async/3, cancel_async/3) and why a bare Task.async in a LiveView kills the LiveView on crash; handle_event as a public websocket endpoint that must re-authorize on every event; Phoenix 1.8 scopes threading %Scope{} through context functions; Ecto N+1 on unloaded associations; changeset cast/4 as the mass-assignment allow-list; and migration safety on populated tables (concurrently, disable_ddl_transaction, expand/contract, NOT VALID + VALIDATE). TRIGGER only when the BEAM backend stack is Phoenix - building, reviewing, or debugging a Phoenix controller, L

API & Backend 15 stars 0 forks Updated 1 weeks ago Apache-2.0

Install

View on GitHub

Quality Score: 81/100

Stars 20%
40
Recency 20%
90
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# /mir-backend-beam-phoenix · Make It Right (Phoenix) Bottom tier of the chain: `mir-backend` (generic gates) → `mir-backend-beam` (BEAM/Erlang VM process model) → **this** (Phoenix/LiveView/Ecto/Plug library mechanics). Run the gates first; load the BEAM runtime tier for supervision, mailbox, ETS and atom-exhaustion concerns; reach for *this* at Gate 5 (design mechanics), Gate 6 (implementation), and Gate 7 review. **Runtime-level concerns (supervision trees, unbounded mailboxes, GenServer bottlenecks, `:persistent_term`, distributed Erlang, `binary_to_term`, Hex supply chain) live in `mir-backend-beam` — not here.** **Stack assumed:** Phoenix · LiveView · Ecto · Plug · Bandit · PostgreSQL · PubSub. Verified 13 Aug 2026 on hex.pm: **Phoenix 1.8.11** (12 Aug 2026, 1.9 is unreleased and in development), **phoenix_live_view 1.2.9** (10 Aug 2026, with 1.1.33 as a maintained line), **ecto 3.14.1** (9 Jul 2026), **ecto_sql 3.14.0**, **plug 1.20.3** (9 Jul 2026), **bandit 1.12.4** (27 Jul 2026), **postgrex 0.22.4** (7 Aug 2026), **phoenix_pubsub 2.2.0**. Bandit is the default adapter in generated Phoenix apps. Phoenix 1.8 requires OTP 25+. If the project uses an Ecto adapter other than Postgres, note the divergence before applying the migration-safety items — the `CONCURRENTLY` and `NOT VALID` patterns below are PostgreSQL-specific. ## The Phoenix footguns AI walks into most ### 1. LiveView state is per-connection — memory scales with concurrent users Each connected LiveView c...

Details

Author
anantbhandarkar
Repository
anantbhandarkar/make-it-right
Created
3 months ago
Last Updated
1 weeks ago
Language
Python
License
Apache-2.0

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

API & Backend Solid

mir-backend-beam

Make It Right (BEAM runtime tier). Erlang VM / BEAM reliability footguns shared across every BEAM-based backend (Phoenix, Nerves, Broadway, pure Erlang/OTP) — distinct from the generic backend gates and from any one framework's mechanics. Covers: let-it-crash + supervision tree design (restart strategies, max_restarts escalation, poison-message crash-loops and why a catch-all handle_info does NOT stop them), unbounded mailbox growth and real backpressure (a GenServer.call timeout does not shed load; GenStage/Broadway; OTP 28 priority messages are not backpressure), hot GenServer as a serial bottleneck and when to use ETS / :counters / :persistent_term instead, blocking handle_call timing out callers, per-process heap isolation and refc-binary retention, distributed Erlang hazards (netsplits, :global, pairwise ordering, :erpc), what Elixir's set-theoretic type checker does and does not catch, and VM-level security (binary_to_term, atom exhaustion, distribution cookie/EPMD, :os.cmd vs System.cmd, OTP TLS/term-d

15 Updated 1 weeks ago
anantbhandarkar
API & Backend Solid

mir-backend-python-fastapi

Make It Right (FastAPI module). FastAPI + Starlette + Async SQLAlchemy 2.0 + Postgres + Alembic + Redis specific reliability augmentation. Use alongside the mir-backend skill when the target stack is FastAPI — it carries the mechanical footguns that the framework-agnostic skill deliberately omits: async session lifecycle and scope, engine creation in lifespan (on_event is deprecated), Pydantic v2 validation boundaries, Annotated[...]-based Depends() auth and object-level authorization, BackgroundTasks vs a real queue, async N+1 with selectinload, greenlet/sync-driver-in-async traps, Starlette threadpool saturation, Alembic migration safety on populated tables, Redis idempotency/locking patterns, and the 2026 Starlette advisory set (Host-header path poisoning, form-limit bypass, StaticFiles UNC). TRIGGER only when the Python backend stack is FastAPI — building, reviewing, or debugging a FastAPI endpoint, dependency, Starlette middleware, SQLAlchemy session, or Alembic migration. Always loads TOGETHER WITH mir-

15 Updated 1 weeks ago
anantbhandarkar
API & Backend Solid

mir-database-postgres

Make It Right (PostgreSQL module). Postgres mechanics the engine-agnostic pillar omits: which ALTER TABLE subforms take ACCESS EXCLUSIVE and the lock queue where a blocked DDL stalls every read behind it; lock_timeout/statement_timeout migration discipline; NOT VALID then VALIDATE; CREATE INDEX CONCURRENTLY and invalid-index cleanup; MVCC bloat, autovacuum, XID wraparound; isolation levels and 40001/40P01 retry; SELECT FOR UPDATE vs FOR NO KEY UPDATE, SKIP LOCKED queues, advisory locks; b-tree/GIN/GiST/BRIN choice, partial and covering indexes, why an index is unused; PgBouncer pooling modes and transaction-pooling breakage; RLS multi-tenancy and its bypass paths. Chains: mir-database (the gates) → this. TRIGGER when the engine is PostgreSQL or Postgres-compatible (RDS/Aurora, Cloud SQL, Neon, Supabase) and the task writes DDL, a migration, an index, a locking or isolation decision, a partitioning or RLS layout, or diagnoses a slow query, EXPLAIN plan, missing index, bloat, vacuum, deadlock, or connection poo

15 Updated 1 weeks ago
anantbhandarkar