Firebase vs Ruby: co jest lepsze dla backendu w tworzeniu aplikacji mobilnych?

Wybór stosu zaplecza dla aplikacji na iOS lub Androida może być trudny. Dlatego tutaj przyjrzymy się backendowi napisanemu przez Firebase i Ruby on Rails i zbadamy, czy istnieją jakieś „kamikaze wybory” technologii backendowej do tworzenia aplikacji mobilnych. Czy są jakieś powody, by nie używać Firebase lub Ruby? Czy można używać Firebase z Ruby on Rails? Odkryjmy.

Zgodzisz się ze mną, jeśli powiem, że marketing to konkurs na uwagę ludzi? Co więcej, marketing jest zbyt ważny, aby pozostawić go działowi marketingu. Doczołgał się nawet do niszy, która wydaje się nie mieć nic wspólnego z promocją - rozwoju oprogramowania; a marketing jest już jego częścią. Deweloperzy wybierają rozwiązanie dla swojego projektu na podstawie gwiazdek, jakie kilka podobnych bibliotek ma na Github, a ilość „tweetów” na koncie jesteśmy w stanie przewidzieć, jaka technologia będzie się aktywnie rozwijać w tym roku. To cyfrowe środowisko naraża nas na ryzyko stania się ofiarą szumu, w którym możemy zostać wprowadzeni w błąd – po prostu wpadamy w polecane narzędzie do szumu, stworzone przez diabelskich marketerów.

Jednym z narzędzi, o których wszyscy ostatnio mówili, jest Firebase i jego API, platforma do tworzenia aplikacji mobilnych i internetowych opracowana przez Firebase, Inc. w 2011 roku, a następnie przejęta przez Google w 2014 roku, jak podaje Wikipedia. Przed przejęciem Firebase przez Google w 2014 r. nie było dowodów na szybki rozwój produktu, a niektórzy twierdzili, że istnieją wady Firebase. Chociaż od tamtego czasu pewne rzeczy się zmieniły. Firebase został zaimplementowany w procesie tworzenia aplikacji takich jak:

• Shazam
• Aplikacja do zamawiania i dostawy Alibaba
• Organizator aplikacji Todoist

Giganci, tacy jak Shazam, oczywiście nie popadliby w bezsensowne wydatki budżetowe, więc w konsekwencji dla nich Firebase był całkiem rozsądnym wyborem. Próbowaliśmy przyjrzeć się zaletom i wadom wdrożenia Firebase, starając się ustalić, w którym projekcie byłoby to dobre rozwiązanie.

Zanim jednak zagłębimy się w zalety Firebase, należy zwrócić uwagę na 2 kwestie – aby pozbyć się wszystkich możliwych nieporozumień, które mogą wystąpić:

1. Firebase początkowo nie miał być opcją zaplecza, ta platforma ma u podstaw bazę danych. To nie jest tak, że istnieją cudownie opracowane aplikacje bez zintegrowanej części serwerowej.
2. Nie jest to jednak relacyjna baza danych. Firebase to baza NoSQL , z dołączonymi wszystkimi zaletami i wadami oraz specyficznym środowiskiem programistycznym i architekturą Firebase.

Co to jest baza danych NoSQL?

Według Basho, NoSQL (co oznacza „Not SQL” lub „Not Only SQL”) to podejście do baz danych, które reprezentuje odejście od tradycyjnych relacyjnych systemów zarządzania bazami danych (RDBMS). Aby zdefiniować NoSQL, warto zacząć od opisu SQL, który jest językiem zapytań używanym przez RDBMS. Relacyjne bazy danych wykorzystują tabele, kolumny, wiersze lub schematy do organizowania i pobierania danych. Natomiast bazy danych NoSQL nie opierają się na tych strukturach i używają bardziej elastycznych modeli danych. NoSQL jest szczególnie przydatny do przechowywania dużych ilości nieustrukturyzowanych danych, które są pozyskiwane szybciej niż dane strukturalne.

