Firebase-admin-node: FR: Reduce npm module size

Created on 25 Mar 2018  路  11Comments  路  Source: firebase/firebase-admin-node

[REQUIRED] Step 2: Describe your environment

  • Operating System version: any
  • Firebase SDK version: 5.11.0
  • Library version: 5.11.0
  • Firebase Product: auth (auth, database, storage, etc)

[REQUIRED] Step 3: Describe the problem

I recently migrated firebase-admin from version 4.x to 5.x and found a huge size increase in the modules that are installed: they are now around 100MB
In a serverless environment this at least slows down deployment time and increases function cold start time.
Note that I am using Firebase for authentication in a non-Google environment so I have to carry firebase-admin as production dependency while it might not be needed when running on GCloud.

Steps to reproduce:

Measure node_modules folder size with and without firebase-admin and make the difference: in my case firebase-admin adds 100MB to node_modules.

Feature Request:

Maybe the module can be split in atomic components: i.e: if I just need auth, I don't want to install database.
Post-install cleaning could also help.
Alternatively provide a run-only version without test tooling.

Thanks!

Most helpful comment

I have a similar use-case where I only need the firebase-sdk for cloud messaging feature/ to send push notifications, I found the SDK overkill especially since im running a serverless AWS Lambda so package size will affect my coldstart & deployment times, so I decided to go with the REST API implementation instead.

All 11 comments

Most of this (80MB+) are coming from Firestore and Storage dependencies. We are working towards refactoring them out. In the meantime you can just delete @google-cloud/firestore from the node_modules directory. That alone should save you plenty.

Thanks, unfortunately @google-cloud/firestore saves me only 500KB.

If grpc and google-gax are installed at top-level you can remove them too. In general you can remove the following if you're not using Firestore or GCS:

 55M    node_modules/grpc
 57M    node_modules/@google-cloud
 63M    node_modules/google-gax

Much better now, thanks for your help.

@hiranya911 what would you recommend in the case where we still want to use Cloud Firestore within the admin-sdk running on a lambda function? Also would this still be a problem using the admin-sdk on Firebase Cloud Functions or because it's within a google-environment would 'cold starts' not require a re-install / duplication (not actually sure how it works) of the dependencies?

firebase-admin has always been a dependency for the Cloud Functions for Firebase SDK. There's no module re-install cost in GCF, and I believe the same applies for AWS. Although AWS have other constraints that need to be worked around: https://medium.com/@samstern_58566/how-to-use-cloud-firestore-on-aws-lambda-4bf6d3a473d9

Ok thanks for clarifying yeah I managed to get Firestore working on Lambda. I'll give Firebase Cloud Functions a try and see if I can eliminate the timeouts.

Just came to this issue.

~@hiranya911 How about seperating it's modules as optional dependencies?
Actually I only use fcm(messaging) module, and manually uninstalling other module(s) in postinstall step is not a fancy way.~

~Hope I can use install and use firebase modules like @firebase/core, @firebase/messaging, etc.~

Oops sorry I misread the above conversation history on this issue.
Hope the refactoring ends soon!

Most of this (80MB+) are coming from Firestore and Storage dependencies. We are working towards refactoring them out.

@hiranya911 Any news on the refactoring? Running on a non-Google environment and my lambda only needs to initailize with service account credatials + use admin.database(). Importing exactly what's needed and skipping firestore, storage, messaging etc. would really help.

Hey @matiaslarsson. Since this issue was reported, we have changed our minds about splitting the SDK. Building and maintaining a bunch of new packages, just because of one dependency (grpc) of one service (Firestore) was overkill. Also it doesn't do any good for Firestore users, which there are great many of. And as for non-Firestore users there's the (ugly) workaround of manually removing unused grpc/firestore dependencies from node_modules.

But the good news is that the Firestore team is making progress towards changing their grpc implementation as we speak. We are counting on this effort to resolve the size issue for all users.

I have a similar use-case where I only need the firebase-sdk for cloud messaging feature/ to send push notifications, I found the SDK overkill especially since im running a serverless AWS Lambda so package size will affect my coldstart & deployment times, so I decided to go with the REST API implementation instead.

Was this page helpful?
0 / 5 - 0 ratings