Quanto è importante utilizzare la stessa lingua per client e server?


11

Ho valutato le soluzioni di architettura per un progetto mobile che disporrà di un servizio / app Web oltre alle app native e ho esaminato varie librerie, framework e stack come Meteor , trattandosi di una sorta di "framework di pacchetti open stack" , è strettamente legato con Node.js .

Si parla molto dei vantaggi dell'utilizzo della stessa lingua sia lato client che lato server, e non lo capisco. Potrei capire se vuoi rispecchiare l'intero stato di un'applicazione web sia su client che su server ma stai lottando per trovare altre vittorie ... Efficienza del flusso di lavoro?

Sto cercando di capire perché la parità di lingua client / server è considerata un Santo Graal. Perché la parità del linguaggio client / server è importante nello sviluppo del software?


12
Direi che non è necessariamente una cosa grandiosa, specialmente quando JavaScript è la lingua in questione.
Latty,

4
Devo ammettere che non ho ancora raggiunto il momento dell'epifania con JS e quindi non ho capito perché avresti voluto scrivere il codice del server con esso, ma questo è un altro argomento ..
Makita,

1
Grazie per aver pubblicato il tuo primo post su Stack Exchange Programmers. Per ulteriori informazioni su come massimizzare i voti positivi e minimizzare i voti negativi, leggi le FAQ. Potresti essere stato votato in negativo perché la tua domanda è più un argomento di chat che qualcosa con una risposta specifica. Potrebbe volerci un po 'di tempo per abituarsi al formato qui. Le risposte brevi che sono prive di dettagli sono sotto votate. Quindi sono le risposte che discutono di un argomento. C'è una via di mezzo in cui una domanda o una risposta è specifica ma abbastanza universale e colpisce un argomento con la giusta quantità di dettagli.
Sviluppatore:

1
Discuterei persino contro di esso. Con l'utilizzo della stessa lingua sia per il server che per il client si corre il rischio di intromissioni e funzionalità specifiche della lingua nella comunicazione.
Pieter B,

3
@Makita Penso che sia una domanda valida, ma le persone tendono ad essere felici con i voti negativi quando chiedono esempi. Ho rimosso alcune parti della domanda originale e focalizzato la tua domanda sul perché la parità di lingua client / server è importante.
maple_shaft

Risposte:


5

Sul lato PRO:

  • Se gli schemi e il codice possono essere riutilizzati da entrambe le parti, c'è molta efficienza nell'implementare una logica e dati simili solo una volta.

Dal lato CON:

  • Il client può essere principalmente una vista adatta per un linguaggio di markup o di script, mentre il server può essere principalmente una logica di business che si adatta meglio a una lingua diversa.

Nello sviluppo web, le lingue si sono moltiplicate, creando potenti strumenti per parti specifiche del sistema, nonché la necessità di apprendere molte specialità da sviluppatori o team di sviluppatori. In altre aree come l'elaborazione delle transazioni o i sistemi integrati che seguono un approccio di progettazione dei sistemi, potrebbero esserci risparmi da un linguaggio comune.

I nuovi framework Javascript sembrano arrivare molto velocemente e si lavora per raggruppare API per il back-end e strumenti per il front-end. Potrebbe essere intelligente mantenere la flessibilità e la separazione delle preoccupazioni tra codice lato client e lato server in modo da essere liberi di fluttuare tra di loro senza rimanere troppo bloccati per troppo tempo con uno strumento particolare.


14

Presumibilmente i benefici percepiti sono:

cioè semplifica la gestione delle risorse per i project manager e ha pochi o nessun vantaggio tecnico (possibilmente anche un vantaggio tecnico negativo se stai assumendo un gruppo di pony con un trucco)


1
È un vantaggio se stai sviluppando da solo, perché non esiste un passaggio "mentale" tra server e client. Se vuoi fare qualcosa e avere una grande esperienza in JavaScript, probabilmente otterrai risultati migliori e più veloci in questo modo, ma probabilmente è tutto ...
K ..

Diresti anche che non ci sono svantaggi tecnici, forse un vantaggio nell'usare una lingua diversa per ogni singolo sottosistema?
Michael Borgwardt,

1
@MichaelBorgwardt supponendo che ogni lingua sia adatta al sottosistema, direi di sì, nessun svantaggio tecnico (forse comunque non un grande vantaggio), ma potrebbe avere un grande impatto sulla dinamica del team e sulle assunzioni. ovviamente la maggior parte dei sottosistemi sarà facilmente implementabile in qualsiasi lingua, quindi non mi aspetterei di vedere questo estremo.
jk.

L'osservazione che questa è una cattiva idea è ingiustificata. Esistono molte lingue che possono essere compilate in JavaScript e in una lingua lato server, incluso Lisp , che in realtà è la lingua utilizzata nel corso SICP elogiata dal post sul blog di Joel.
back2dos,

@ back2dos si spera che lo chiarisca
jk.

2

Il vantaggio è che puoi riutilizzare (in parte) l'esperienza e il codice delle persone su entrambi i lati.

Persone

Gli sviluppatori devono padroneggiare una sola lingua e formare un unico pool. Piuttosto che due pool di competenze. Ciò semplifica il trasferimento delle conoscenze tra di loro e consente anche loro di passare più facilmente il loro lavoro tra client e server. Infine, facilita la comunicazione con i membri del team dell '"altra parte" quando discutono di problemi tecnici perché condividono lo stesso background tecnico.

Codice

A volte è utile avere un certo stato sul lato client, o algoritmi o entrambi. A volte, lo stesso viene fatto su entrambi i lati. Facciamo l'esempio di un gioco multiplayer: devi rappresentare lo stato del gioco sia sul client che sul server. Inoltre, è necessario implementare le regole sul lato client (per reattività) e anche sul lato server (per convalidare le azioni di un giocatore). Essere in grado di riutilizzare il codice per queste cose può essere un grande vantaggio. ... in alcune altre applicazioni, non ti servirà affatto ... tutto dipende dal caso.

... ovviamente ci sono anche degli aspetti negativi, ma questo è per un altro post;)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.