Perché i siti Web di grandi dimensioni utilizzano lingue diverse per il backend e il frontend?

"Front-end" e "Back-end" possono essere termini nebulosi, in particolare nelle applicazioni aziendali. "Front-end" può significare l'interfaccia utente o può essere l'intera applicazione. "Back-end" può essere usato per indicare gli interni, o potrebbe essere il database oi servizi esterni che vengono consumati. Che cosa significano i termini spesso dipendono interamente da chi stai parlando. Quindi forse hai chiesto "hey, cosa intendi con questo?"

Quando entri nello sviluppo di grandi aziende, avrai molti e molti team che scrivono tanto e tanto codice. Questi team si svilupperanno in diverse lingue , utilizzando diversi paradigmi, da posizioni diverse. Parte di questo codice dovrà funzionare insieme e in gran parte no.

Lavoro per una grande banca. Il mio team sviluppa la nostra applicazione in C #. Tutto. Ma noi consumiamo servizi Web scritti in gran parte in Java e tali servizi parlano con altri servizi che parlano con altri servizi che ottengono i dati dell'account da e verso gli archivi dati appropriati, e < em> chi sa quali lingue sono usate con quelle.

Versione breve: le persone utilizzano gli strumenti che portano a termine il lavoro.

Penso che sia necessario ampliare un po 'la domanda: perché i progetti software di grandi dimensioni utilizzano più di un linguaggio di programmazione?

Ci sono molte possibili risposte, le più importanti sono:

• Le applicazioni di grandi dimensioni sono costituite da molte parti relativamente indipendenti; spesso, ogni parte è costruita da una squadra diversa o anche da un altro contraente esterno. Il vantaggio di andare con la migliore offerta è spesso maggiore del vantaggio di avere tutto nella stessa lingua.
• Le lingue vanno e vengono, e a volte un componente di un grande sistema sopravvive all'ecosistema. Un esempio del mondo Microsoft è il numero di aziende che ora usano C # per tutti i nuovi progetti, ma hanno ancora una base di codice VB considerevole. Il costo di riscrivere un progetto solo per il gusto di farlo nell'ultimo linguaggio di programmazione non è praticamente mai giustificato.
• Interfaccia con componenti di terze parti. Se il tuo ecosistema C # deve eseguire un'attività specifica per la quale esistono solo soluzioni Java, hai due possibilità: implementare la soluzione da solo o utilizzare la soluzione Java e sviluppare un po 'di colla per integrarla nel tuo sistema. Quest'ultimo è quasi sempre meno costoso per qualsiasi compito non banale.

Le considerazioni relative alle prestazioni non sono praticamente mai la ragione, tranne che in applicazioni estremamente critiche per le prestazioni come il trading ad alta frequenza: in quelle aree può essere utile scrivere il core engine fondamentale in una lingua con prestazioni di runtime migliori (ad esempio, C ++), ma i sistemi di supporto (UI, reporting, ecc.) In qualcosa di più alto livello come Java o C #.

È relativo in una grande impresa.
Nella mia azienda lo stack è approssimativamente

(html/javascript)--> (JSP on Tomcat and Java based WebCMS) -> (.Net SOA)  

Quindi per il team di sviluppo web il frontend è HTML / JS e il backend è Java. Per l'azienda il frontend è Java e il backend è .Net.

In effetti, lo strato .Net deve lavorare con un'applicazione COBOL / UNIX per fatturazione e reclami e quindi in questa prospettiva .Net è frontend e COBOL è backend.

E sì, come altri hanno già detto abbiamo team di progettisti UX, sviluppatori HTML / JS, sviluppatori Java, middleware Web, sviluppatori .Net, sviluppatori SQL, sviluppatori COBOL che lavorano su ciascuna porzione dello stack.

In realtà in qualsiasi impresa sufficientemente grande si tratta di tartarughe che arrivano fino in fondo.

Semantica confusionaria

È un problema di semantica. Quando qualcuno dice un frontend .NET o uno sviluppatore front-end Java, di solito parlano della persona che conosce molto i linguaggi dei template e forse dei framework che non dovrebbero mai più essere usati come webform che sono stati usati per cercare di nascondere il buttare le cose su una parete http (cioè "sviluppo web") da sviluppatori di app che non volevano o almeno si presumevano non volessero saperne di più su tutta quella merda. Nel caso di .NET e Java misti, non sono sicuro, ma ho potuto solo supporre che nel senso di MVC delle cose abbiano Java che agisce per tutte le cose del modello di business e .NET che gestisce tutto il resto che sarebbe meglio descritto come "middle-tier" ma è ancora tutto sul lato server.

La vera separazione è ciò che accade sul server e cosa succede sul client o sul browser. Si potrebbe facilmente confondere la costruzione dell'HTML da inviare o rappresentare il front-end con "sviluppo front-end", quindi preferisco evitare confusione usando i termini client e lato server anziché front e back-end quando si discute di ciò che faccio tipicamente, (di solito il lavoro lato client).

