Firebase vs Ruby: cosa c'è di meglio per il backend nello sviluppo di app mobili?

La scelta dello stack di backend per la tua app iOS o Android può essere difficile. Ecco perché qui esaminiamo il backend scritto da Firebase vs Ruby on Rails e indaghiamo se ci sono "scelte kamikaze" della tecnologia di backend per lo sviluppo di un'applicazione mobile. Ci sono motivi per non usare Firebase o Ruby? È possibile utilizzare firebase con Ruby on Rails? Scopriamolo.

Saresti d'accordo con me se affermo che il marketing è un concorso per l'attenzione delle persone? Inoltre, il marketing è troppo importante per essere lasciato a un dipartimento di marketing. Ha strisciato fino alla nicchia che sembra non avere nulla a che fare con la promozione: lo sviluppo del software; e il marketing ne fa già parte. Gli sviluppatori scelgono una soluzione per il loro progetto in base alle stelle che alcune librerie simili hanno su Github e alla quantità di "tweet" dell'account siamo in grado di prevedere quale tecnologia crescerà attivamente quest'anno. Questo ambiente digitale ci mette a rischio di diventare vittime dell'hype, dove potremmo essere fuorviati, semplicemente innamorandoci dello strumento hype altamente raccomandato, creato da diabolici marketer.

Uno degli strumenti di cui tutti hanno parlato di recente è Firebase e la sua API, una piattaforma di sviluppo di applicazioni mobili e web sviluppata da Firebase, Inc. nel 2011, poi acquisita da Google nel 2014, come afferma Wikipedia. Prima che Firebase venisse acquisito da Google nel 2014, non c'erano prove della rapida crescita del prodotto e sono presenti alcuni presunti svantaggi di Firebase. Anche se da allora alcune cose sono cambiate. Firebase è stato implementato nel processo di creazione di app come:

• Shazam
• App per ordini e consegne Alibaba
• Organizzatore di app di Todoist

Giganti come Shazam ovviamente non sarebbero andati in spese sfrenate, quindi di conseguenza, per loro Firebase era una scelta abbastanza ragionevole. Abbiamo cercato di esaminare i pro ei contro dell'implementazione di Firebase, cercando di capire a quale progetto sarebbe stato adatto.

Ma ci sono 2 punti da fare prima di immergerci nei vantaggi di Firebase: per eliminare tutti i possibili malintesi che potrebbero verificarsi:

1. Firebase non era originariamente pensato per essere un'opzione di backend, questa piattaforma ha un database al suo interno. Non è che ci siano app miracolosamente sviluppate senza la parte server integrata.
2. Tuttavia, non è un database relazionale. Firebase è una base NoSQL , con tutti i suoi pro e contro allegati + ambiente di sviluppo e architettura specifici di Firebase.

Che cos'è un database NoSQL?

Secondo Basho, NoSQL (che significa "Non SQL" o "Non solo SQL") è un approccio ai database che rappresenta un allontanamento dai tradizionali sistemi di gestione dei database relazionali (RDBMS). Per definire NoSQL, è utile iniziare descrivendo SQL, che è un linguaggio di query utilizzato da RDBMS. I database relazionali si basano su tabelle, colonne, righe o schemi per organizzare e recuperare i dati. Al contrario, i database NoSQL non si basano su queste strutture e utilizzano modelli di dati più flessibili. NoSQL è particolarmente utile per archiviare grandi quantità di dati non strutturati, che vengono acquisiti più velocemente dei dati strutturati.

Al contrario, Structured Query Language (SQL) è un linguaggio di programmazione utilizzato dagli architetti di database per progettare database relazionali. In un database SQL come MySQL, Sybase, Oracle o IBM DM2, SQL esegue query, recupera dati e modifica i dati aggiornando, eliminando o creando nuovi record. SQL è un linguaggio dichiarativo leggero che fa un sacco di lavoro pesante per il database relazionale, agendo come la versione di un database di uno script lato server.
[Fonte: Upwork]

Ora che abbiamo assicurato che siamo sulla stessa pagina, estraiamo alcuni vantaggi dell'utilizzo di Firebase.

1. Firebase potrebbe richiedere meno tempo.

Una volta che si arriva alla creazione di un'app in tempo reale con Firebase come backend, non è incluso lo sviluppo di parti del server, poiché i NoSQL non lo richiedono. Quindi, in una prospettiva a breve termine, questa piattaforma potrebbe richiedere meno tempo per essere sviluppata. Una volta che vuoi creare un'app semplice, con un piccolo backend senza big data, Firebase può essere implementato rapidamente nel progetto. Quando hai una scadenza fissa o un evento imminente, Firebase potrebbe essere una soluzione temporanea decente.

2. Firebase è una soluzione in tempo reale.

Se hai bisogno di notifiche push e aggiornamenti istantanei, allora hai bisogno di quella che viene chiamata un'app in tempo reale. Nel caso di Firebase, ci sono molti codelab scritti per questo e alcuni di questi mostrano come creare un'applicazione di chat per diverse piattaforme:

• iOS
• Android
• ragnatela

Il che ci dà un motivo per adeguarci: con tutti i vantaggi e gli svantaggi di Firebase, soddisfa le esigenze delle app di comunicazione in tempo reale.

3. Lo sviluppo di Firebase è una soluzione abbastanza sicura.

