Composer pulling in 11MBs of unneccesary Google Services libraries

[MichaelPote]

As far as I can see, Firebase-php requires the google/apiclient composer library just so that it can use the authentication routines inside the Google_Client() class. Unfortunately the google/apiclient library insists on requiring the google/apiclient-services library which constitutes over 5000 extra php includes and 11.4 MB of code. It does not seem like this code is ever used.

Unfortunately distributing Firebase-php inside my project with all this extra bloat is just not feasible, so I went into composer's autoload.php files and manually commented out the 5089 Google_Service_* classes from being included in the project and I was able to authenticate with my Firebase project and read and write to my Firebase database just fine.

The only solution I can think of would be to suggest that Firebase-php extract just the Google_Client() class out of the google/apiclient package to drastically reduce the code footprint required to use the library. Any other ideas are welcome?

[jeromegamez]

Hi @MichaelPote and thanks for reaching out!

I see that you are referring to release 1.x of the library. Starting with 2.x, the library only requires google/authwhich reduces the total footprint of the library to currently 2.6MB.

Extracting the Google_Client class is not an option as well, because it has too many references to other classes which have references themselves and so on - maintaining this would be a nightmare :).

I do agree that using the rather big dependency is not optimal, but if the firebase-php library is not the only dependency you have in your project, there are certainly some overlaps. Of course I do understand if this is not an option for you.

I will see what I can do, but unfortunately I can't promise you a change - I should have mentioned in the 1.x branch that this version will only receive bugfix updates (similar to PHP 5.6), and it already doesn't provide all the features that are present in the 2.x branch.

If you'd like to propose a Pull Request to the 1.x branch that reduces the total size, I will definitely have a serious look at it. Unfortunately I can't recommend another Firebase library with a smaller footprint, as I don't know one that provides Service Account based authentication.

[MichaelPote]

Hi @jeromegamez, thanks very much for the reply. I'd love to use the 2.x branch of firebase-php but I'm building a WordPress plugin and I unfortunately cant bank on people being able to run PHP 7.

How much work is it to convert the v1.x branch to also only use the google/auth library? Perhaps it's something I could look at doing a pull request for.

[jeromegamez]

Some background:

I initially included the google/apiclient dependency because the plan was (and still is) to support further Firebase features besides the Realtime Database: Firebase Storage and FCM are just two examples. That's why google/auth might not remain the only Google dependency even in the 2.x release.

Using google/apiclient was the easiest way to add Service Account based authentication to the 1.x branch when 2.x already was the current version, and to be honest, I didn't look at the total size of all dependencies (as a comparison, Symfony Standard needs 50M out of the box, Laravel needs 41M).

But after your issue, I will certainly look more at this in the future.

[jeromegamez]

I will have a look at it this evening and let you know if I can figure something out!

[MichaelPote]

Awesome, thanks @jeromegamez!

[jeromegamez]

After having looked at it, I have realized that I wouldn't be able to release a new version implementing a possible solution 🙁 - here's the thing: the Firebase Configuration Interface defines two public methods getGoogleClient() and hasGoogleClient() - removing them or changing their signature (which would be necessary to remove the google/apiclient dependency) and releasing another 1.x release would break applications that currently rely on those methods.

I honestly don't think that developers implementing the 1.x version are actually using those methods, but the possibility does exist, and removing those methods or changing their signature would violate SemVer and put existing projects at risk.

I'm sorry that I can't help you more - on the bright side, as the 1.x branch will not change considerably in the the future, you should be safe to create a fork and implement the changes to reduce the size there (and become the only PHP 5.x Firebase library with active support 🙂).

I will close the issue now, but want to make clear that this doesn't mean I want to end the conversation here. Please feel welcome to add more comments or to join the #php channel in the Firebase Community Slack, where you will find me and other PHP developers working with Firebase.

[MichaelPote]

@jeromegamez Thanks very much for looking into it. I understand the need to keep the library backward compatible. I'll look into forking it and implementing this and a couple other changes I've made to the codebase. Thanks again!

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.