Dove mettere la logica aziendale se si utilizza Firebase?

9

Sto per iniziare a sviluppare un'applicazione web a pagina singola che è molto semplificata con un sistema di documentazione multiutente. Il front-end utilizzerà probabilmente Angular2.

Il progetto ha una scadenza breve, quindi ho cercato "scorciatoie", cioè utilizzando vari servizi già pronti invece di implementare tutto da zero.

Avrò bisogno di una sorta di back-end per archiviare i dati dell'applicazione. Mi sono guardato intorno e ho trovato Firebase, che sembra portare via parte del lavoro di creazione di un back-end e API separati per comunicare con il front-end.

Ma ciò significa anche che dovrei mettere la logica aziendale nel front-end, nell'app web Angular2, giusto?

Quindi, se un giorno o l'altro in futuro volessi creare un front-end per app per dispositivi mobili, dovrei duplicare il codice della logica aziendale?

Suppongo che l'alternativa sarebbe quella di creare un back-end che contenga la logica aziendale e utilizzi Firebase per l'archiviazione dei dati, ma sembra un po 'strano (non potrei usare solo un ORM o qualcosa direttamente nel mio back-end per raggiungere il lo stesso risultato senza molto più lavoro?)

In che modo le persone solitamente strutturano questo tipo di app, se vogliono utilizzare Firebase ad esempio?

    
posta Magnus W 12.03.2017 - 07:01
fonte

2 risposte

2

But that also means I would have to put the business logic in the front end, in the Angular2 web app, right?

Sì. Fondamentalmente la tua Angular 2 SPA è l'intera app da sola. Senza un'app lato server, la business (logica) dovrebbe essere collocata da qualche altra parte. In questo caso nella SPA.

Firebase è stato disgustato per permettere agli sviluppatori di app di creare app senza doversi preoccupare dell'infrastruttura di back-end (app server, server http, TLS, RDMS, ecc.

Firebase non esclude necessariamente i backend ma per quelle app che utilizzano backend come mere repository (CRUD). Tuttavia, fornisce Funzioni cloud per le procedure lato server. Quindi potresti ancora implementare alcune logiche di business sul lato server.

So if I some day in the future would like to make a mobile app front end, I would have to duplicate the business logic code?

Non necessariamente. Se la tua app Web è costruita in Angular 2, piattaforme incrociate come Native Script potrebbero permetterti di riutilizzare componenti web, librerie, utility, modelli di dati , ecc. Non ho approfondito l'argomento, quindi non posso assicurarti una compatibilità totale. La chiave qui è TypeScript , sia Angular che NativeScript ci richiedono di codificare in TS.

Il problema è quindi dove ospitare il codice Javascript compilato e il controllo delle versioni. Una parola CDN .

I guess the alternative would be to create a backend that contains the business logic and uses Firebase for its data storage, but that seems a bit weird (couldn't I just use an ORM or something directly in my backend to achieve the same result without a lot more work?)

Avere qui un back-end potrebbe essere utile per un singolo motivo e molto semplice. Disaccoppiamento. Le tue app sarebbero legate a una singola interfaccia web. Se il tuo SPA sta per consumare diverse API REST, avere una singola interfaccia web (facciata) "governandoli tutti" renderà il modo SPA più semplice. Ma non mentirò, sposteremo semplicemente la complessità da un lato (client) a un altro (server).

Tuttavia, se la tua app non è un mashup non trarrai vantaggio da tale astrazione.

How do people usually structure these kinds of apps, if they want to make use of Firebase for example?

Varia molto tra i progetti. Ad esempio, utilizziamo Firebase + backend.

  • DB Firebase per condividere i dati tra le sessioni e i dispositivi dell'account e come registro delle modifiche quando il nostro back-end è temporaneamente non disponibile.

  • I messaggi cloud di Firebase forniscono notifiche push e argomenti di upstream / downstream, quindi utilizziamo il servizio come broker di pubblicazione / sottotitoli.

risposta data 20.05.2017 - 00:26
fonte
0

Risposta breve: non utilizzare la business logic.

Risposta lunga: Descrivi un'applicazione che sembra abbastanza piccola da non avere una logica di business separata; valutare se hai davvero una tale logica di business in primo luogo; un sacco di logica aziendale può essere ridotta dalla progettazione dei dati, e un po 'dal livello di presentazione. Molti piccoli sistemi sono per lo più CRUD e non hanno alcuna reale logica di business; un sacco di volte ho visto due o tre strati di classi che sono solo oggetti passanti che lasciano lo spazio per un futuro che non arriverà mai.

Potresti iniziare con un'API appena uscita da Firebase e successivamente introdurre un ulteriore livello per la logica di business quando trovi che c'è un reale bisogno di farlo, purché tu abbia progettato il tuo contratto abbastanza bene perché il servizio mantenga una stabile firma mentre l'implementazione potrebbe cambiare.

    
risposta data 19.05.2017 - 00:46
fonte

Leggi altre domande sui tag