Perché i siti Web di grandi dimensioni utilizzano lingue diverse per il back-end e il front-end?

La mia comprensione da piccole applicazioni MVC è che hai il front-end, che si occupa di HTML, JS, jQuery, ecc., E che hai il back-end, che è composto da controller e modelli.

Tuttavia, quando parlo con sviluppatori di grandi aziende, spesso menzionano un livello frontend e un livello backend. Quindi a volte, potrei sentire che hanno un frontend con C # e un backend con Java. Perché un'azienda dovrebbe desiderare un backend e un frontend in diverse lingue? Questo aiuta a scalare meglio il grande sito Web?

Quando le persone dicono che il loro frontend è costruito in C #, significa che stanno usando un framework per il frontend (come .NET) e un framework aggiuntivo sul backend (come Spring)? O significa qualcosa di completamente diverso?

"Front-end" e "Back-end" possono essere termini nebulosi, in particolare nelle applicazioni aziendali. "Front-end" può indicare l'interfaccia utente o può essere l'intera applicazione. "Back-end" può essere utilizzato per indicare gli interni, oppure potrebbe essere il database o i servizi esterni che vengono utilizzati. Il significato dei termini dipende spesso interamente da chi stai parlando. Quindi forse hai chiesto "hey, cosa intendi con quello?"

Quando entri nello sviluppo di grandi aziende, avrai un sacco di team che scrivono un sacco di codice. Questi team si svilupperanno in lingue diverse, usando paradigmi diversi, da posizioni diverse. Alcuni di questi codici dovranno lavorare insieme e molti altri no.

Lavoro per una grande banca. Il mio team sviluppa la nostra applicazione in C #. Tutto. Ma consumiamo servizi Web che sono in gran parte scritti in Java e quei servizi parlano con altri servizi che parlano con altri servizi che ottengono i dati dell'account da e verso gli archivi dati appropriati e chissà quali lingue vengono utilizzate con quelli.

Versione breve: le persone usano gli strumenti per svolgere il lavoro.

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

Esistono molte risposte possibili, le più importanti sono:

• Le grandi applicazioni sono costituite da molte parti relativamente indipendenti; spesso, ogni parte è costruita da un team diverso o anche da un diverso appaltatore esterno. Il vantaggio di scegliere l'offerta migliore è spesso maggiore del vantaggio di avere tutto nella stessa lingua.
• Le lingue vanno e vengono, e talvolta un componente di un grande sistema sopravvive all'ecosistema. Un esempio dal mondo Microsoft è il numero di aziende che ora usano C # per tutti i nuovi progetti, ma hanno ancora una notevole base di codice VB. 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, allora hai due possibilità: implementare tu stesso la soluzione o utilizzare la soluzione Java e sviluppare un po 'di colla per integrarla nel tuo sistema. Quest'ultimo è quasi invariabilmente più economico per qualsiasi compito non banale.

Le considerazioni sulle prestazioni non sono praticamente mai la ragione, tranne in applicazioni estremamente critiche per le prestazioni come il trading ad alta frequenza - in quelle aree, può essere utile scrivere il motore principale critico in un linguaggio con prestazioni di runtime migliori (diciamo, C ++), ma i sistemi di supporto (UI, reporting, ecc.) in qualcosa di livello superiore come Java o C #.

È relativo in una grande impresa.
Nella mia compagnia lo stack è grosso modo

(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, il livello .Net deve funzionare 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, Web Middleware, sviluppatori .Net, sviluppatori SQL, sviluppatori COBOL che lavorano su ogni parte dello stack.

In realtà in qualsiasi impresa sufficientemente grande, è completamente tartaruga.

Semantica confusa

È un problema di semantica. Quando qualcuno dice un front-end .NET o uno sviluppatore front-end Java, di solito parlano della persona che conosce molto i linguaggi di modellazione e forse i framework che non dovrebbero mai essere usati mai più come i webform che sono stati usati per provare a nascondere ridimensionamento di cose su un muro http (ovvero "sviluppo web") da parte di sviluppatori di app che non volevano o almeno si presumeva che non volessero conoscere tutta quella merda. Nel caso di .NET e Java misti, non sono sicuro ma potrei solo immaginare che, nel senso di MVC, hanno Java che agisce per tutte le cose del modello di business e .NET che gestisce tutto il resto che sarebbe meglio descritto come "livello intermedio" ma è ancora tutto lato server.

La vera separazione è ciò che accade sul server e ciò che accade sul client o sul browser. Potresti facilmente confondere la creazione dell'HTML da inviare o rappresentare il front-end con "sviluppo del front-end", quindi preferisco evitare confusione utilizzando i termini client e lato server anziché front-end e back-end quando discutiamo di ciò che faccio in genere, (di solito lavoro lato client).

Lingue lato client

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

Lingue lato server

Il motivo per cui hai a disposizione miliardi di opzioni sul web lato server è perché puoi farlo. È il tuo server. Tutto quello che deve fare è comunicare via http / ssl e il resto dipende da te. JavaScript è ora un'opzione tra l'altro, ma ciò solleva una domanda interessante. Dovresti comunque trattare un'app Web come se fossero davvero due app su entrambi i lati di quel muro HTTP. Sono dell'opinione consapevole del fatto che sì, sì, dovresti e adoro Node.js.

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

Se ti stai concentrando sull'interfaccia utente Web e hai flessibilità nella scelta dell'implementazione, è molto più probabile che tu utilizzi un linguaggio di destinazione dell'interfaccia utente Web, come JScript o Flex, piuttosto che C #.

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

Il motivo è il bilanciamento del rischio aziendale.

Diciamo che sei un datore di lavoro gigante 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 che vuoi iniziare con esso.

Se ti impegni in una sola tecnologia potresti prosciugare il pool di talenti. Sei sicuro di voler assumere un decente Langauge A quando c'è una stella in lingua B proprio dietro l'angolo? E se domani i framework di Langauge A si impadronissero del supporto dello sviluppatore principale? E se domani ci fosse un fantastico linguaggio C, dovresti ignorarlo perché ti sei impegnato nel linguaggio A cinque anni fa?

Idealmente quello che vuoi è un sistema etrogeno con lingue diverse che rifletta l'attuale pool di talenti e le tendenze tecnologiche. Volete che questo equilibrio cambi lentamente mentre il pool di talenti e le tendenze stanno cambiando in modo tale che in qualsiasi momento tutti i vostri sistemi siano fattibili e potete assumere le persone per mantenerli.

... e questo è quello che fanno le aziende.

È utile pensare al front-end e al back-end come ad 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 a un CMS. Queste possono essere facilmente applicazioni MVC separate. Il front-end ha ancora bisogno di modelli e controller per funzionare - dopotutto, 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.

Tendo ad amare usare Django / Python come CMS sul back-end e usare 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 vogliono solo una soluzione CMS. La maggior parte dei clienti non saprebbe nemmeno che il CMS eseguiva una lingua o un framework diversi se non gli fosse stato detto.

Si tratta davvero di trovare ciò che funziona meglio per il sito che si desidera creare. I front-end e i back-end devono davvero solo condividere il database, quindi finché possono entrambi lavorare con quello, sentiti libero di scegliere le migliori opzioni per l'attività a portata di mano.

Un esempio di 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 svolto correttamente il proprio lavoro, il server lo farebbe e non potrebbe mai mostrarti il ​​vero codice PHP. Viene analizzato quando la pagina viene pubblicata e il risultato della traduzione del codice è HTML.