Quali rischi ci sono nell'usare Node.js con Java EE?

Question

Quali rischi ci sono nell'usare Node.js con Java EE?

#1 da (2 voti)
#2 da (0 voti)

1

Stiamo sviluppando un'applicazione web B2B in cui stiamo utilizzando (suggerito dagli anziani) due server. Uno è Node.js (per servire tutti i contenuti html e statici relativi alle richieste) e l'altro è Tomcat per implementare i servizi REST per servire il back-end.

Penso che aggiungerà un sovraccarico non necessario se consideriamo quanto segue:

È necessario mantenere due server.
Sicurezza (gestione della sessione / gestione delle viste).
Risorse (servono sviluppatori Node.js e sviluppatori Java).
Distribuzione e configurazioni.

Ho sbagliato a considerare questi rischi con una decisione architettonica del genere? Quale sarebbe la logica potenziale per decidere di utilizzare due framework completamente diversi come questo in cui vi sono funzionalità e sovrapposizione di funzionalità?

java enterprise-architecture node.js tomcat

posta Ali786 12.04.2017 - 11:31

fonte

2 risposte

Leggi altre domande sui tag java enterprise-architecture node.js tomcat

Framework over-HTTP basato su eventi Come riutilizzare il codice boilerplate per la gestione delle sessioni di Hibernate?

score 2 · Answer 1

Se usi i microservizi, non dovrebbe importare quale microservizio sia stato scritto usando quale tecnologia.

Avere due lingue e runtime per due parti dei sistemi può avere uno svantaggio di dover configurare due tipi di distribuzioni ma non dovrebbe essere complicato se fatto bene.

D'altra parte questo sembra usare il tributo giusto per il lavoro. Se sono necessari due strumenti, è necessario utilizzare due strumenti anziché utilizzare uno strumento solo per ridurre al minimo il numero di strumenti utilizzati. Nota che lo strumento giusto per il lavoro non è solo una forma fisica astratta per uno scopo particolare, ma anche altri fattori devono essere presi in considerazione come l'esperienza delle persone, gli strumenti già scritti, il codice disponibile, le librerie, l'architettura ecc.

Anche l'esistenza di due sistemi separati imporrà limiti chiari all'API. Ciò può aiutare a ridurre le astrazioni che perdono e l'accoppiamento stretto, quindi alla fine della giornata potrebbe non essere una cattiva idea che possa sembrare all'inizio.

Tieni presente che la necessità di sviluppatori di nodi e sviluppatori Java non richiede più risorse. Non pensi che nessuno di quei gropus di sviluppatori possa creare entrambe le parti del sistema nello stesso momento di una di quelle parti, vero?

score 0 · Answer 2

Non sono un fan della filosofia del "miglior strumento per il lavoro". Ma è un grosso problema di immagine piuttosto che tecnico.

Generalmente i reclutatori amano raggruppare gli sviluppatori in set di abilità / stack. Java, Microsoft, JS. Se ti attacchi con uno stack singolo è facile reclutare nuovi sviluppatori. Tutti conoscono il campo di gioco.

Non è che quegli sviluppatori siano incapaci di raccogliere uno stack casuale e farlo funzionare, è solo il modo in cui il mondo funziona.

Le aziende vogliono assumere persone che hanno fatto esattamente la stessa cosa prima di qualsiasi altra parte. Se inizi a utilizzare tecnologie casuali, cadi dal percorso facile e conosciuto e rendi la tua vita più difficile.

Anche da un punto di vista tecnico, vuoi essere in grado di riutilizzare i tuoi componenti di basso livello. Log, accesso db, cloud api wrappers ecc. Se ti attacchi a un singolo stack, puoi semplicemente avere un set di questi.

Ovviamente implicito in questa idea è che lo stack scelto offre una soluzione praticabile al tuo problema. es. Se vuoi un widget su un telefono Android, devi farlo in xml / java