Flexibility for shared client/admin code?

[IsaiahByDayah]

Im sure a lot of this will be me getting ahead of myself, but I figured it'd be worth sharing? After looking through the docs a bit, something popped into my head.

One of the things that the new modular approach to Firebase might allow for is true client/admin code sharing, no?

For instance, in my app I allow users to manipulate documents (adhering to Firestore rules), but I also manipulate those same docs in Cloud Functions (where I want to ignore rules).

Even though these are different environments, the documents and the logic behind the manipulation are the same (get doc A, update field X, Y, and Z), BUT with the current admin/client it's extremely difficult (impossible?) to write cross-environment code. I find myself maintaining similar helper functions for both places

BUT, with the new modular approach, interacting with Firestore (seemingly) looks to be abstracted away from the app? So it seems like in the future we could be at a point where we can do something like...

// in shared package
import { doc } from "firebase/firestore"
const doThing = (db: FirebaseFirestore, path: string) => {
  const docRef = doc(db, path)
  docRef.update({...})
}


// In The Browser
import { doThing } from "shared"

const clientApp = initializeApp({ /* config */ });
const clientDB = initializeFirestore(clientApp, settings);

doThing(clientDB, "/test/abc") // Works fine so long as it doesn't fail any rules



// In Cloud Function
import { doThing } from "shared"

const adminApp = initializeApp({ /* config */ });
const adminDB = initializeFirestore(adminApp, settings);

doThing(adminDB, "/test/abc") // Also works fine! Ignores any rules

Being able to abstract out business logic like this into modules could really open up the ability for people to build tools on top of Firebase that makes it even easier to get up and running with things.

I could see a world where full firebase-plugins can be created? Imagine something like...

  // Browser Environment
  import Chat from "firebase-plugins-chat"

  const chat = new Chat(clientApp)

  ...

  const unsubscribe = chat.room("abc").onMessage((data) => {
    const { from, message } = data
    ...
  })

  ...

  chat.room("abc").send("Hello, World!")

  // Cloud Function
  import Chat from "firebase-plugins-chat"

  const chat = new Chat(adminApp)

  export const requestToJoinRoom = functions.onCallable(async (data, context) => {
    const user = await getUserFromContext(context)

    chat.user(data.room.admin.id).send(`${user.name} wants to join room "${data.room.name}"`)
  })

Have something handle the logistics of collections, sub-collections, document data structure, etc. and you just get a nice exposed API to use. Sort of like how Firebase Extensions work but more modular?

Idk, like I said I'm sure I'm getting far ahead of myself and I'm not even sure if this is the right place to discuss this sort of thing, but it sure would be cool if stuff like this becomes a possibility due to the flexibility of the rewrite. If it's already possible to do something like this I would LOVE some resources cause I've tried and (in TypeScript at least), it seems like the client-sdk and the admin-sdk are too different to have any sort of abstracted logic module.

Looking forward to all the great work you guys are doing and excited to play around with the new alpha stuff!

[samtstern]

Thanks for the thoughts! I have a few thoughts here as well. I have a personal project where I use Firestore in my JS frontend and my Node.js backend and I definitely duplicate a lot of helpers! But I am not one of the decision-makers for Admin SDK or Web SDK things so take my thoughts with a grain of salt:

• At this time we don't plan to re-do firebase-admin in the new Modular style, it would be a huge breaking change without the benefits of tree-shaking. Our general opinion is that the non-Modular SDK has the more ergonomic API but we're willing to sacrifice that to make Web apps small and fast. So right now that wouldn't make sense for Admin. Of course if all developers tell us they like the new style even without the size benefits, we could reconsider!
• I come from an Android background and over there we have a similar thing. Android developers frequently use the Java Admin SDK on their backend. There was a time when we were able to unify most of the types so that developers could share common Firebase code between the backend and frontend. Over time though that meant our SDKs were sort of non-idiomatic on both platforms. Eventually we decided to break away from this and make our Admin SDK more server-Java friendly and our Android SDK more mobile-Java friendly, which improved both SDKs. Maybe Web and Node will always be closer together than Android and Server Java though!

[kossnocorp]

I work on Typesaurus, a universal Firestore ODM that allows using the same code in web and Node.js (and even React Native): https://github.com/kossnocorp/typesaurus

Once the new Firebase SDK is generally available (or even earlier), I'll use the new SDK.

[IsaiahByDayah]

By that do you mean you'll move away from using typesaurus? Or that you'd be integrating the new sdk into typesaurus?

Either way this looks cool. Will have to try it out!

[kossnocorp]

Sorry I wasn't clear. I meant I will integrate the new SDK into Typesaurus when it's ready for the public.

[nthonymiller]

Just wanted to make comment on sharing of code.

The sharing of types/interfaces between the client-sdk and admin-sdk, would provide the ability to code share.

Currently FieldValue is different between both version, as well as converters interface.