Tworzenie aplikacji webowej w Ruby bez frameworka [closed]

Czy możliwe jest stworzenie aplikacji internetowej w Rubim bez użycia frameworka?

Za długo; nie przeczytałem

Tak, to jest zdecydowanie możliwe. Większość frameworków Ruby jest zbudowana z czystego Ruby na bazie innych bibliotek oprogramowania pośredniczącego, takich jak interfejsy serwerów WWW.

Ruby and the Web

Ruby jest językiem ogólnego przeznaczenia, dlatego nie jest specjalnie przeznaczony do tworzenia stron internetowych. PHP, na przykład, jest język, który został napisany do tworzenia aplikacji internetowych. W Rubim będziesz potrzebował pewnych bibliotek, aby poprawnie obsługiwać nagłówki HTTP i elementy specyficzne dla sieci.

Na przykład w Pythonie (innym generycznym języku programowania) mamy standardową specyfikację interfejsu serwera www o nazwie WSGI (interfejs bramy serwera www). Każdy serwer, który implementuje specyfikację WSGI nazywa się WSGI-compatible . I każdy serwer kompatybilny z WSGI może działać tak samo WSGI Python script w ten sam sposób.

Dlaczego ci to mówię, mówiąc o Ruby? Ponieważ Ruby ma bardzo podobną koncepcję do WSGI, z możliwym wyjątkiem, że nie jest Jeszcze standardem. Jego nazwa toRack i zapewnia interfejs do radzenia sobie z typowymi niskopoziomowymi rzeczami HTTP/serwerowymi, których nie chcesz zajmować się samemu, abyśmy mogli używać Ruby tak, jakbyśmy używali PHP .

Ruby, Rack i Apache

Weźmy prawdziwy przykład życia: Apache. Apache jest jednym z najczęstszych serwerów internetowych. Jak działa PHP z Apache? Z mod_php. Jak aplikacje kompatybilne z Pythonem WSGI współpracują z Apache? Z mod_wsgi. Jak aplikacje kompatybilne z Ruby Rack współpracują z Apache? Z mod_rack. Widzisz wzór? Serwer WWW musi wiedzieć, jak prawidłowo połączyć aplikację z kontekstem webowym żądania / odpowiedzi.

Przykład Rack

Bez zajmowania się tym abstrakcyjnym dyskusja, skupmy się na przykładzie:

class HelloWorld
    def call(env)
        [200, {"Content-Type" => "text/plain"}, ["Hello world!"]]
    end
end

[12]} ten przykład jest dostarczany przez witrynę Rack i wyjaśnia, w jaki sposób działa skrypt kompatybilny z Rack: [13]}

Na serwerze internetowym można zainstalować wiele samouczków (w Google znajdziesz wiele samouczków związanych z Twoim serwerem internetowym).]}
• tworzysz config.ru plik w folderze głównym (.ru jest głównie Ruby)
• wklejasz ten skrypt
• uruchamiasz go metodą run

Et voilà , mamy interfejs serwera www. env hash zawiera zmienną środowiskową z bieżącego żądania, a zwracana tablica zawiera 3 komponenty:

1. status odpowiedzi. 200 oznacza "wszystko jest w porządku". 404 oznacza "nie znaleziono". I tak dalej.
2. nagłówek HTTP . Opisują one ciało odpowiedzi. Jego długość. Jego treść. I tak dalej.
3. ciało odpowiedzi . Zawiera on rzeczywisty wynik Twojej aplikacji. HTML, JSON, XML, HXML, prosty tekst... nieważne.

Na przykład w PHP wszystko to odbywa się automagicznie. Po wykonaniu echo "Hello"; status odpowiedzi i nagłówki są generowane przez interpreter PHP.

Uwaga o alternatywach

Możesz kopać w tej dziedzinie, ile chcesz, ale większość wymienionych poniżej technologii jest przestarzała lub ich użycie jest wysoce zniechęcane przez społeczność.

W pierwszych latach istnienia sieci było common interfejs używany do uruchamiania skryptów Perl, Python, Ruby, C po stronie serwera: CGI lub Common Gateway Interface. Jest to interfejs, który może być używany przez prawie każdy język programowania, ale jest ogólnie uważany za powolny.

Niektórzy myśleli, aby ożywić ten interfejs, czyniąc go szybszym. I z tego, zgadnij co, powstał FCGI , lub FastCGI. Ta technologia jest używana częściej niż mogłoby się wydawać. Niektóre skrypty PHP są konwertowane do FCGI Skrypty czasami, aby je uruchomić szybciej. Nie chcę iść dalej w tym temacie, ponieważ istnieje wiele innych odniesień.

I wreszcie, można stworzyć własny serwer WWW. W rzeczywistości nie jesteś zmuszony do tworzenia serwera www za pomocą Rubiego, aby używać Rubiego. Teoretycznie rzecz biorąc, serwer WWW jest tak prosty jak:

W tym celu należy wykonać następujące czynności:]}
1. załatw sprawę z żądaniem
2. wyjście odpowiedź
3. goto 1

W realnym środowisku nie chcesz samodzielnie wdrażać serwera www do stron produkcyjnych. Więc zdecydowanie odradzam to.

A jeśli tak, to dlaczego frameworki są wybierane przez większość programistów ruby?

Plusy

[12]}frameworki służą do szybkiego rozwoju. Jeśli masz terminy, nie chcesz zajmować się sprawami niskopoziomowymi i chciałbyś framework build -blog polecenie, które zarządza jak największą ilością nudnych rzeczy i pozwala skupić się na prawdziwym projekcie aplikacji.

Frameworki są zazwyczaj open source i mają duże społeczności, co pomaga w szybkim ulepszeniu frameworka. Możesz łatwo zrozumieć, że błąd w kodzie widziany przez 10.000 par oczu znajduje się 10.000 razy szybciej niż kod, który piszesz dla siebie.

Wady

Niektóre frameworki mogą być zbyt duże dla Twoich potrzeb, a inne mogą być zbyt małe. W Rubinie / align = "center" bgcolor = "# e0ffe0 " / Cesarz Chin / / align = center / Jeden jest ogromny, a drugi jest bardzo mały i naprawdę zejdzie Ci z drogi. Czasami chcesz coś pomiędzy.

Frameworki są zazwyczaj bardzo ogólne. Oznacza to, że musisz skonfigurować rzeczy, które wydają się oczywiste dla Twojego kontekstu.

Frameworki zawierają więcej kodu niż potrzebujesz. Jest to fakt, który możesz sam wydedukować. Oznacza to zwykle większą złożoność i bezpośrednio więcej błędów (chociaż jest to rekompensowane przez ogromną społeczność wokół nich).