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

La maggior parte delle domande che chiedi non sono rispondenti senza contesto, e sono più o meno dati che la gestione ha già fatto la scelta per te ... a meno che tu non stia chiedendo "dovrei smettere e trovare un nuovo lavoro di fronte a tutto questo cambia? '

Se stai andando duro, ti consiglio di leggere questo post sull'argomento: Come sopravvivere a un riscrittura di base senza perdere la sanità mentale .

Recentemente 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 stiamo cercando di migrare lontano dagli ambienti MS.

Le mie esperienze fino ad ora sono state positive, avrai una curva di apprendimento iniziale con tutto il non-blocco di esso, ma una volta superato che è in realtà abbastanza divertente da codificare .. Lo so, DIVERTENTE!

Tuttavia, ha un lato oscuro, ogni uomo e il suo cane che ha fatto un po 'di sviluppo front-end con JavaScript - e questo dovrebbe essere ogni sviluppatore front-end che spero - si eccita un po' quando si dice che node.js è " lato server javascript 'tuttavia ciò non significa che gli sviluppatori front-end avranno l'esperienza necessaria per scrivere buone applicazioni lato server.

Per una cosa che hai considerato è che un errore fatale farà cadere l'intera app a causa della sua natura non threaded, quindi le puntate sono un po 'più alte e devi controllare e catturare tutto in modo esplicito.

Per quelli che hanno fatto fronte e retro - e si divertono entrambi - non dover cambiare i contesti mentali dai linguaggi front-end a quelli back-end è un vero vantaggio che penso che alla fine aumenterà la produttività della nostra squadra.

Bene, non penso che riscrivere l'applicazione fosse una buona idea a meno che non si stesse comportando male. Per rispondere alle tue domande:

1. Node.js non è magico. La tua applicazione ha un'enorme quantità di utenti, quindi non c'è modo di essere certi che lo renderà più veloce.

2. Bene, sì, Node.js infatti consuma meno risorse del server. Quindi non solo puoi risparmiare denaro sulle risorse, ma puoi anche fare di più con quelle esistenti. Questo è principalmente a causa della natura single-threaded di Node.js. Non c'è sovraccarico di thread aggiuntivi.

3. Ancora una volta Node.js non è magico. Detto questo, potrebbe esserci del vero in questo. Node.js ha una comunità molto attiva che ha creato centinaia di moduli per ogni attività possibile. Quindi è abbastanza probabile che la maggior parte del lavoro sia stata fatta per te. Devi solo assemblare i pezzi.

4. In teoria, sì. Poiché Node.js è JavaScript, puoi condividere il codice tra client e server. Ma non so esattamente cosa sarà condiviso. Non ho scritto alcun pezzo di codice che è stato 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 codificare su client e server in una sola lingua.

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

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