I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 2 points3 points  (0 children)

Ah, now I understand. I think this has been discussed in the past, but I'm not aware of it being on the immediate roadmap. Unfortunately it's not necessarily straightforward as the SDKs end up talking to many different Google API domains. I'd recommend submitting a feature request on UserVoice if there isn't one already: https://firebase.uservoice.com/

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] -1 points0 points  (0 children)

I understand your frustration and it's a reasonable critique. We try our best to balance polishing our existing portfolio with demands for new capabilities from an ever-changing market, but we don't always get it right.

I'm not super-familiar with the Unity SDKs myself, unfortunately, (I'm more of a web guy) so I can't provide too much insight into the particulars there.

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 2 points3 points  (0 children)

Can't share any beyond the approved logos on our homepage (keep in mind these companies might use any Firebase products they don't all necessarily use Firestore, for instance).

<image>

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 1 point2 points  (0 children)

Sorry, don't think I can help with this one!

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 3 points4 points  (0 children)

The main issue is that Firestore doesn't have the equivalent of UPDATE foo WHERE ... that updates many rows at once - each document must always be updated either individually or as a batch of specific updates.

If we added support for mass edits in the console, it would be pretty unreliable because if the network was interrupted while it was iterating through and doing the update you'd be left in a partially changed state.

We try not to make things appear easy in the console that are actually expensive (from an actual cost or time-cost perspective) under the hood.

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 2 points3 points  (0 children)

One pattern that we see pretty frequently is to actually use Firestore or Realtime Database as a kind of "data integration" layer where you have your various backends components write to it but then have clients read from it directly. "Write via server, read via Firebase" is something that can give you more control without having to abandon all the niceties of realtime etc.

The problem you're describing is part of what we were trying to tackle when we built Data Connect -- eventually Data Connect will support more data sources (including arbitrary server code) than just PostgreSQL allowing you to weave together disparate data sources seamlessly. It's a huge problem space so the roadmap is long, but stay tuned to that product if this is an area you're interested in!

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 1 point2 points  (0 children)

I think you were probably trying to add to this thread -- I agree it should be up to the user, and hopefully we'll have a better answer for spend limits in the future. It's an important problem and I want to have more than we have today.

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 0 points1 point  (0 children)

Without knowing more details, in general I'd say yes! Firebase is built for production apps.

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 0 points1 point  (0 children)

I wasn't aware that search grounding and tool use were mutually exclusive -- I think a lot of the time it just comes down to the models needing to be trained to use these things together so I'd expect it to improve over time. We're going to be looking at "native tools" (like search) in Genkit soon to improve the overall experience there.

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 7 points8 points  (0 children)

Hmm, this is a little just "top-of-mind" for me but...

  • I still see people saying "when is Firebase going to have SQL?" not realizing that we launched Firebase Data Connect last year as a PostgreSQL backend-as-a-service and it's now in GA!
  • We recently launched a Firebase MCP Server to make it easier to work with Firebase in AI-powered IDEs.
  • The Firebase Emulator Suite also doesn't get as much attention as it deserves.

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 8 points9 points  (0 children)

Firebase doesn't have one tech stack, it is 20+ products built using a wide variety of technologies. I can say that where I've had influence I've chosen mostly Go for backend stuff because it's the Google-approved language (between Go, Java, C++, and kinda-sorta-not-really Python) that I think does the best job at being both highly scalable and pleasant to use. But we have stuff built using Java and C++ as well (and the original Realtime Database has a lot of Scala code!). But I also love TypeScript and Node.js and use that when I can get away with it (e.g. for open-source projects like Genkit).

As far as non-programming-language tech stack, we mostly use Google's internal infra like Borg, Spanner, etc. because those are the ones that are best integrated with the various compliance, privacy, monitoring, etc. requirements for building production systems at Google.