Lingue lato client

Il motivo per cui utilizziamo lo stesso set di lingue sul browser è perché il browser è sul lato ricevente e per la maggior parte (c'è stata ormai la resistenza per lo più da Microsoft e Adobe su questo) nessuno vuole avere inviare tre diverse versioni dello stesso lato client per soddisfare ogni potenziale cliente o richiedere l'installazione di un plug-in proprietario per il web. Inoltre, le tre lingue incapsulano abbastanza bene le preoccupazioni sul lato client, permettendoci di costruire e modificare rapidamente front-end delle app Web mantenendo un accoppiamento lento tra la struttura del documento, il modo in cui tutto appare e come tutto si comporta. Puoi cambiarne uno senza cambiare abbastanza facilmente gli altri due.

Lingue lato server

Il motivo per cui hai migliaia di opzioni sul web lato server, ovviamente, è perché puoi. È il tuo server. Tutto ciò che deve fare è comunicare tramite http / ssl e il resto dipende da voi. JavaScript è ora un'opzione tra l'altro, ma fa emergere una domanda interessante. Dovresti ancora trattare un'applicazione web come se fossero davvero due app su entrambi i lati di quel muro HTTP. Sono dell'opinione informata attraverso il dolore che sì, sì dovresti e io adoro Node.js.

In breve, dove hai progetti di grandi dimensioni, hai anche diversi team di sviluppatori che lavorano al progetto e quei team tendono a specializzarsi su diversi livelli dell'applicazione.

Se ti concentri sull'interfaccia utente web e disponi di flessibilità nella scelta dell'implementazione, è molto più probabile che utilizzi un linguaggio di targeting ui Web, come JScript o Flex, piuttosto che C #.

Allo stesso modo, se si è alla fine dell'archivio dati transazionale dell'applicazione, che si occupa di molte azioni simultanee contemporaneamente, i linguaggi specializzati come l'erlang tendono ad abituarsi. (O prodotti di terze parti implementati in parte in queste lingue)

Il motivo è il bilanciamento del rischio aziendale.

Diciamo che sei un grande datore di lavoro in una città. Devi assumere molti sviluppatori per creare molti servizi diversi. Diciamo che la tua valutazione iniziale è che Lanuage A si adatta meglio ai tuoi interessi e vuoi iniziare con esso.

Se ti impegni con una tecnologia, potresti asciugare il pool di talenti. Sei sicuro di voler assumere un ragazzo Langauge decente quando c'è una stella della lingua B proprio dietro l'angolo? Cosa succederebbe se domani i framework di Langauge A fossero supportati dallo sviluppatore principale? E se domani ci fosse un sorprendente linguaggio C, dovresti ignorarlo perché ti sei impegnato con il linguaggio A cinque anni fa?

Idealmente quello che vuoi è un sistema eterogeneo con lingue diverse che rifletta l'attuale pool di talenti e le tendenze tecnologiche. Vuoi che questo equilibrio cambi lentamente mentre il pool di talenti e le tendenze stanno cambiando in modo che in qualsiasi momento tutti i tuoi sistemi siano realizzabili e puoi assumere le persone per mantenerle.

... e questo è un po 'quello che fanno le aziende.

È utile pensare al front-end e al back-end come applicazioni separate che utilizzano entrambe la stessa origine dati.

Anche per i siti più piccoli, puoi pensare al front-end come a ciò che il client si interfaccia e al back-end come qualcosa come un CMS. Questi possono facilmente essere applicazioni MVC separate. Il front-end ha ancora bisogno di modelli e controller per funzionare - dopo tutto, il controller è il punto di ingresso per i visitatori del tuo sito e i modelli saranno il modo in cui ottieni i dati dal tuo database all'utente.

Mi piace usare Django / Python come CMS sul back-end e utilizzare Rails, CodeIgniter o Spring MVC sul front-end. Spesso non c'è scelta; il client ha già un sito legacy impostato in una lingua sul front-end e vuole solo una soluzione CMS. La maggior parte dei clienti non saprebbe nemmeno che il CMS gestisse una lingua o un framework diverso se non gli fosse stato detto.

Si tratta davvero di trovare ciò che funziona meglio per il sito che vuoi costruire. Le estremità anteriore e posteriore hanno davvero bisogno solo di condividere il database, quindi finché possono lavorare con quello, sentiti libero di scegliere le migliori opzioni per il compito da svolgere.

Un esempio di un linguaggio back-end è PHP, che è un linguaggio di scripting. Quando viene richiesta una pagina PHP, il server legge il codice PHP e rende il markup.  Il risultato è l'HTML che ti viene inviato. Tu, il visualizzatore di pagine web, non vedi mai una riga di codice PHP.  Supponendo che l'amministratore del server Web abbia fatto correttamente il suo lavoro, il server non potrebbe mai mostrarti il codice PHP attuale. Viene analizzato quando la pagina  viene pubblicato e il risultato di tale conversione del codice è HTML.