Skip to content
← Wszystkie wpisy
4 min czytania Dawid Skłodowski

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.