Comment by magsafe | Hacker News Reader

Comment by magsafe | Hacker News Reader

One thing I didn't see mentioned in this article is Firebase. It feels like a hidden gem lurking within the overall GCP offering, and may be overlooked by devs who're not doing mobile-specific work. For me, Firebase was the gateway drug that got me into GCP. I successfully built and hosted the backends for a couple of iOS apps using Firebase. The best parts were cloud functions and built-in sync (including offline/occasionally connected sync scenarios). Firebase Cloud functions allowed me to convert an AWS Elastic Beanstalk project into a 100% serverless architecture, which basically runs itself with no ongoing maintenance or scaling required. It took a significant amount of work off my shoulders. Once I had a positive experience with Firebase, I started poking deeper into the Cloud Console. I realized I could use App Engine, Compute Engine and various other services, which all made perfect sense as "upgrades" to the core Firebase project. I've now migrated the backends of 2 existing, popular iOS apps from AWS to Firebase+GCP. Kudos to the Google team for making Firebase perfect for my needs, and the overall Cloud platform.

Ya, we love Firebase! Use Firebase functions heavily and i've been very pleased. That tied with redux works so smoothly. It's a different way of thinking about things but I find it so much easier to maintain and reason about than your conventional rest service.

Couple things I wish it had:

1. Ability to `keepalive` certain functions. Cold start is real. We have gotten around this via app engine cron that triggers certain functions.

2. Schedule them on cron. We have gotten around this using app engine.

If curious, this is what we are building off of Firebase (and React native) https://itunes.apple.com/us/app/bunch-group-video-chat-games...

> One thing I didn't see mentioned in this article is Firebase.

Can confirm, I'm also building my startup off of Firebase.

Super easy to get up and running with. I was talking to a friend at Amazon about how I create serverless HTTP entpoints and he was impressed that getting started with it was a 10 minute affair from "never done backend programming" to "REST endpoint setup." Another half an hour got me full end to end auth working from my app to my endpoints through to Firebase DB. FWIW I haven't investigated what it'd take to do the same within Amazon's eco-system, but from what I've gathered I'd have to understand a few more concepts than the simple "npm run deploy" that is the heart of Firebase's serverless offering.

Firebase's serverless stuff is dead simple. Wish the emulator was better though, I can'd do encrypted endpoints on localhost, which means 90% of my API can't be tested locally. Having to deploy to the actual service seriously adds to my code-deploy-debug loop!

> I can'd do encrypted endpoints on localhost, which means 90% of my API can't be tested locally. Having to deploy to the actual service seriously adds to my code-deploy-debug loop!

