mir-backend-ruby

Solid

Make It Right (Ruby runtime tier). YARV/MRI Ruby 4.0 runtime reliability footguns shared across EVERY Ruby backend framework (Rails, Sinatra, Hanami, Sidekiq/Solid Queue workers) — distinct from the generic backend gates and from any one framework's mechanics. Covers: the GVL (threads give no CPU parallelism, like Python's GIL), the reworked Ractor API in Ruby 4.0, YJIT/ZJIT enablement, Puma's forked-worker + thread model, fork-safety of DB/Redis connections, copy-on-write memory and per-worker bloat, background job hygiene (idempotency, retries), GC/string-literal pressure, and the Rack/Puma/Bundler security layer every Ruby web app inherits. TRIGGER when the backend runtime is Ruby — sits between mir-backend (generic) and the framework module (e.g. mir-backend-ruby-rails). SKIP for Node/JVM/Go/Rust/.NET/Python/PHP/BEAM runtimes (each has its own mir-backend-<runtime> tier), and for Rails/ActiveRecord library mechanics — N+1, strong parameters, callbacks, migrations, Active Storage — which belong to mir-back

AI & Automation 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-ruby · Make It Right (Ruby runtime) The middle tier. `mir-backend` decides **what is correct** (any language). The framework module (e.g. `mir-backend-ruby-rails`) knows the **library's mechanics**. This tier owns what's true for **all Ruby backends because they run on YARV (MRI) and speak Rack** — the concurrency model, the process model, and the HTTP/dependency layer that Rails, Sinatra, Hanami, and every job worker inherit. **Runtime assumed:** MRI Ruby 4.0 under Puma. Current stable is **Ruby 4.0.6**; 3.4.x, 3.3.x and 3.2.x are still maintained, 3.1 is EOL (verified against ruby-lang.org on 13 Aug 2026). Notes hold for JRuby except where GVL specifics differ (JRuby has no GVL; true thread parallelism is available). Load order: `mir-backend` → `mir-backend-ruby` → `<framework module>`. ## What changed in Ruby 4.0 (check this before trusting older Ruby advice) Ruby 4.0.0 shipped 25 Dec 2025. It is the release that was planned and written about as "Ruby 3.5" — blog posts and AI training data referring to 3.5 mean this. | Change | What breaks | What to write instead | |---|---|---| | `Ractor.yield`, `Ractor#take`, `#close_incoming`, `#close_outgoing` **removed** | Every Ractor pipeline written against Ruby 3.x raises `NoMethodError` | `Ractor::Port` for message passing; `Ractor#join` / `#value` to wait for termination | | `--rjit` **removed** | Boot flags / Dockerfiles carrying `--rjit` fail to start | Drop the flag; use YJIT | | `Kernel#open` / `IO` with ...

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

AI & Automation Solid

mir-backend-ruby-rails

Make It Right (Rails module). Ruby on Rails 8.1 specific reliability augmentation. Use alongside mir-backend and mir-backend-ruby when the target stack is Rails — carries the mechanical footguns the framework-agnostic skills deliberately omit: ActiveRecord N+1 and eager-loading strategies, params.expect / strong parameters and mass-assignment safety, callback side-effect timing (after_commit vs after_save) and jobs enqueued inside transactions, transaction semantics and nested transactions, migration safety on populated tables (the #1 Rails production incident class), connection pool sizing across the Rails 8 primary/cache/queue/cable databases, and the Rails security defaults and Active Storage advisories. TRIGGER only when the Ruby backend is Rails — building, reviewing, or debugging a Rails controller, model, concern, migration, Active Storage attachment, or background job that uses ActiveRecord. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-ruby (YARV runtime: GVL, Ractors, YJIT, Puma

15 Updated 1 weeks ago
anantbhandarkar
AI & Automation Solid

mir-backend-python

Make It Right (Python runtime tier). CPython runtime reliability footguns that are shared across EVERY Python backend framework (FastAPI, Django, Flask, Celery) — distinct from the generic backend gates and from any one framework's mechanics. Covers: the GIL and the free-threaded build (PEP 703/779, officially supported since 3.14 but not the default), async-vs-sync 'coloring', blocking the event loop, choosing asyncio vs threads vs multiprocessing vs subinterpreters vs a worker queue, fork-safety of connection pools and the 3.14 forkserver default change, lazy annotations (PEP 649/749), serverless cold starts, dropped-task exceptions, and runtime-level security (unsafe deserialization, archive extraction, shell arguments, SSRF, packaging supply chain). TRIGGER when the backend runtime is Python — sits between mir-backend (generic) and the framework module (e.g. mir-backend-python-fastapi). SKIP for Node/JVM/Go/Rust/.NET/Ruby/PHP/BEAM runtimes (each has its own mir-backend-<runtime> tier), and for framework-l

15 Updated 1 weeks ago
anantbhandarkar
AI & Automation Solid

mir-backend-jvm

Make It Right (JVM runtime tier). Java 25/21 LTS and Kotlin runtime reliability footguns shared across every JVM backend framework — distinct from the generic backend gates and from any one framework's mechanics. Covers: thread-pool sizing and pool-exhaustion deadlock, blocking I/O on platform threads, virtual threads after JEP 491 (synchronized no longer pins on Java 24+, jdk.VirtualThreadPinned JFR event) and virtual threads not bounding concurrency, GC choice (G1, ZGC, Generational Shenandoah) and container-aware heap sizing (-XX:MaxRAMPercentage), cold start (Leyden AOT cache, AppCDS, GraalVM native image, CRaC), JMM visibility and data races, ThreadLocal leaks in pooled threads, and JVM-level security (untrusted deserialization and ObjectInputFilter, XXE defaults, SSRF to the cloud metadata IP, Security Manager disabled since JDK 24, Maven/Gradle dependency verification). Chains: mir-backend -> this -> framework module. TRIGGER when the backend runtime is Java or Kotlin on the JVM. SKIP for Python, Node,

15 Updated 1 weeks ago
anantbhandarkar