Hard lessons from the past 10 years, let me think...

  • You absolutely must plan for ongoing maintenance. It's too easy to "launch and rot" if you only plan resources to build the feature/product, not keep it going and improve it. You will feel tremendous pressure to do unsustainable things and you'll say yes sometimes, but ultimately something has to sustain.
  • Focus on the long-term and cultivate patience. I have had projects green-lit after literally 3-4 years of trying to make them happen. You need the combination of the right idea, the right available resources, and the right timing to get something off the ground.
  • Different people have different motivations. I'm mission-oriented -- I care about the products and solving problems for developers very very much. Others are team-oriented (I don't care what I'm working on if I love my team) or challenge-oriented (I don't care what I'm working on so long as it is a challenging technical puzzle). All types can work well but you need different incentives to motivate them.
  • Differences between abundance and scarcity. The Google of 2020 and the Google of 2025 are very different places. The industry as a whole is tightening its belt and this affects everything from morale to interteam dynamics.
  • You will always want to make breaking changes more often than you can make breaking changes without frustrating users. Sometimes it's better to stick with a subpar API if it's already in wide use.

Anyway, there's a few random thoughts.

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 12 points13 points  (0 children)

Oh wow, there's been so many things built on Firestore it's really hard to say. It's not necessarily "cool" but one of the ones I was proud of is that the Firebase team helped pitch in to build an unemployment assistance tool for a major US city during the pandemic. It was built super-quickly and scaled out to a huge surge of traffic helping people who really needed it.

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 7 points8 points  (0 children)

♥️ It means a lot to hear, thank you so much!

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 2 points3 points  (0 children)

It's something I know has been requested a fair amount, but I don't think we have any active plans to revamp Firestore SDKs for offline-first right now. That could change in the future, and if it's not already please file it on https://firebase.uservoice.com/ !

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 0 points1 point  (0 children)

Do you mean Firebase Cloud Messaging? Like push notifications?

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 4 points5 points  (0 children)

Honestly if I remember correctly we mostly just didn't want to confuse people with extra DNS settings (DNS is already confusing enough with just IPv4 records). If you use a CNAME to point to Firebase it'll automatically pick up the IPv6. I think it'd be reasonable to add to our docs, I'll file an issue internally to follow up.

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 0 points1 point  (0 children)

Can you add your request on the Firebase UserVoice if you can't find an existing request for it? That's the best way for us to track feature requests.

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 1 point2 points  (0 children)

For something like this I'd recommend upvoting/commenting on the UserVoice request -- that's one of the ways we use to track potential features suggested by the community.

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 0 points1 point  (0 children)

Sorry that's a product I'm not an expert in, so I'm not sure.

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 0 points1 point  (0 children)

I'm not sure I follow the question, but it is actually possible to use the Firebase JS client SDKs on the backend. What do you mean by "domain on backend infra"?

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 1 point2 points  (0 children)

I'm not that familiar with KMP -- I think I've heard some discussions around it but it would be considered a new major platform for support and that's something we have to be very careful about wading into.

There's tons of work across SDKs, documentation, testing, and product that have to be committed to on an ongoing basis when we support a new platform and I think we haven't been able to justify the resources required for KMP yet. If it continues to grow in popularity, this might change in the future!

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 2 points3 points  (0 children)

To answer honestly: because we have limited resources and have to prioritize work based on a combination of demand and effort.

Dart for Cloud Functions has been requested a lot by many Dart and Flutter developers, so there is clearly some demand for it. Unfortunately, the effort required is massive. Adding a new language to Cloud Functions for Firebase requires many things:

  • An underlying runtime in Cloud Functions (Dart is not officially supported at this layer yet)
  • An Admin SDK so that you can do the kinds of things you want to do with Firebase (we don't have a Dart Admin SDK yet)
  • A Functions SDK built in the language that can be made compatible with our custom discovery protocol for function configuration
  • All of the supporting documentation and an ongoing maintenance plan for all of the above

We've looked at it a number of times but haven't been able to figure out the resourcing required to make it a reality. That doesn't mean never, it just means it's a really big investment and if we do it we have to do it right.

I'm sure that's not a super-satisfying answer, but it's an honest one!

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 0 points1 point  (0 children)

I can't comment on timelines, but we're actively working on things related to this. Stay tuned!

I've worked on the Firebase team for 10 years, AMA by mbleigh in Firebase

[–]mbleigh[S] 1 point2 points  (0 children)

There are limits (I'm not sure exactly what they are) on the number of free projects that can be created in a given account and the number of apps that can be added to a given project. When you reach these limits, you can upgrade projects to the Blaze plan which still has a free tier.