Google neemt softwarebedrijf Firebase over

Google heeft de start-up Firebase overgenomen. Firebase levert aan developers van mobiele apps op iOS en Android back-end-diensten die het via een api mogelijk maken om realtime-apps te bouwen. De Firebase-diensten zullen op Googles cloudplatform beschikbaar komen.

Volgens Firebase maken meer dan 110.000 geregistreerde softwareontwikkelaars gebruik van zijn diensten, Met Firebase kunnen onder andere mobiele apps gebouwd worden die offline zijn te gebruiken; data wordt pas gesyncd met de Firebase-databases als er weer een internetverbinding is.

Ondanks de overname door Google belooft het bedrijf dat alle diensten beschikbaar zullen blijven en dat het ook de huidige ondersteunde platformen zal blijven bedienen. De start-up is van mening dat zijn diensten complementair zijn op die van Google. Wel zou het Firebase-platform flink opgeschaald worden voordat het beschikbaar moet komen op Googles cloudplatform.

Hoeveel Google heeft betaald voor het drie jaar oude Firebase is niet bekendgemaakt. Mogelijk zal Google de toevoeging van nieuwe Firebase-functionaliteit op Google Cloud volgende maand aankondigen: op 4 november zal de internetgigant het Google Cloud Platform Live-evenement organiseren.

Reacties (23)

[dirkpostma]

Ik mis bij Firebase nog (erg) de mogelijkheid om ietwat geavanceerde queries te kunnen runnen. Maar dikke kans dat ze binnen afzienbare tijd net zo veel kunnen als bv. MongoDB. Ik zie op zich veel toekomst voor Firebase! Grootste nadeel zal zijn dat je als bedrijf niet te afhankelijk wilt worden van een third-party waar niet zonder meer een replacement voor is.

[Verwijderd]

Ja in vroeger tijden kocht je hier gewoon een library voor, dan wist je zeker dat je data veilig was, en dat de dienst niet van de ene op de andere dag stopt met bestaan (bijvoorbeeld door een overname). Bovendien wist je dat de API stabiel bleef, en alleen veranderde als JIJ dat wilde (door een update te installeren bijvoorbeeld). Nu ben je overgeleverd aan de grillen van een bedrijf. Brrrr.

[Verwijderd]

Nu ben je overgeleverd aan de grillen van een bedrijf.

Daar hebben ze een heel handig documentje voor uitgevonden. Het heet SLA ofwel Service Level Agreement.

En ik vraag me af hoe een library gegevens gaat synchroniseren in een Cloud. Die ontstaat niet spontaan als je gegevens upload. Of bedoel je dat je gegevens opslaat op een website, waardoor je toch weer afhankelijk bent van een bedrijf? Tenzij je zelf het hele beheer op je neemt. Inclusief het patchen en bijhouden van security, waardoor je ongeveer weer net zo veilig bent als bij een third party.

[kozue]

En wat voor SLA verwacht je op een gratis dienst?

[edit:]
En een library synchroniseert niet met een cloud. Dat is het hele idee: geen hippie cloudmeuk te hoeven gebruiken. De library zal gewoon de data in een zelf beheerde database opslaan, die je zelf ergens kunt (laten) hosten (als je het zo goedkoop mogelijk wilt kan het nog op je webserver). Uiteraard heb je iemand nodig die weet hoe je een database beheert, maar die zijn er genoeg te vinden, en je bent nooit afgehankelijk van de grillen van een extern bedrijf met een onvervangbaar component in je site.

[Reactie gewijzigd door kozue op 24 juli 2024 07:33]

[Verwijderd]

En wat voor SLA verwacht je op een gratis dienst?

Als je Firebase een beetje professioneel wil inzetten in je app, zou ik persoonlijk niet gaan voor de gratis dienst. Dat is hooguit leuk in de ontwikkel/testfase.

die je zelf ergens kunt (laten) hosten

Waarmee je alle nadelen ook krijgt. Als je het zelf host moet je security expert worden, en als je het laat hosten ben je weer overgeleverd aan de grillen van een bedrijf. Laat je een eigen database ergens hosten, heb je zelfs beide nadelen. Je moet en zelf de security van je database maar waarborgen, en het bedrijf kan er morgen mee ophouden.

[kozue]

En als die grillen je niet bevallen ga je gewoon naar een ander bedrijf die hetzelfde aanbied. Er is niet 1 maar honderden database providers die allemaal hetzelfde software pakket leveren.

[Verwijderd]

Dat is een afweging. Ga je het synchronisatiewiel zelf uitvinden met een generieke database, of leg je dat bij een cloud aanbieder.

Bij de eerste kan je idd redelijk snel wisselen. Bij de tweede kan dat net zo goed, het zal alleen iets meer inspanning kosten. Want voor Firebase zijn er natuurlijk net zo goed concurrenten.

[Balance]

"Met Firebase kunnen onder andere mobiele apps gebouwd worden die offline zijn te gebruiken; data wordt pas gesyncd met de Firebase-databases als er weer een internetverbinding is."

Ik hoop dat dit meer en meer gebruikt gaat worden. Als ik opsta zou ik graag willen dat terwijl ik aan het ontbijt zit over wifi mijn krant wordt binnengehaald, het weer wordt bekeken en offline kaarten worden vernieuwd. Als je op zo'n manier met je data omgaat kan je zonder problemen 80 tot 90% van je mobiele data besparen.

