Przez lata deploy aplikacji Rails wyglądał mniej więcej tak: serwer aplikacji (Puma), baza danych (PostgreSQL), Redis (cache + sesje + Action Cable), Sidekiq (background jobs), Nginx jako reverse proxy, być może jeszcze Elasticsearch. Do tego Capistrano albo Docker + Kubernetes. Stack, który na papierze wygląda sensownie, ale w praktyce oznacza administrowanie pięcioma różnymi technologiami, każda z własnymi quirkami, konfiguracją i potrzebą monitoringu.

Rails 8 mówi: to za dużo. I proponuje radykalnie prostszą alternatywę.

Filozofia „one person framework”

DHH od lat powtarza, że Rails ma być frameworkiem, w którym jeden programista może zbudować i utrzymać produkcyjną aplikację. To nie jest nowy pomysł – ale przez ostatnią dekadę ekosystem Rails trochę się od niego oddalił. Potrzebowałeś specjalisty od DevOps, żeby ogarnąć Kubernetes. Potrzebowałeś Redisa do wszystkiego. Potrzebowałeś osobnego systemu kolejek.

Rails 8 wraca do korzeni z trzema nowymi bibliotekami, które zbiorowo nazywane są Solid Trifecta: Solid Queue, Solid Cache i Solid Cable.

Solid Queue – kolejki zadań bez Redisa

Solid Queue to system kolejek oparty na relacyjnej bazie danych. Zamiast Redisa, Twoje zadania w tle są zapisywane w tabelach PostgreSQL (lub SQLite w trybie deweloperskim). I zanim powiesz „ale przecież baza danych nie nadaje się do kolejek” – zmierzymy się z tym mitem.

W Rails 8 Solid Queue jest domyślnym adapterem Active Job:

# config/environments/production.rb
config.active_job.queue_adapter = :solid_queue# config/solid_queue.yml
production:
  dispatchers:
    - polling_interval: 1
      batch_size: 500
  workers:
    - queues: "*"
      threads: 5
      polling_interval: 0.1

To wszystko. Nie musisz instalować Redisa, konfigurować Sidekiq, martwić się o connection pool czy monitorować oddzielny proces. Twoje joby działają w tym samym stosie co aplikacja.

A wydajność? Solid Queue obsługuje miliony zadań dziennie w produkcji. Basecamp i HEY – aplikacje, na których DHH testuje swoje pomysły – działają na Solid Queue. Jeśli to wystarczy dla serwisu mailowego z milionami użytkowników, to prawdopodobnie wystarczy dla Twojej aplikacji.

Solid Queue oferuje też rzeczy, których Sidekiq w darmowej wersji nie ma: recurring jobs (zamiast whenever/cron), concurrency controls i pausing queues. To dojrzałe narzędzie, nie prototyp.

Solid Cache – cache w bazie danych

Ten pomysł brzmi jeszcze bardziej kontrowersyjnie. Cache w bazie danych? Przecież cache ma być szybki, a baza danych jest wolna – prawda?

Nie do końca. Solid Cache wykorzystuje fakt, że współczesne dyski NVMe są absurdalnie szybkie. Redis trzyma cache w RAM, co oznacza, że jesteś ograniczony ilością pamięci serwera (i ceną tej pamięci). Solid Cache trzyma cache na dysku, co oznacza, że możesz mieć terabajty cache’u za ułamek kosztu.

# config/environments/production.rb
config.cache_store = :solid_cache_store

Dla typowych aplikacji webowych różnica w latencji między Redis a Solid Cache jest nieodczuwalna – mówimy o mikrosekundach, nie milisekundach. A zyskujesz prostszą infrastrukturę, mniej ruchomych części i mniejsze koszty.

Oczywiście, jeśli budujesz system tradingowy, gdzie każda mikrosekunda ma znaczenie – Redis nadal ma sens. Ale dla 99% aplikacji webowych? Solid Cache jest więcej niż wystarczający.

