RESTful Backend - Quanto accoppiato dovrebbe essere il mio back end e front end?

1

Sto creando un'applicazione web con un client front-end scritto in angolare e un back-end che sto scrivendo in Django (ci sono dei motivi per cui ho scelto i framework ma sono irrilevanti per la mia domanda).

Il mio front end è pianificato su tutte le pagine che saranno disponibili. Al momento sto solo implementando il ciular angolare, ma in futuro prevedo di implementare un'app nativa per Android e iOS per scopi di apprendimento.

La mia domanda è: in che modo il mio back end design dovrebbe essere abbinato al mio front end client?

Dovrei progettare i miei endpoint su una base per visualizzazione? Sembra che il back-end abbia bisogno di lavoro quando creo un altro client.

O i miei endpoint dovrebbero essere più focalizzati sull'esposizione della funzionalità CRUD per i miei modelli? Questo sembra lasciare spazio alla creatività e rendere il back-end più flessibile.

Queste sono alcune delle domande che mi sono posto e le ho fornite per aggiungere un po 'più di spazio alla mia domanda.

Anche se avessi optato per l'approccio crudistico, mi sembra di implementare ancora endpoint specializzati per la gestione delle funzionalità delle applicazioni più comuni.

Grazie in anticipo.

    
posta rocktheartsm4l 31.01.2015 - 23:41
fonte

2 risposte

1

Se ogni cliente che intendi servire richiede un output diverso dal tuo back-end. Quindi scrivi il tuo back-end in un modo in cui è in grado di servire ogni tipo.

Fai un po 'di astrazione. Chiediti, quali sono le esigenze di tutti i client allo stesso modo e quali sono le esigenze di ogni cliente in un modo specifico diverso.

Metti insieme tutte le cose che sono uguali per tutti i client, quindi scrivi un'interfaccia per ciascun client che gestisca le differenze per quel client. Queste interfacce otterranno tutti i contenuti dallo stesso modulo, ma si adattano servendo quel contenuto per le esigenze specifiche dei clienti.

    
risposta data 01.02.2015 - 08:03
fonte
1

Dovresti progettare il tuo back-end attorno alle risorse che stai esponendo dal back-end.

Questi non devono corrispondere esattamente al modello (le risorse esposte e il modello interno sono due cose distinte), ma spesso si avranno molte sovrapposizioni. Ad esempio potresti avere un oggetto modello "utente" e una risorsa "utente" esposta dal server.

Una "risorsa" è un concetto astratto, ma è importante avere nella testa quali risorse il server espone ai clienti.

Una volta capito che scrivere il client dovrebbe essere un gioco da ragazzi dato che il client richiede semplicemente le risorse e fa qualcosa con loro.

Per dare un esempio di dove le risorse e il modello di dominio non sono necessari completamente sul giro immagina un server che espone una risorsa "studente" ai clienti, ma nel modello di dominio c'erano in realtà 10 diversi oggetti che sono andati a creare quella risorsa (nessuno di loro ha chiamato "studente")

Quindi l'URL di risorsa per uno studente assomigliava a "/ students / [id]" ma quando è stato effettuato l'accesso il server ha creato 10 diversi modelli, da Person a Grade, a School per creare quella singola risorsa.

Molti framework web, come Django, mappano le risorse molto da vicino al modello di dominio che può rendere le cose più facili (es. / studenti / [id] mappa direttamente su un oggetto Studente nel modello), ma è importante ricordare che questo non è un requisito o, a volte, nemmeno una buona idea.

    
risposta data 06.02.2015 - 19:35
fonte