Finché Firebase è basato sull'infrastruttura di Google, offre una buona ragione per affermare che è una soluzione ben protetta. Sebbene tu possa raddoppiare la tua sicurezza definendo le regole del database NoSQL, poiché per impostazione predefinita non hai il controllo sui dati archiviati: è ospitato sui server di Google.

Ogni rosa ha la sua spina.

Quindi, se intendi che migliaia di persone utilizzeranno il tuo prodotto, allora Firebase potrebbe essere una soluzione inutile.

Una volta scelto Firebase come stack di backend principale, ci sono alcuni punti che devi considerare. Non gli svantaggi dell'utilizzo di Firebase, solo cose che devi sapere. Con Firebase, sei libero di scegliere il piano tariffario, ma quello adatto per le applicazioni in tempo reale è " pay as you go ". Con questo piano, paghi solo per le risorse che consumi, quindi più utenti ottiene la tua app, più ti costerà la manutenzione del backend.

Molte persone considerano questo un vantaggio in più, dato che molti utenti del tuo prodotto sono fantastici, non è vero? Tuttavia, all'inizio è difficile monetizzarli tutti: prima devi far amare il tuo prodotto alle persone. E nel caso con Firebase, potrai spendere soldi per tutti i tuoi utenti gratuiti. Quindi, se intendi che migliaia di persone utilizzeranno il tuo prodotto, allora Firebase potrebbe essere una soluzione inutile.

Si dice che Firebase abbia anche costi nascosti, quando dopo una rapida crescita dell'utente o dell'utilizzo potresti ricevere un addebito senza preavviso; quindi se non sei preoccupato di essere caricato silenziosamente, allora fallo.

Ecco perché un'altra opzione di backend decente per la tua app è un backend Ruby + un determinato server per l'archiviazione dei dati (questo è l'approccio che usiamo spesso quando lavoriamo sui progetti dei nostri clienti). Inoltre, il backend di Ruby on Rails e i vantaggi di Firebase sono più o meno gli stessi. Nel caso di Ruby, vanno come segue:

1. Ruby è un linguaggio semplice.

C'è un breve elenco di framework da implementare su di esso, anche se paragonato al linguaggio PHP e al suo codice sorgente, ma ci sono molte gemme: un sistema completo di librerie multiuso per Ruby. Altrettanto semplice è il modello architettonico delle lingue - MVC, con chiare dipendenze delle entità.

Maggiori informazioni sui tipi e le funzioni dei modelli architettonici

2. La community di Ruby ha superato la prova del tempo.

A differenza della neonata società di sviluppo Firebase, la comunità di Ruby è gigantesca, ha molte gemme open source, che consentono ai programmatori di aprire e sviluppare rapidamente applicazioni complesse. Inoltre, a causa di una certa "fama" di Ruby, molti servizi famosi (come Stripe) hanno librerie già pronte per Ruby.

3. Puoi testare il tuo codice su Ruby.

Ruby dispone di un'infrastruttura di sviluppo avanzata che consente di massimizzare e scrivere test di unità in tutto il progetto, per ridurre i bug nelle funzionalità nuove ed esistenti. Ciò ridurrà anche il costo del cambiamento futuro nel mezzo del processo di sviluppo.

4. Non sei legato a un tipo specifico di database.

O, più precisamente, a un tipo specifico di database. Ruby ti consente di utilizzare qualsiasi database relazionale o orientale, nonché NoSQL e altre tecnologie diverse, tra cui Elasticsearch, Reddis e altre meno popolari.

5. La sintassi di Ruby è un gioco da ragazzi.

Non ci sono tipi di dati in Ruby e, rispettivamente, non è necessario verificare se i tipi di dati sono strutturati in modo appropriato. E' inoltre presente il sistema componibile degli errori (detto anche sistema di logging); questo rende più facile la ricerca di un errore e quindi consente di correggere i bug che si verificano più velocemente.

SO, Firebase vs RoR: quale scegliere e quando?

Dopo il confronto tra Firebase e Rails, la risposta diplomatica è: dipende principalmente dai tuoi obiettivi.

Firebase come backend per lo sviluppo di app mobili è adatto a te se hai bisogno di uno dei seguenti:

• Una piccola app in tempo reale con funzionalità semplici
• Una semplice app in cui è necessario archiviare carichi e carichi
• Un'app che dimostra i concetti che verrà successivamente completamente rinnovata

Tuttavia, se stai cercando di creare un sistema mobile complesso, con algoritmi e funzionalità perplessi, anche il backend dell'app mobile Ruby on Rails è un'ottima scelta. Inoltre, se un'applicazione non ha una struttura chiara, nel database non relazionale, che è senza dubbio il backend cloud di Firebase, non è possibile selezionare correttamente i dati da esso. Le logiche di business create su Firebase vengono comunemente inserite nella base; a causa di ciò, potrebbe apparire un miscuglio quando la logica dell'applicazione è un po' perplessa. E non dimentichiamo che ti viene addebitato ogni volta che ottieni un nuovo utente, anche senza informarti: i tuoi soldi potrebbero essere semplicemente trasferiti una mattina quando ti svegli.

Spero che la lettura di questo articolo ti abbia aiutato a capire come utilizzare Firebase nello sviluppo di app mobili, se ritieni che soddisfi le tue esigenze.

Leggi anche: React Native vs Native App Development: quale scegliere?

Scritto da Oleg Tsarenko & Elina Bessarabova