Solid Cable – WebSockety bez Redisa

Action Cable – system WebSocketów w Rails – od zawsze wymagał Redisa jako backendu pub/sub. Solid Cable eliminuje tę zależność, używając (znowu) bazy danych jako warstwy transportowej.

# config/cable.yml
production:
  adapter: solid_cable
  polling_interval: 0.1.seconds
  keep_messages_around_for: 1.day

Dla aplikacji z setkami jednoczesnych połączeń WebSocket (co obejmuje większość aplikacji) Solid Cable działa świetnie. Polling jest szybki, a brak Redisa oznacza jedną mniej rzecz do monitorowania.

Kamal 2 – deployment bez Kubernetesa

Solid Trifecta upraszcza runtime, ale Rails 8 idzie dalej – upraszcza też deployment. Kamal 2 to narzędzie do deploymentu, które zastępuje Capistrano, Kubernetes i inne kolosy:

# Deployment całej aplikacji:
kamal setup    # pierwszy raz
kamal deploy   # każdy następny

Kamal używa Dockera pod spodem, ale abstrahuje całą złożoność. Budujesz obraz, Kamal wysyła go na serwer, podmienia kontenery z zero-downtime. Obsługuje SSL (przez Let’s Encrypt), load balancing (przez wbudowany Thruster/Traefik) i rolling deploys.

Potrzebujesz serwera za 5-10 dolarów miesięcznie na Hetznerze lub DigitalOcean. Nie potrzebujesz Heroku, AWS ECS, Kubernetes, Terraform ani żadnego innego kosmicznego narzędzia. Jeden serwer, jedna komenda, działająca produkcja.

Thruster – wbudowany reverse proxy

Rails 8 zawiera też Thruster – napisany w Go reverse proxy, który zastępuje Nginx. Obsługuje kompresję gzip, cache’owanie assetów, X-Sendfile i automatyczny SSL. Jest wbudowany w domyślny Dockerfile Rails 8, więc nie musisz go osobno konfigurować.

To oznacza, że Twój stack produkcyjny to:

Puma (serwer aplikacji)
Thruster (reverse proxy)
PostgreSQL (baza + cache + kolejki + WebSockety)

Trzy procesy zamiast siedmiu. Jeden serwer zamiast klastra. To jest „one person framework” w praktyce.

Czy to oznacza, że Redis i Sidekiq umarły?

Nie. Redis nadal jest fantastycznym narzędziem, jeśli potrzebujesz jego specyficznych możliwości – zaawansowany pub/sub, Lua scripting, operacje na strukturach danych z nanosekundowymi latencjami. Sidekiq Pro i Enterprise oferują funkcjonalności, których Solid Queue nie ma (np. batched jobs z callbackami, rate limiting na poziomie workerów).

Ale większość aplikacji Rails nie potrzebuje tych funkcjonalności. Większość aplikacji potrzebuje prostych kolejek, prostego cache’u i prostych WebSocketów. I dla tych przypadków Solid Trifecta jest lepsza – bo jest prostsza.

Podsumowanie

Rails 8 to najbardziej opinionated wersja frameworka od lat. Zamiast dawać programistom wybór między dziesięcioma adapterami, mówi: „użyj tego, działa, jest proste”. I w większości przypadków ma rację.

Jeśli zaczynasz nowy projekt w 2025 roku, nie masz powodu, żeby od razu sięgać po Redisa, Sidekiq i Kubernetes. Zacznij z Solid Queue, Solid Cache i Kamal. Dodaj złożoność dopiero wtedy, gdy jej naprawdę potrzebujesz. Nie wcześniej.

Bo jak mówi stare powiedzenie w Rails: convention over configuration. A teraz też: simplicity over infrastructure.

Rails 8 i Solid Trifecta – jak pozbyć się Redisa, Sidekiq i skomplikowanej infrastruktury