prism

Framework webowy w Ruby oparty wyłącznie o bibliotekę standardową - bez zewnętrznych gemów. Router, warstwa kontrolerów, plikowy ORM z migracjami, layouty i partiale.

TL;DR

Framework webowy w Ruby zbudowany wyłącznie na bibliotece standardowej. Zero zewnętrznych gemów: własny router, warstwa kontrolerów, plikowy ORM z migracjami, layouty i partiale. Wszystko to, co zwykle bierzesz z Rails, napisane od zera po to, żeby zrozumieć, jak to naprawdę działa.

Wprowadzenie

Rails jest świetny, ale kiedy przez lata tylko go używasz, łatwo zapomnieć, jak działa pod spodem. prism to świadome zejście o poziom niżej: nie ma tu ani jednego zewnętrznego gemu, więc każdy element trzeba było zrozumieć na tyle dobrze, żeby go samemu napisać. Routing, dispatch do kontrolera, renderowanie widoku, warstwa danych.

Efektem jest mały framework, który realnie serwuje aplikację, i jednocześnie mapa tego, co konkurencja robi za zasłoną. To nie makieta frameworka, tylko działająca całość, w której każda warstwa jest na wyciągnięcie ręki, bo napisałeś ją własnoręcznie.

Router, który sam rozwikłuje ścieżkę

Serce każdego frameworka webowego to decyzja, który kod obsłuży dane żądanie. W prism ta decyzja jest jawna: deklarujesz trasy, a router dopasowuje metodę i ścieżkę do pary kontroler plus akcja, wyciągając po drodze parametry z segmentów adresu. Nie ma tu magii, jest tablica reguł czytana z góry na dół.

Kiedy sam piszesz dispatch, przestaje on być czarną skrzynką. Widzisz dokładnie, gdzie ścieżka zamienia się w wywołanie metody, i to ta sama wiedza, której brakuje, gdy framework robi to za ciebie.

routes.rb · ruby

Prism::Router.draw do
  get "/posts", to: "posts#index"
  get "/posts/:id", to: "posts#show"
  post "/posts", to: "posts#create"
end

Warstwa danych i widoku bez ukrytej sklejki

Zamiast wpinać Postgresa, prism trzyma dane w plikach i dokłada do tego migracje oraz proste zapytania. To wystarcza, żeby pokazać całą pętlę: definiujesz model, robisz migrację, zapisujesz rekord i odczytujesz go w kontrolerze. Baza danych schodzi z pola widzenia, a na wierzchu zostaje sam kształt tego, jak ORM mapuje rekordy na obiekty.

Ograniczenie do plików nie jest brakiem, tylko decyzją. Dzięki niemu warstwa danych mieści się w głowie w całości i nie chowa żadnego kroku za sterownikiem bazy, którego i tak nie widać.

Renderowanie widoku wygląda na trywialne, dopóki nie spróbujesz złożyć go z warstw. prism ma layouty, w które wstrzykiwana jest treść akcji, i partiale, które składają powtarzalne kawałki. Dokładnie ten sam mechanizm, który w dużych frameworkach dzieje się niewidocznie, tu jest jawną funkcją, którą sam napisałeś.

➜

Wskazówka

Kiedy wszystko jest napisane ręcznie, debugowanie polega na czytaniu własnego kodu, a nie na zgadywaniu, co robi framework. To najważniejsza korzyść z takiego ćwiczenia: znika warstwa, której działania musisz się domyślać.

Mapa tego, co Rails chowa za zasłoną

Największy zysk z prism nie jest samym frameworkiem, tylko tym, co zostaje w głowie po jego napisaniu. Router, kontrolery i ORM razem zamykają się w kilkuset liniach czytelnego Ruby, a każda z tych linii odpowiada jakiemuś kawałkowi, który Rails robi za zasłoną. Po tym ćwiczeniu duży framework przestaje być magią i staje się zestawem decyzji, które rozumiesz.

Skąd zwykle, a skąd w prism

Element	Zwykle z półki	W prism
Routing	Rails	własny router od zera
Warstwa danych	ActiveRecord	plikowy ORM z migracjami
Widoki	ActionView	layouty i partiale ręcznie
Zależności	dziesiątki gemów	zero, sama stdlib

Więcej projektów

Inne realizacje z tej samej kategorii - zobacz, jak podchodzimy do podobnych wyzwań.

Masz podobny projekt?

Napisz do nas - wycena jest bezpłatna i wraca w godzinę.