2013-04-08 9 views
7

Desidero creare un'app Web in Ruby ma non so se è possibile farlo senza dover utilizzare un framework. Non so perché la maggior parte degli sviluppatori di Ruby usa un framework come Rails o Sinatra.Creazione di un'app Web in Ruby senza un framework

Come si configura un'applicazione web Ruby che non si basa su un framework esistente?

+1

Ovviamente è possibile. Rails è scritto in Ruby. Se ne scrivi un equivalente all'interno della tua app, deve funzionare allo stesso modo. – sawa

+0

Si può persino scrivere in linguaggio C, assemblatore o macchina. Perché hai scelto di scrivere in Ruby e non in queste lingue? – sawa

+4

Questa domanda è attualmente in fase di discussione [discussa su Meta] (http://meta.stackexchange.com/questions/176134/why-is-questo-questo-diritto-dispositivo-di-serie-considerato-not-costruttivo) – LittleBobbyTables

risposta

78

È possibile creare un'app Web in ruby ​​senza utilizzare un framework?

Troppo lungo; Non letto

Sì, è sicuramente possibile. La maggior parte dei framework Ruby sono costruiti con puro Ruby su altre librerie middleware come le interfacce web server.

Ruby e il Web

Ruby è un linguaggio general purpose; quindi non è nello specifico progettato per lo sviluppo web. PHP, ad esempio, è un linguaggio che è stato scritto per creare applicazioni web. In Ruby stai andando a bisogno di alcune librerie per gestire correttamente le intestazioni HTTP e gli elementi specifici del web.

In Python, ad esempio, (un altro linguaggio di programmazione generico) abbiamo una specifica di interfaccia del server Web standard denominata WSGI (Interfaccia gateway server Web). Ogni server che implementa le specifiche WSGI è chiamato compatibile con WSGI. E qualsiasi server compatibile con WSGI può eseguire lo stesso script WSGI Python nello stesso modo.

Perché te lo sto dicendo quando parli di Ruby? Perché Ruby ha un concetto molto simile a WSGI, con la possibile eccezione che non è eppure uno standard. Il suo nome è Rack e fornisce un'interfaccia per gestire i comuni file HTTP/server di basso livello che non desideri gestire autonomamente, in modo da poter utilizzare Ruby come se stessimo utilizzando PHP.

Ruby, Rack e Apache

Prendiamo un esempio reale di vita: Apache. Apache è uno dei server web più comuni là fuori. Come funziona PHP con Apache? Con mod_php. In che modo le applicazioni compatibili con Python WSGI funzionano con Apache? Con mod_wsgi. In che modo le applicazioni compatibili con Ruby Rack funzionano con Apache? Con mod_rack. Riesci a vedere il modello qui? Il server Web deve sapere come collegare correttamente la tua applicazione al contesto web richiesta/risposta.

esempio Rack

senza affrontare, inoltre, in questo discorso astratto, concentriamoci su un esempio:

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

Questo esempio è fornito dal sito Rack e spiega come uno script Rack-compatibile corre:

  • Si installa rack sul server Web (sono disponibili numerosi tutorial su Google specif IC al server web)
  • Si crea un file config.ru nella cartella principale (.ru è principalmente Ruby)
  • si incolla che lo script
  • Si esegue con la run metodo

Et voilà, abbiamo un'interfaccia web server. Il env hash contiene la variabile d'ambiente dalla richiesta corrente e la matrice si sta tornando contiene 3 componenti:

  1. lo stato della risposta. 200 sta per "Tutto è ok". 404 sta per "Non trovato". E così via.
  2. L'intestazione HTTP. Questi descrivono il corpo della risposta. La sua lunghezza Il suo contenuto E così via.
  3. Il corpo di risposta. Questo contiene l'output effettivo della tua applicazione. HTML, JSON, XML, HXML, testo semplice ... qualunque cosa.

In PHP, ad esempio, tutto questo viene fatto automaticamente. Quando esegui lo echo "Hello"; lo stato della risposta e le intestazioni vengono generati per te dall'interprete PHP.

Una nota sulle alternative

Si può scavare in questo campo tutto quello che volete, ma la maggior parte delle tecnologie elencate di seguito sono sia disapprovato o il loro utilizzo è altamente sconsigliato dalla comunità.

Nei primi anni del web c'è stata una comune interfacciautilizzato per eseguire il Perl, Python, Ruby, scrips C nel lato server: CGI o Common Gateway Interface. Questa è un'interfaccia che può essere utilizzata praticamente da qualsiasi linguaggio di programmazione, ma è generalmente considerata lenta.

Alcuni pensano di far rivivere questa interfaccia rendendola più veloce. E da quello, indovina un po ', è nato FCGI o FastCGI. Questa tecnologia è usata più spesso di quanto si possa pensare. Alcuni script PHP vengono convertiti in script FCGI a volte per farli girare più velocemente. Non voglio andare oltre su questo argomento, poiché ci sono molti altri riferimenti là fuori.

E infine, è possibile creare il proprio server web. In realtà non sei obbligato a creare il server web con Ruby per usare Ruby.Teoricamente parlando, un web server è semplice come:

  1. ascolto su una porta (80 la maggior parte del tempo) fino a quando arriva una richiesta
  2. Gestione della richiesta
  3. uscita la risposta
  4. goto 1

Nell'ambiente di vita reale, non si desidera implementare il server Web per siti Web di produzione. Quindi lo scoraggio decisamente.

E se sì, perché i framework scelti dalla maggior parte degli sviluppatori di ruby ​​web?

I pro

quadri hanno lo scopo di rendere il vostro rapido sviluppo. Se hai scadenze, non vuoi occuparti di cose di basso livello e ti piacerebbe un comando framework build -blog che gestisca quante più cose noiose per te come puoi e ti concentri sul vero design dell'applicazione.

I framework sono in genere open source e hanno grandi comunità che aiutano a rendere il framework più veloce. Puoi facilmente capire che un bug nel codice visto da 10.000 paia di occhi si trova 10.000 volte più veloce del codice che scrivi per te stesso.

I contro

Alcuni quadri normativi potrebbe essere troppo grande per le vostre esigenze e di altri potrebbe essere troppo piccolo. Nel contesto Ruby ci sono le enormi Rails e il suo fratellino Sinatra. Uno è enorme e l'altro è molto piccolo e ti toglie di mezzo. A volte vuoi qualcosa in mezzo.

I quadri sono in genere molto generici. Ciò significa che devi configurare cose che sembrano ovvie per il tuo contesto.

I quadri contengono più codice di quanto necessario. Questo è un fatto che puoi dedurre da solo. Questo di solito significa più complessità e direttamente altri bug (anche se questo è compensato dalla grande comunità che li circonda).

+2

Grazie mille tanto! Questo è stato davvero utile e ti ha richiesto molto tempo per scrivere. –

+3

Che bella risposta! È un peccato che la domanda sia chiusa perché questo merita un sacco di voti positivi. –

+1

La chiusura non ferma i upvotes @JustinEthier. – yannis