Rails 5.1: Webpacker, yarn i szyfrowane sekrety
Rails 5.1 zawiera pokój z nowoczesnym JavaScriptem i zaostrza zarządzanie sekretami. Przegląd wydania — Webpacker i yarn, szyfrowane sekrety, testy systemowe, form_with i porzucenie jQuery jako domyślnego.
Rails 5.1 to wydanie wyraźnie patrzące na zewnątrz. Tam, gdzie 5.0 było o trybie API i ActionCable, 5.1 zwraca się ku dwóm rzeczom, które społeczność obchodziła gemami i konwencjami latami: relacji z nowoczesnym JavaScriptem i bezpiecznym zarządzaniu sekretami. Wnosi też prawdziwe testowanie przeglądarki do frameworka i porządkuje formularze. Przenieśliśmy aplikacje; oto co ma znaczenie.
Webpacker i yarn: pokój z JavaScriptem
Nagłówkiem jest to, że Rails oficjalnie obejmuje nowoczesny toolchain JavaScriptu. Webpacker — integracja Webpacka — dostarcza się jako wspierana opcja, a yarn staje się sposobem zarządzania zależnościami JavaScriptu. To rozwiązanie napięcia, które omawialiśmy, gdy asset pipeline zaczął się napinać: zamiast walczyć z nowoczesnym JS przez Sprockets, Rails daje ci teraz pierwszoklasową ścieżkę do Webpacka dla aplikacjopodobnego frontu, trzymając Sprockets do reszty.
rails new myapp --webpack=react # scaffolduje Webpacker + React, zarządzane yarnem
Pragmatyczny kształt jest niezmieniony: Webpacker obsługuje twój prawdziwy kod frontu (zależności npm, moduły, komponenty), Sprockets obsługuje CSS i posypany JavaScript, a oba współistnieją. Co 5.1 zmienia, to że jest to teraz błogosławiona ścieżka, z generatorami i defaultami, a nie doczepką od strony trzeciej. Dla zespołów budujących cokolwiek mocno frontowego na Rails to oficjalne wsparcie usuwa sporo tarcia konfiguracji i niepewności.
Powiązane, jQuery nie jest już domyślną zależnością. Latami każda nowa aplikacja Rails dostarczała się z jQuery; 5.1 wyrzuca je z defaultów, odzwierciedlając, że nowoczesny JavaScript (i własne nieobtrusywne skrypty Rails) już go nie potrzebuje. Wciąż możesz je dodać, ale framework już go nie zakłada — mały, lecz wymowny znak tego, dokąd przesunął się front.
Szyfrowane sekrety
Nagłówkiem bezpieczeństwa są szyfrowane sekrety. Wcześniej config/secrets.yml
dokumentował nazwy twoich sekretów, ale trzymał wartości produkcyjne w ENV, bo plik jest
commitowany w postaci jawnej. 5.1 pozwala commitować same sekrety, zaszyfrowane:
rails secrets:setup # generuje config/secrets.yml.enc i klucz główny
rails secrets:edit # deszyfruje, otwiera w edytorze, ponownie szyfruje przy zapisie
Zaszyfrowany plik (secrets.yml.enc) jest bezpieczny do commitowania; jest nieczytelny bez
klucza głównego, który trzymasz poza repo (w RAILS_MASTER_KEY na serwerach). To naprawdę
miły model: twoje sekrety są wersjonowane obok kodu — więc wdrażają się razem, nie mogą
zdryfować, a nowe środowisko potrzebuje tylko jednego klucza głównego — pozostając
zaszyfrowane w spoczynku. To fundament, który wyrośnie w pełniejszy system credentials w
późniejszym Rails, a przyjęcie go teraz daje ci zarządzanie sekretami, które jest zarazem
wygodne i bezpieczne. (Chroń klucz główny jak wytrych, którym jest: kto go ma, ma każdy
sekret.)
Testy systemowe: prawdziwe testowanie przeglądarki w pudełku
5.1 wnosi testy systemowe do Rails — wsparte Capybarą, pełnoprzeglądarkowe testy integracyjne jako pierwszoklasowa, generowana część frameworka, z prawdziwym sterownikiem przeglądarki (headless Chrome) skonfigurowanym od ręki:
# test/system/checkout_test.rb
class CheckoutTest < ApplicationSystemTestCase
test "klient może ukończyć checkout" do
visit new_cart_path
# ... przeprowadź prawdziwą przeglądarkę przez przepływ ...
assert_text "Dziękujemy za zamówienie"
end
end
Latami testowanie przeglądarki oznaczało złożenie Capybary, sterownika i sterty konfiguracji samodzielnie. Posiadanie tego wygenerowanego i wspieranego — w tym automatycznych zrzutów ekranu przy porażce — obniża barierę do testowania części aplikacji, które psują się tylko w prawdziwej przeglądarce. Stosują się zwykłe ostrożności (omówione we wcześniejszych wpisach: trzymaj ich mało, są wolne, zarządzaj strategią DatabaseCleaner), ale usankcjonowana, gotowa konfiguracja to realna poprawa.
form_with: jeden helper formularzy, by rządzić wszystkimi
Mniejsza, lecz mile widziana unifikacja: form_with zastępuje długo mylącą parę form_tag
(dla formularzy bez modelu) i form_for (dla formularzy z modelem) pojedynczym helperem
obsługującym oba:
<%= form_with model: @product, local: true do |f| %>
<%= f.text_field :name %>
<%= f.submit %>
<% end %>
<%= form_with url: search_path, method: :get do |f| %>
<%= f.text_field :q %>
<% end %>
Jeden helper, wsparty modelem albo URL, z Ajaksem-domyślnie (wybierasz local: true dla
standardowego wysłania). Usuwa wahanie „którego helpera formularza użyć?” i jest API
formularzy idącym naprzód.
Werdykt
Rails 5.1 to framework wchodzący w krok z dwiema rzeczywistościami, które obchodził. Webpacker
i yarn czynią nowoczesny toolchain JavaScriptu pierwszoklasową, wspieraną ścieżką zamiast
obejściówki gem-i-konwencja — a porzucenie jQuery z defaultów po cichu potwierdza kierunek.
Szyfrowane sekrety dają ci wersjonowane, zaszyfrowane w spoczynku zarządzanie sekretami, które
wdraża się z kodem i nie może zdryfować. Testy systemowe wnoszą prawdziwe testowanie
przeglądarki do pudełka, a form_with porządkuje długotrwałą brodawkę. Nic z tego nie jest
ryzykowne do przyjęcia: weź Webpacker tam, gdzie twój front go potrzebuje, migruj do
szyfrowanych sekretów w swoim czasie i ciesz się porządkami. To pewne, modernizujące wydanie,
które czyni Rails wygodniejszym domem dla mocno javascriptowych, świadomych bezpieczeństwa
aplikacji 2017.