Bij bijna elke app kan zo'n principe gebruikt worden: Alles binnenhalen als je op wifi zit, en alleen wat je echt nodig hebt als je op een mobiel netwerk zit. Zo vind ik het helemaal niet erg als Facebook 500MB of zelfs een gigabyte aan cache opneemt om alles wat mijn vrienden, groepen en pagina's in het afgelopen 48 uur hebben gepost op te slaan, plus hun profielen. Dan kan 90% van wat je bekijkt van je device worden geladen en de andere 10% als je iets specifieks opzoekt over het mobiele netwerk.
Mijn NRC app mag best een paar honderd MB gebruiken van mijn opslag om de kranten van de afgelopen 3 dagen op te slaan, zodat ik deze niet over een mobiel netwerk hoef te laden. Spotify mag gigabytes aan muziek offline opslaan, zodat ik dat niet hoef te streamen. Nu.nl mag alle artikelen van de afgelopen week opslaan (en foto's van de afgelopen 48 uur), tekst kost toch geen drol aan opslag. Whatsapp mag alle foto's en video's binnenhalen zodra ik wifi heb. Nokia HERE maps mag zo een gigabyte aan data opslaan als dat betekend dat ik nooit meer mobiele data aan mijn navigatie verstook.

Een erg snelle SD-kaart van 64GB kost €35 en die kan je jaren gebruiken. Kijk eens wat je nu voor 1GB aan data betaald per maand, en hoeveel je kan doen en besparen als apps beter vooraf gegevens opslaan op je device. Een app moet vooruit denken wat je de komende dag nodig hebt en welke gegevens je over een langere tijd vaak gaat gebruiken, en dat opslaan zodra het wifi heeft.

[kozue]

Ieder z'n eigen mening. Ik gebruik mijn databundel toch nooit volledig, het maakt me echt niet uit of er een paar artikelen meer over minder over de verbinding heen gaan. Opslag gebruik ik echter liever voor iets nuttigs dan cache voor dingen die je toch nooit gaat gebruiken. Leuk als jij een sd kaart hebt van 64gb, maar een iphone met 16gb is zo vol.

Behalve dat:
- ik zit niet te wachten op derde partijen die informatie over mij aan google door gaan geven. Ik vermijd google zo veel mogelijk, ik vind het een walgelijk bedrijf geworden dat niks om de privacy van klanten en niet-klanten geeft.
- je reactie heeft niks met firebase te maken want het is geen caching dienst maar een database die toevallig caching mogelijkheden heeft.

[Verwijderd]

Haha geloof me, firebase is in 1,5 jaar niet meer wat het nu is. Doet google bijna iedere keer. Vriend van me werkt bij google. Ook overgenomen, binnen 1,5 jaar stond iedereen op straat, behalve diegene die intern binnen google een plek vonden. Verder werden de overgenomen diensten stop gezet. De informatie draait het ze meestal om of de patenten.

[jbtbnl]

Ik denk dat de kans reeel is dat Google op de een of andere manier deze technogie gaat integreren met AngularJS. Tot nu toe heeft AngularJS nog geen eenduidige manier om modellen via API's te binden. Hier zijn nu dan ook allerlei 3rd party libraries voor om dit gat te vullen, maar dat is ongunstig voor de uniformiteit binnen het verder zeer geordende AngularJS platform.

Edit: met integreren bedoel ik tot standaard maken. Dat het nu al samenwerkt met AngularJS lijkt me duidelijk.

[Reactie gewijzigd door jbtbnl op 24 juli 2024 07:33]

[Verwijderd]

AngularJS is toch client side? Je zou zeggen dan dat ze juist met de client DB van de browser iets moois kunnen maken. Maar dat heeft toch niks te maken met Firebase?

[Verwijderd]

binnen 1,5 jaar stond iedereen op straat, behalve diegene die intern

Sommige overnamen zijn voor de patenten, sommige om kennis in huis te halen. Je kan moeilijk hard maken dat jouw hondje Fikkie heet, dus heten alle hondjes Fikkie.

Wel bijzonder overigens: iedereen stond op straat, maar niet iedereen.

[Verwijderd]

Over 1.5 is er gewoon een open-source versie van firebase denk ik.

[Verwijderd]

Natuurlijk kan een cloud wel op opensource componenten gebouwd worden. De Cloud staat volledig los van open of closed source.

[Gersomvg]

Backend van urenregistratie applicatie die ik gebruik is gebaseerd op dit platform. Werkt prima!

Zelf ook nog wel eens naar gekeken, maar het grootste gemis van iets als dit blijft denk ik toch de beperkte backend controller logic mogelijkheden..

[Verwijderd]

Naast een Java (Android) en Objective-C (iOS) interface heeft het ook Javascript (Web) en REST interfaces. Dat maakt het toch best breed inzetbaar, niet alleen voor mobiele apps.

[BarôZZa]

Firebase is een prima dienst met mooie mogelijkheden. Helaas heb ik na de registratie nooit echt de tijd gehad om er iets mee te ontwikkelen. Doordat de dienst ook nog maar kort bestond leek het me niet verstandig om er flink wat tijd in te investeren. Je ziet namelijk wel vaker dat dat soort diensten worden overgenomen en vervolgens worden afgeschoten. De overname door Google is in mijn ogen echter wel gunstig. Google's cloudplatform is ook een prima service en samen moeten er mooie dingen mogelijk zijn.

Moet ook zeggen dat Firebase het slim heeft gespeeld. Zij hebben flink ingezet op zaken als WebRTC, Android en AngularJS. Zaken waar Google een flinke vinger in de pap heeft. In veel gevallen maakten ze het makkelijker om mee te werken dan Google met haar cloudoplossing. De overname is dan ook een erg logische.

[Verwijderd]

Overigens denk ik dat die security rules binnen firebase zo ingewikkeld (en gewoon ontoereikend) zijn, dat menig app-developer steken zal laten vallen, en het voor een hacker heel simpel is om zo grote hoeveelheden illegale data uit firebase te halen.

[Verwijderd]

Betekent dit dat Google nu inzicht krijgt in de data van honderden duizenden bestaande apps?