Così hai la tua app Rails, e come sai hai controller e azioni e vista e cosa no.
Quando un utente nel browser accede all'app su Heroku, digita l'URL che punta ai server Heroku.
I server Heroku sono server Web che ascoltano gli utenti che digitano l'URL e li collegano all'applicazione Rails. L'applicazione rails fa la sua parte (ottiene un elenco di post di blog o qualsiasi altra cosa) e il server invia queste informazioni al browser dell'utente.
Hai usato un server web per tutto il tempo, solo che è stato estratto da te e reso super semplice grazie a Heroku.
Così il ciclo di vita è un po 'come questo:
Mentre siete stati costruendo le applicazioni sul computer di sviluppo probabilmente avete venire attraverso il comando rails server. Questo avvia un programma chiamato WEBrick che è un server web e ascolta sulla porta 3000. Vai alla tua app tramite http://localhost:3000.
WEBrick ascolta sulla porta 3000 e risponde alle richieste degli utenti, come il comando "hey dammi un elenco di post".
Quando si inserisce il codice in produzione (nella propria esperienza tramite heroku push) si invia il codice a un provider che si occupa dell'equivalente di produzione di rails server.
Una configurazione di produzione (di cui parlano i vostri sviluppatori senior) è un po 'più complessa della vostra installazione locale rails server sul vostro computer di sviluppo.
Nella produzione hai il tuo server Rails (spesso cose come Unicorno, Passeggero) che prende il posto di WEBrick.
In molte impostazioni di produzione, viene utilizzato anche un altro server, ad esempio Apache o nginx, ed è il server a cui l'utente si connette quando accede all'applicazione.
Questo server esiste spesso come un router per capire come gestire i diversi tipi di richieste. Ad esempio, le richieste di file statici (css, immagini, javascript, ecc.) Che sono storted sul server possono essere elaborate direttamente da Apache o nginx, poiché fa un fantastico (e veloce) lavoro di invio di risorse statiche al client.
Altre richieste, ad esempio "ottieni un elenco di tutti i post del blog", vengono trasferite sul server Rails (Unicorno, Passeggero, ecc.) Che a loro volta eseguono il lavoro richiesto e inviano la risposta ad Apache/nginx, che lo invia di nuovo al cliente.
Heroku fa tutto questo per te in un bel pacchetto facile da usare, ma suona come il posto in cui il tuo lavoro lo gestisce da solo, piuttosto che usare Heroku. Hanno creato il proprio gruppo di server Web e faranno a modo loro un equivalente di heroku push che invierà il codice ai server e si assicureranno che siano pronti per rispondere alle richieste degli utenti.
Spero che questo aiuti!
grazie mille per la lunga spiegazione! – Edmund
Grazie. La prima volta che ho letto su Passenger/Unicorn facendo il 'lato rotaie del lavoro del server' e Nginx/Apache facendo l'invio dei file. Fino ad ora ero confuso dal fatto che Nginx fosse lo stesso di Passenger ecc. E perché nel Production fossero necessari due diversi componenti del server. –