Rails 5 nadszedł: tryb API, ActionCable i ujednolicona komenda

Rails 5 osiągnął release candidate, a finałowe wydanie jest bliskie. To największy skok wersji od jakiegoś czasu i — w przeciwieństwie do stałych wydań punktowych linii 4.x — wnosi parę naprawdę strategicznych dodatków: pierwszoklasowy tryb API i ActionCable — obok porcji mniejszych zmian dotykających codzienny kod. Uruchamialiśmy bety; oto przegląd tego, co naprawdę ma znaczenie.

Tryb API: Rails dla backendów JSON

Nagłówkową strategiczną zmianą jest tryb --api. Wzrost aplikacji jednostronicowych i klientów mobilnych oznacza, że wiele nowych aplikacji Rails to czyste backendy JSON bez żadnych widoków renderowanych po stronie serwera — a ciągnięcie pełnego stosu middleware (ciasteczka, sesje, flash, renderowanie widoków) na tę przejażdżkę było marnotrawne. Rails 5 czyni API-only pierwszoklasowym wyborem:

rails new my_api --api

To generuje szczuplejszą aplikację: przyciętym stosem middleware, ActionController::API zamiast ActionController::Base (bez warstwy widoków, bez ciasteczek domyślnie) i generatorami, które nie scaffoldują widoków. Dostajesz części Rails, których naprawdę chcesz dla API — routing, kontrolery, ActiveRecord, ekosystem — bez ciężaru części, których nie chcesz. To Rails uznający oficjalnie, że „backend za frontem JS/mobilnym” to teraz podstawowy przypadek użycia, a nie dodatek po fakcie. Dla zespołów budujących SPA wobec API Rails to właściwy domyślny wybór.

ActionCable: czas rzeczywisty w pudełku

Drugim strategicznym dodatkiem jest ActionCable, wnoszący WebSockety do Rails z tymi samymi modelami, uwierzytelnieniem i konwencjami co wszystko inne. Jest na tyle ważny, że zasługuje (i dostał) własne opracowanie, więc nie powtórzę tu szczegółów — ale należy na każdą listę powodów, dla których Rails 5 ma znaczenie. Razem z trybem API sygnalizuje odpowiedź Rails na mocno javascriptowy, czasu rzeczywistego web: możesz zbudować API i kanał na żywo w tym samym frameworku, który już znasz.

ApplicationRecord: miejsce na współdzielony kod modeli

Mała, ale urocza zmiana. Tak jak kontrolery zawsze dziedziczyły z twojego własnego ApplicationController, modele teraz dziedziczą z ApplicationRecord:

# app/models/application_record.rb
class ApplicationRecord < ActiveRecord::Base
  self.abstract_class = true
end

class Post < ApplicationRecord
end

Latami „chcę tego zachowania na wszystkich moich modelach” oznaczało monkey-patching samego ActiveRecord::Base — ponowne otwieranie klasy frameworka, dotykające każdy model w każdym gemie też. ApplicationRecord daje ci czystą, należącą do aplikacji klasę bazową na współdzielone concerny, scope’y i helpery, bez dotykania frameworka. To oczywista rzecz, która zawsze powinna była istnieć, a teraz istnieje.

Attributes API

Po cichu potężny dodatek: możesz teraz deklarować typowane atrybuty na modelu, w tym takie niewsparte kolumną bazy, i kontrolować, jak wartości są rzutowane:

class Product < ApplicationRecord
  attribute :price_in_cents, :integer
  attribute :discount, :decimal, default: 0
  attribute :published_at, :datetime
end

To formalizuje rzutowanie typów, daje wirtualnym atrybutom prawdziwy dom, a nawet pozwala definiować własne typy. To fundament dla czystszych obiektów formularzy i obsługi wartości i usuwa sporo doraźnego kodu attr_accessor-plus-ręczne-rzutowanie, który aplikacje kiedyś nosiły.

belongs_to jest wymagane domyślnie

Zmiana, która zaskoczy cię przy aktualizacji, jeśli nie jesteś gotowy: asocjacje belongs_to są teraz wymagane domyślnie. Wcześniej rekord mógł być zapisany z nil kluczem obcym dla belongs_to; teraz to zawodzi walidację, chyba że powiesz inaczej:

class Comment < ApplicationRecord
  belongs_to :post                      # teraz wymagane — komentarz MUSI mieć post
  belongs_to :author, optional: true    # zrezygnuj jawnie, gdy nil jest poprawny
end

To dobry domyślny wybór — większość belongs_to naprawdę nie powinna być nil, a stare zachowanie pozwalało osieroconym rekordom się przemknąć. Ale to zepsuje istniejące aplikacje, które polegały na opcjonalnych asocjacjach, więc to pierwsza rzecz do sprawdzenia przy aktualizacji. Dodaj optional: true tam, gdzie nil jest prawowicie dozwolony.

rails połyka rake

Zmiana workflow, którą zauważysz natychmiast: komenda rails wchłania teraz rake. Możesz uruchamiać rails db:migrate, rails test, rails routes — zadania, które kiedyś wymagały rake, teraz działają też pod rails:

rails db:migrate      # było: rake db:migrate
rails db:seed
rails routes          # było: rake routes

rake wciąż działa, ale ujednolicenie wszystkiego pod jedną komendą usuwa wieczne wahanie „to rake czy rails?”. Małe, ale docenisz to codziennie.

Mniejsze dodatki

Jeszcze kilka wartych wiedzy: Turbolinks 5 to znaczące przepisanie zasilające też adapter aplikacji natywnych; ActionController::Renderer pozwala renderować szablony poza kontrolerem (przydatne do renderowania w zadaniach w tle albo broadcastach ActionCable); tokeny CSRF per formularz zaostrzają bezpieczeństwo; i jest zwykłe porządkowanie z deprecjacjami. Minimalne Ruby to teraz 2.2.2, więc upewnij się, że twój runtime jest aktualny przed aktualizacją.

Werdykt

Rails 5 to znaczące wydanie, nie rutynowe. Tryb API i ActionCable są strategiczne — to Rails pozycjonujący się pod javascriptowo-frontowy, czasu rzeczywistego, mobilno-backendowy świat, który stał się normą, i czynią Rails wiarygodnym wyborem dla tych architektur, a nie reliktem renderowanym po stronie serwera. Codzienne zmiany — ApplicationRecord, attributes API, ujednolicona komenda rails — to rodzaj usprawnień jakości życia, które czynią framework przyjemniejszym do życia. Jedyną rzeczą do zaplanowania przy aktualizacji jest wymagane belongs_to; przejrzyj najpierw swoje opcjonalne asocjacje. Poza tym to pewne, patrzące w przód wydanie i łatwe do polecenia, by na nie przejść.