Wręcz przeciwnie, Structured Query Language (SQL) to język programowania używany przez architektów baz danych do projektowania relacyjnych baz danych. W bazie danych SQL, takiej jak MySQL, Sybase, Oracle lub IBM DM2, SQL wykonuje zapytania, pobiera dane i edytuje dane poprzez aktualizowanie, usuwanie lub tworzenie nowych rekordów. SQL to lekki, deklaratywny język, który wykonuje wiele zadań dla relacyjnej bazy danych, działając jak wersja skryptu po stronie bazy danych.
[Źródło: Upwork]

Teraz, gdy mamy pewność, że jesteśmy na tej samej stronie, wymieńmy kilka zalet korzystania z Firebase.

1. Firebase może być mniej czasochłonny.

Gdy już zaczniesz budować aplikację czasu rzeczywistego z Firebase jako zapleczem, nie jest wliczone tworzenie części serwerowych — ponieważ NoSQLs tego nie wymagają. Tak więc w perspektywie krótkoterminowej opracowanie tej platformy może zająć mniej czasu. Gdy zechcesz stworzyć prostą aplikację, z niewielkim backendem, który nie wymaga dużych ilości danych, możesz szybko wdrożyć Firebase do projektu. Gdy masz ustalony termin lub zbliżające się wydarzenie, Firebase może być przyzwoitym rozwiązaniem tymczasowym.

2. Firebase to rozwiązanie działające w czasie rzeczywistym.

Jeśli potrzebujesz natychmiastowych powiadomień push i aktualizacji, potrzebujesz tak zwanej aplikacji w czasie rzeczywistym. W przypadku Firebase napisano na to wiele ćwiczeń z kodowania - a niektóre z nich pokazują, jak zbudować aplikację do czatu na różne platformy:

• iOS
• Android
• Sieć

Co daje nam powód do dostosowania się – ze wszystkimi zaletami i wadami Firebase spełnia potrzeby aplikacji do komunikacji w czasie rzeczywistym.

3. Tworzenie Firebase jest dość bezpiecznym rozwiązaniem.

Dopóki Firebase opiera się na infrastrukturze Google, daje to dobry powód, aby stwierdzić, że jest to dobrze chronione rozwiązanie. Chociaż możesz podwoić swoje bezpieczeństwo, definiując zasady bazy danych NoSQL, ponieważ domyślnie nie masz kontroli nad przechowywanymi danymi - jest ona hostowana na serwerach Google.

Nie ma róży bez kolców.

Jeśli więc chcesz, aby z Twojego produktu korzystały tysiące osób – Firebase może okazać się bezwartościowym rozwiązaniem.

Po wybraniu Firebase jako podstawowego stosu zaplecza należy wziąć pod uwagę kilka kwestii. Nie wady korzystania z bazy Firebase, tylko rzeczy, o których musisz wiedzieć. W Firebase masz swobodę wyboru planu cenowego — ale ten, który pasuje do aplikacji czasu rzeczywistego, to plan „ płatny na bieżąco ”. W ramach tego planu płacisz tylko za zasoby, które zużywasz, więc im więcej użytkowników uzyska Twoja aplikacja, tym więcej będzie Cię kosztować utrzymanie zaplecza.

Wiele osób uważa to za większy plus - ponieważ wielu użytkowników twojego produktu jest fantastycznych, prawda? Jednak na samym początku ciężko jest spieniężyć je wszystkie – musisz najpierw sprawić, by ludzie pokochali Twój produkt. W przypadku Firebase możesz wydawać pieniądze na wszystkich swoich bezpłatnych użytkowników. Jeśli więc chcesz, aby z Twojego produktu korzystały tysiące osób – Firebase może okazać się bezwartościowym rozwiązaniem.

Plotka głosi, że Firebase ma również ukryte koszty, gdy po szybkim wzroście liczby użytkowników lub użytkowania możesz zostać obciążony bez ostrzeżenia; więc jeśli nie martwisz się, że zostaniesz po cichu naładowany - zrób to.

