Abbiamo una grande applicazione Ruby on Rails (25 milioni di utenti mensili), il nostro management ha deciso di riscrivere in Node.js, sono pazzo?

Per favore dimmi se:

Node.js renderà il nostro sito più veloce!
Node.js consumerà meno risorse del server, possiamo risparmiare denaro!
Node.js ci renderà più produttivi!
Node.js significa che possiamo condividere codice JavaScript lato client e server.

Per chiarire, stiamo riscrivendo un server frontend, che parlerà con la nostra attuale applicazione Ruby on Rails come API. Nel frattempo, trasformeremo la nostra applicazione Ruby on Rails in servizi.

Maggiori dettagli sull'architettura esistente:

Memcached per la cache dei parziali HTML
Redis per sessione e alcuni dati strutturati nella cache
MySQL singolo master, più slave
- C'è un grande tavolo che accetta molte scritture (immagina un sondaggio)
- Altrimenti legge principalmente.
MongoDB per alcuni metadati
Ruby on Rails 3.0
nginx e unicorno

— user88487
fonte

sheesh, tutte queste lingue hipster. Un'applicazione php ben scritta si ridimensionerà facilmente, gli strumenti tradizionali funzionano, non lasciare che questi hipster ti dicano diversamente.

— Darknight,

La domanda dovrebbe essere più sulla falsariga di "I miglioramenti consentiranno di risparmiare abbastanza denaro per il business per renderlo utile?" Potrebbe risparmiare denaro nell'arco di 5 anni, ma la riscrittura è costosa e richiede molto tempo - a meno che il tuo codice non sia un orribile casino terribile, penso che i tuoi manager siano arrabbiati

— Mikey C,

Se si stanno prendendo in considerazione le riscritture, si potrebbe anche considerare di spostare il proprio front-end in javascript lato client, il che significa che non si avrebbe più un server front-end dinamico, solo file statici.

— Joeri Sebrechts,

@Darknight ricorda che a un certo punto PHP era il linguaggio hipster e che le persone che lo mostravano potevano essere implementate in prodotti di successo ne promuovevano l'adozione, mentre gli sviluppatori Web Perl stavano ridacchiando agli hipsters PHP.

Sono molto sorpreso che nessuno abbia sollevato l'articolo di Joel Spolsky. Cose che non dovresti mai fare . Non sto dicendo che tutte le riscritture siano sbagliate, ma sono d'accordo con @MikeyC che dovrebbero essere affrontate con estrema cautela.

— Dan Pichelman,

Risposte:

La maggior parte delle domande che poni non sono rispondenti senza contesto e sono più o meno discutibili dato che la direzione ha già fatto la scelta per te ... a meno che tu non ti stia chiedendo "dovrei uscire e trovare un nuovo lavoro di fronte a tutto questo cambiamento ?'

Se hai intenzione di metterti alla prova, ti consiglio di leggere questo post sull'argomento: Come sopravvivere a una riscrittura radicale senza perdere la sanità mentale .

Di recente ho iniziato il percorso di riscrittura di un po 'di logica del server in node.js. Il motivo principale è che è attualmente scritto in .NET e vogliamo migrare lontano dagli ambienti MS lungo la strada.

Le mie esperienze finora sono state positive, avrai una curva di apprendimento iniziale con tutta la sua non-bloccabilità, ma una volta superato che in realtà è abbastanza divertente codificare .. Lo so, DIVERTIMENTO!

Ha un lato oscuro, però, ogni uomo e il suo cane che hanno fatto uno sviluppo del front-end con JavaScript - e che sarebbe ogni sviluppatore di front-end che spero - si eccitano un po 'quando dici che node.js è' javascript lato server 'tuttavia ciò non significa che gli sviluppatori front-end avranno l'esperienza richiesta per scrivere buone app lato server.

Per prima cosa hai considerato è che un errore fatale farà cadere l'intera app a causa della sua natura non thread, quindi la posta in gioco è un po 'più alta e devi controllare e catturare esplicitamente tutto.

Per coloro che hanno fatto sia il fronte che il retro - e si divertono entrambi - non dover cambiare i contesti mentali dalle lingue front-end a back-end è un vero vantaggio che penso aumenterà in definitiva la produttività del nostro team lungo la strada.

