There are currently two versions of the Firebase APIs, one that is namespaced and one that is modular. For at least a year, I brushed off the notion that they were different and was repeatedly confused/frustrated when VS Code would lint the Firebase methods I’ve known and loved. Today, I finally decided to educate myself.
Google has a brief explanation about why new apps should use the modular API. Long story short, code organized into modules allows build tools to remove unused code in a process known as “tree shaking”. Code organized using namespaces, does not allow for this type of optimization.
That makes sense.
Unfortunately, the way Google implemented the modular API destroyed the API’s discoverability and made it pretty difficult to get used to. All functions are now isolated from one another and queries must be built from parts instead of chained together.
In other words, the new syntax is the complete inverse of the original namespaced API. It looks like the namespaced code is being turned inside out. Just look at this line:
Why is the database instance buried three layers deep in the query?
This is a cut and dry case of tree-shaking and bundle size being prioritized over developer ergonomics.
What makes this change even worse is that the NodeJS API continues to use the “namespaced” API. This makes it rather easy to put yourself in the mentally taxing position where half of your stack uses an intuitive Firebase API while the other half reads like something GPT-2 would write. For example, Cloud Functions written in TypeScript use the original namespaced API. Code switching between these two interfaces can be crazy-making…but for now that’s just the way it is.
For this example, I’ll walk through using the Firebase Admin SDK in Firebase Cloud Functions. Cloud functions are considered a “privileged environment” so using the Admin SDK here is generally safe.
This code will run the required initializeApp() method as soon as your Cloud Function is activated. Then, in other files, you can use the admin object by importing it:
The Admin SDK gives you access to Firestore, as well as nearly every other Firebase product, via an appropriately named method on the admin instance. To interact with Firestore:
const db = admin.firestore();
The namespaced API let’s you do basically everything by using methods on instances. In the code below, collection(), doc(), and set() are all methods that intuitively chain together to do something that reads like a sentence - “In the “cities” collection, find the “LA” doc and set it’s data:
const data = {
name: 'Los Angeles',
state: 'CA',
country: 'USA'
};
// Add a new document in collection "cities" with ID 'LA'
const res = await db.collection('cities').doc('LA').set(data);
To interact with Firestore, you first need to initialize it and retrieve a reference to the “service”:
// Pass in the initialized app from above
const db = getFirestore(app);
Now, instead of using chained methods like in the namespaced API, you need to use specific functions for action you want to take. For example, addDoc, setDoc, deleteDoc, etc:
console.log("Document written with ID: ", docRef.id);
} catch (e) {
console.error("Error adding document: ", e);
}
In my opinion, this provides a much worse developer experience. Instead of ctrl-spacing your way from one method to the next, you need to remember everything. That sucks.
Since Astro components cannot provide interactivity, you need to create a React component called CopyAsMarkdown.tsx which will handle copying the page content to the user’s clipboard.
This component should accept the page’s title and content as props:
In typical Google fashion, the google_sign_in package was updated recently and if you missed the migration guide, your apps are broken. In this post, I’ll walk you through using version 7.1.0 of the google_sign_in package with Firebase and Flutter.
To get started, add the newest google_sign_in version to your pubspec.yaml:
google_sign_in: ^7.1.0
If you don’t have one already, create a new Firebase project in the Firebase console and then navigate to the authentication tab. Under “Sign-in method”, select “Add new provider” and choose “Google”.
Once you have the client ID, add it to your environment variables file. I typically create a config.json file in my assets folder and load my variables from that using String.fromEnvironment:
GoogleSignInException(code GoogleSignInExceptionCode.unknownError, [28444] Developer console is not set up correctly., null)
As pointed out in the docs, “[clientId] is the identifier for your client application, as provided by the Google Sign In server configuration”. In other words, you need to set the serverClientId to a web client ID on Android, not an android client ID.
Failed to sign in with Google: GoogleSignInException(code GoogleSignInExceptionCode.clientConfigurationError, serverClientId must be provided on Android, null)
Ensure that you are initializing the GoogleSignIn instance before calling any other methods.
Execution failed for task ‘:app:checkDebugDuplicateClasses’.
Querying the mapped value of provider(java.util.Set) before task ‘:app:processDebugGoogleServices’ has completed is not supported
Update the Kotlin version in android/gradle/wrapper/gradle-wrapper.properties and android/settings.gradle to the latest Kotlin version (ex. 8.10):