Dlatego kolejną przyzwoitą opcją backendu dla Twojej aplikacji jest backend Ruby + pewien serwer do przechowywania danych (jest to podejście, które często stosujemy podczas pracy nad projektami naszych klientów). Poza tym backend Ruby on Rails i plusy Firebase są mniej więcej takie same. W przypadku Rubiego przebiegają one następująco:

1. Ruby to prosty język.

Jest krótka lista frameworków do zaimplementowania na nim, nawet w porównaniu z językiem PHP i jego kodem źródłowym, ale jest wiele perełek - kompletny system wielofunkcyjnych bibliotek dla Rubiego. Równie prosty jest wzorzec architektury języków - MVC, z wyraźnymi zależnościami encji.

Przeczytaj więcej o rodzajach i funkcjach wzorów architektonicznych

2. Społeczność Rubiego przetrwała próbę czasu.

W przeciwieństwie do nowo powstałego społeczeństwa programistów Firebase, społeczność Ruby jest gigantyczna, ma mnóstwo klejnotów open-source, które pozwalają programistom szybko otwierać i rozwijać złożone aplikacje. Co więcej, ze względu na pewną „sławę” Rubiego, wiele znanych serwisów (takich jak Stripe) ma gotowe biblioteki dla Rubiego.

3. Możesz przetestować swój kod na Ruby.

Ruby posiada zaawansowaną infrastrukturę programistyczną, która pozwala maksymalizować i pisać testy jednostkowe w całym projekcie - w celu zmniejszenia błędów w nowych i istniejących funkcjach. Obniży to również koszty przyszłej zmiany w trakcie procesu rozwoju.

4. Nie jesteś przywiązany do określonego typu bazy danych.

A dokładniej do konkretnego typu bazy danych. Ruby pozwala na korzystanie z dowolnych relacyjnych lub orientalnych baz danych, a także NoSQL i innych różnych technologii - w tym Elasticsearch, Reddis i innych mniej popularnych.

5. Składnia Rubiego to bułka z masłem.

W Rubim nie ma typów danych - i, odpowiednio, nie ma potrzeby sprawdzania, czy typy danych są odpowiednio ustrukturyzowane. Ponadto obecny jest również system błędów komponowalnych (zwany również systemem rejestrowania); ułatwia to wyszukiwanie błędu, a następnie pozwala na szybsze naprawianie występujących błędów.

SO, Firebase a RoR – który wybrać i kiedy?

Po porównaniu Firebase vs Rails odpowiedź dyplomatyczna brzmi - zależy to głównie od Twoich celów.

Firebase jako zaplecze do tworzenia aplikacji mobilnych przyda się, jeśli potrzebujesz jednego z następujących elementów:

• Mała aplikacja działająca w czasie rzeczywistym z prostymi funkcjami
• Prosta aplikacja, w której musisz przechowywać ładunki i ładunki
• Sprawdzająca się w koncepcji aplikacja, która zostanie później w pełni odnowiona

Chociaż jeśli chcesz stworzyć złożony system mobilny z zakłopotanymi algorytmami i funkcjami, backend aplikacji mobilnej Ruby on Rails również jest świetnym wyborem. Poza tym, jeśli aplikacja nie ma przejrzystej struktury, w nierelacyjnej bazie danych, jaką niewątpliwie jest backend Firebase w chmurze, nie da się właściwie wyselekcjonować z niej danych. Logika biznesowa tworzona w Firebase jest często umieszczana w bazie; z tego powodu może pojawić się mish-mash, gdy logika aplikacji jest nieco zakłopotana. I nie zapominajmy, że opłata jest naliczana za każdym razem, gdy zdobywasz nowego użytkownika, nawet bez informowania o tym – Twoje pieniądze mogą zostać po prostu przelane pewnego ranka, gdy się obudzisz.

Mam nadzieję, że przeczytanie tego artykułu pomogło Ci dowiedzieć się, jak korzystać z Firebase w tworzeniu aplikacji mobilnych – jeśli uważasz, że odpowiada Twoim potrzebom.

Przeczytaj też: React Native vs Native App Development – ​​którą wybrać?

Napisane przez Olega Tsarenko i Elinę Bessarabovą