— dave.zap
fonte

"Per prima cosa hai considerato è che un errore fatale farà cadere l'intera app a causa della sua natura non thread, quindi la posta in gioco è un po 'più alta e devi controllare e catturare esplicitamente tutto" - Questa sarebbe la mia preoccupazione.

— Tentimes

Sì, il mio punto principale con questa affermazione era che solo gli sviluppatori front end non sono particolarmente esigenti quando si tratta di gestire le eccezioni. Dai, è già quasi il 2017!

— dave.zap,

Bene, non penso che riscrivere l'applicazione sia stata una buona idea a meno che non funzionasse male. Per rispondere alle tue domande:

Node.js non è magico. La tua applicazione ha un'enorme quantità di utenti, quindi non c'è modo di essere certi che la renderà più veloce.
Bene, sì, Node.js consuma infatti meno risorse del server. Quindi non solo puoi risparmiare denaro sulle risorse, ma puoi anche fare di più con quelli esistenti. Ciò è principalmente dovuto alla natura a thread singolo di Node.js. Non vi è sovraccarico di thread aggiuntivi.
Ancora una volta Node.js non è magico. Detto questo, potrebbe esserci della verità in questo. Node.js ha una comunità molto attiva che ha creato centinaia di moduli per ogni possibile attività. Quindi è abbastanza probabile che la maggior parte del lavoro sia stata fatta per te. Devi solo mettere insieme i pezzi.
Teoricamente si. Poiché Node.js è JavaScript, è possibile condividere il codice tra client e server. Ma non so esattamente cosa verrà condiviso. Non ho scritto alcun codice riutilizzabile su un client. Le cose che facciamo sul server di solito non hanno nulla a che fare con il client. Più importante per me è la mancanza di cambio di contesto. Trovo più facile programmare codice sia su client che su server in una sola lingua.

Poiché Node.js è a thread singolo, a meno che non sia configurato esplicitamente per farlo, non può sfruttare più CPU .

Dai un'occhiata anche ai commenti. Forniscono alcune buone informazioni sul funzionamento di Node.js.

— Akshat Jiwan Sharma
fonte

Meno risorse a causa di un singolo thread? Cosa pensi che farebbero quei fili extra?

— Joe,

@Joe, per quanto ho capito, si sommeranno. Nel nodo js è una buona pratica eliminare una richiesta il più rapidamente possibile. O completandola in una volta sola o riprendendola la prossima volta. Per essere onesti nodo js è l'unica tecnologia per cui ho realizzato applicazioni di produzione, quindi potrei non essere la persona migliore per confrontarla con altre tecnologie lato server. Per questo motivo mi sono trattenuto dal fare confronti e ho semplicemente messo ciò che penso di sapere sul nodo js la mia risposta.

— Akshat Jiwan Sharma,

Sì, un singolo thread certamente limita l'utilizzo delle risorse, perché il server può fare solo una cosa alla volta sul loop degli eventi. Limita anche l'uso del server, perché può fare solo una cosa alla volta. È molto importante citare funzioni (a thread singolo) e lati positivi e negativi piuttosto che solo aspetti positivi. Node.js è adatto per alcuni usi ma è una cattiva idea per altri. Quando il server del nodo a thread singolo presenta problemi di capacità, potrebbe essere necessario aggiungere un'altra istanza del nodo. Ora hai un server multi-processo.

— Joe,

Capisco cosa intendi. Aggiornerò la risposta a breve (leggi dopo alcune ricerche)

— Akshat Jiwan Sharma,

Non si tratta solo di CPU. Il motivo per cui è importante gestire ogni richiesta il più rapidamente possibile (in un sistema a thread singolo senza altra concorrenza) è perché il server non può soddisfare più richieste contemporaneamente, quindi ogni richiesta deve attendere fino al termine della gestione di tutti le richieste prima di esso. La concorrenza, fatta bene, significa meno attesa. L'uso dei thread non è intrinsecamente un drenaggio delle prestazioni e il single threadingness (per impostazione predefinita o meno) non è un vantaggio in termini di prestazioni.

— Peter Hosey,