Try using ngrok (https://ngrok.com/). It can forward public HTTPS to localhost HTTP.

I run a service that fixes this problem. https://serveo.net/ It uses SSH port forwarding to proxy public HTTPS traffic to your local server.

Thank you for the kind words. I'll make sure the firebase teams receive it :)

Have you migrated anything off of Firebase? Or still kept the “base” projects and upgraded around it? I’m interested specifically in how expensive Firebase is for popular products

I haven't migrated off of Firebase but this is something I've thought a lot about as I've selected Firebase for many of my client projects.

As far as I can tell there is no open-source alternative with feature parity that makes it easy to migrate away from Firebase. I'd be curious to hear about how people have done this.

This is actually what I'm afraid of - specifically vendor lock-in and being stuck with a stack that has high operating cost. From some of the comments I've seen, Firebase has high operating costs. But I'm still planning on testing this out myself with a small project soon.

Is Parse on node comparable at all?

If you like Firebase, I'd like to give a shout-out to Sanity [1]. (Disclosure: I work part-time on the backend, but I'm not an employee and I don't work on the product itself; but call this a shameless plug if you will!)

Sanity is a headless CMS, but the API itself is like a souped-up Firebase and can be used on its own without adopting the Sanity UI. It's got many of the same features -- web API, change watching via WebSockets -- but adds support for joins, fine-grained patches (CRDT-like but not actually), transaction history APIs, fine-grained document-level permissions, and many other neat things. We are particularly proud of the query language, GROQ [2], which is a very powerful superset of JSON that allows you to express transformation pipelines over structured data.

Sanity is hosted on Google Cloud, too, so performance when used inside GCP should be great.

[1] https://sanity.io

[2] https://www.sanity.io/docs/data-store/how-queries-work

Thanks for the pointer to sanity. After a quick read over the docs, it seems a really impressive piece of software.

Yes. Firebase is so awesome! It really mis fun to work with and works so well with Angular. This guy has some awesome tutorials to get started.

https://angularfirebase.com/

Yep. Firebase + GCP(app engine) is awesome.

I've heard that while Firebase is good, it has pretty high pricing once you have enough users and has a big vendor lock-in problem.

Since you were already at Amazon, I assume you compared Firebase to AWS Lambda? Could you tell us why did you end up prefering Firebase?

I'm not him but to me the big thing that Firebase has and AWS Lambda doesn't is Firebase - a database.

Firebase Functions === AWS Lambda but it's only one of 17 components that is Firebase.

Also, Authentication component is nice (easy way to implement accounts/login with Google/Facebook/Twitter/email).

I'm not him but to me the big thing that Firebase has and AWS Lambda doesn't is Firebase - a database.

Only if you are pleased using a "NoSQL" solution.

Firebase is very much easy to get started for mobile apps. You have nice console to create project, and as developer you deal with just its SDK, one CLI and simple API. For something similar to Firebase in AWS, you need to make use of Lambda, API Gateway, DynamoDB, Cognito separate products, which has steep learning curve. And then you need to know the AIM security to get started. AWS has a Mobile Hub product which is trying to make things easy to create mobile apps by automate some of these AWS products for you. So now you have to learn awsmobile CLI tool on top of the core awscli tool. And if you develop for the web, they have this AWS Amplify Javascript library on top of basic JS SDK library which has a higher abstraction thus to make things simple (or worst). If you're new to AWS, you often struggle with which library should one learn and use. And if you use AWS Ampify and read the documents, it is as if the library is build for React. I'm not sure why AWS can be so married to one web stack. So much emphasis and priority is given to React and React Native in this library. They will give the excuse that React is what their customer wants. They now have mature React/React Native Amplify library thus giving the impression that to use AWS its better to use React/React Native. So they spend resource on AWS-Amplify, even move one of JS cognate-identity-js SDK under this umbrella, hoping the world will standardised on JavaScript and React Native for iOS, Android and web. So what happen if you're developing a mobile app using Unity, Xamarin and Flutter? No luck as they only have SDK for iOS, Android and web. Compare this with Firebase that has SDK for iOS, Android, web, Xamarin, Unity, Flutter and C++. AWS has an opportunity in AppSync to make a product as easy to get started as Firebase. What is required is native mobile SDK for iOS, Android, web, Flutter, Unity, Xamarin that is not just specific to AppSync and GraphQL, but also add in authentication, analytics etc APIs. Something like Firebase SDK API. AWS is still stronger for enterprise usage. And you can’t use Firebase in China due to its use of Google Play services. But Firebase is definitely a weapon used by Google to draw customers into other Google Clouds offering.

Thanks a lot for the through response. That was very helpful!

Firebase is great, but in my little experience, as it's database grows, it becomes clunky to sort and query, especially since everything is pretty much done client side.

Try Cloud Firestore, it has a lot of improvements with querying over the RTDB. I can also confirm sorting/querying is handled server-side. (Disclaimer: I'm the PM for it and use it for my own side-projects)

Would be even better if there was a graphql frontend like AWS AppSync. Helps structure the data a lot more easily.

Firebase is great, but covered under a separate agreement with Google, and its terms aren't as friendly to corporate users. For example, they still aren't encrypting tenant data at REST. Nothing is COPPA compliant.

I'm pretty sure that's wrong.

Also: https://cloud.google.com/firestore/docs/server-side-encrypti...

"Each Cloud Firestore object's data and metadata is encrypted under the 256-bit Advanced Encryption Standard, and each encryption key is itself encrypted with a regularly rotated set of master keys."

So... yup.

Wow, sounds like my info is out of date! This was true when we last evaluated it. I really do appreciate how fast Google is on this stuff.

I lot has changed in the last year or so, might be worth looking again. Most of the backend services are under GCP's terms of service, products like Cloud Firestore all do encryption at rest, etc.

It sounds like my info is out of date, which makes me very happy considering how much I love Firebase.

> encrypting tenant data at rest

I know that this is required by various security certifications - but is there a reasonable threat model that it actually protects against?

The only one I see is someone physically stealing the hard disks out of the servers, which is impossible if you are using a trustworthy cloud datacenter instead of a server in your bedroom.

If you have customer-managed keys like parts of Google Cloud, it keeps even Google from reading your data on disk.

> The only one I see is someone physically stealing the hard disks out of the servers, which is impossible if you are using a trustworthy cloud datacenter instead of a server in your bedroom.

If you are using a public cloud data center for private data with regulations around authorized access, there is basically 100% chance that people without access authorization have physical access to the servers and their disks in a manner where there is no direct knowledge of the data owner of what occurs, which makes the threat of “unauthorized person gains physical access to the hard drive and steals data” greater, not less, than “a server in your bedroom” (or, more relevantly for corporate use cases, in a corporate data center for which you control physical security.)

Reply on news.ycombinator.com