Does firebase/firestore reuse firebase/firestore/lite?

[kossnocorp]

Hey, first of all, I like the change a lot!

I'm wondering if firebase/firestore uses code from firebase/firestore/lite to perform one-time read operations? In other words, when I first import firebase/firestore/lite and then import firebase/firestore, will the code responsible for one-time operations be downloaded again?

[peterpeterparker]

Indeed good question. As for example, is there a difference between import import { serverTimestamp } from "firebase/firestore"; or import { serverTimestamp } from "firebase/firestore/lite"; assuming I use both in my apps?

[Feiyang1]

@kossnocorp The way we think about firestore and firestore/lite is that they are 2 separate packages with very similar API but different implementations. Though they share some implementations today, we don't guarantee they will be the same going forward, so we just build them separately as independent packages.

That said, sharing code between firestore and firestore/lite can potentially reduce bundle size if you use both of them in your project - for example, use firestore/lite to get data for fast initial rendering, then dynamically load firestore to listen to realtime updates, so it makes sense they share code at runtime.

But I don't think we want to say some APIs are interoperable between firestore and firestore/lite, because 1. it might not be the case at some point in the future and we don't want it to be a breaking change 2. it can be confusing to users to remember which APIs are interoperable and which ones are not. @schmidt-sebastian Any thoughts?

When you say shared code between these two modules, do you mean the code within the SDK, or user code you write that can work on both modules?

[schmidt-sebastian]

Both SDKs share some code, but this is mostly an implementation detail. The types are not meant to be compatible and are not meant to be used interchangeably between SDKs. We may in the future make it easier to "upgrade" from firestore/lite to firestore, but for now we have no work scheduled.

[kossnocorp]

Gotcha, thank you for the elaboration!

Just in case if you're curious why I'm asking: I build a Firestore ODM and thought about using the lite version while users do only-time fetches and switch to extended version when they require realtime.

When you say shared code between these two modules, do you mean the code within the SDK, or user code you write that can work on both modules?

I mean code within the SDK.

[Feiyang1]

I see. Just to make sure I understand you correctly, you'd like the 2 modules to share code because it will result in smaller bundler size for your library, or is there something else I missed?

[kossnocorp]

Now after I thought about it a bit more I realized it won't make any difference unless this shared code is imported asynchronously. Even then it might not give any benefits because of gzip.

I import SDK asynchronously, only when the user access Firestore for the first time. For example scenario:

1. When the app loads, only the ODM code is downloaded.
2. User opens a page with a one-time query.
3. ODM imports firestore/lite and performs the one-time query.
4. User opens another page with a realtime query.
5. ODM imports firestore and perform the query.

If firestore and firestore/lite would share some code, at 5th might perform faster. But only if it would be imported asynchronously by firestore and firstore/lite modules.

All in all, I don't think it's worth it unless firestore/lite could be heavily reused by firestore.

[Feiyang1]

firebase/firestore and firebase/firestore/lite don't share code at runtime. One-time operations are implemented differently in them, where the ones in firebase/firestore support latency compensation and cache. So yes, if you import one-time operations from both entry points, you will download 2 implementations of them.

[peterpeterparker]

Thank you for the answer @Feiyang1

[kossnocorp]

Thank you, good to know that!