Discussion: the road to AngularFire v6

[jamesdaniels]

The road to AngularFire v6

Angular 9 is coming soon! Let's kick off discussions on what AngularFire v6 will look like. We've managed to keep the API stable and introduce no (intentional) breaks for over a year! 🎉

Hope everyone has enjoyed this consistency.

Why break at all?

We currently support three Angular (6, 7, and 8) and Firebase majors (5, 6, and 7) with the current version of AngularFire... that's a lot of work.

To support older versions of Firebase we have a number of conditionals and a lot of unneeded code/types.

To maintain support for older versions of Angular, we've been holding back our typescript version and not adopting any new APIs.

Plan of action

Version 5.3:

Release it, WIP here #2187

Version 5.4:

Reimplement @angular/fire/database-deprecated using @angular/fire/database under the hood. It's been raised that database-deprecated has been pretty broken since we've dropped it from our test suite but it is holding back some of our developers from upgrading. We should try to get them on the latest version of 5, before we start breaking things.

Perhaps at this point we'll mark peer support for Angular 9.0 final. So far in my testing the release candidates seem to work fine and we shouldn't need to break a major to support.

Once we've dealt with that:

Version 5.3.1:

Cherry-pick the fixes for the ng add and ng deploy commands.

Version 6:

• Bump the peer dependency to the latest minor of Firebase (currently v7.6)
• Bump the peer dependency of Angular to v9
• Bump the peer dependency of Typescript to bring inline with Angular v9 (currently v3.6)
• Various bugs / types / export naming (see SEMVER comments in the source)
• Change our build process to use ng-packagr WIP Refactor build process #2117
• Drop the angularfire2 shim releases on NPM
• Add the SDK proxy that AngularFireAnalytics and AngularFireRemoteConfig use in the upcoming 5.3 release (Adding AngularFireAnalytics, AngularFireRemoteConfig, and refactoring DI Tokens #2187) to all the modules and drop the instance getters.
• Make all modules side-effect free (no longer importing the SDKs)

Version 6.1:

• "Lazy" versions of all the "non-lazy" modules. These do not assume the developer has loaded any of the Firebase SDKs and will dynamically import them; obviously some APIs will be different.

Version 7:

• Drop the "non-lazy" modules
• Move all our operators, observables, etc. to pure-functions (more on this soon)
• whatever else we think of by then...

Things we're thinking of:

• Reduce the amount of code in this library by leaning on RxFire
• Can we build a migrator for @angular/fire/database-deprecated in a reasonable timespan? If so, I'll drop database-depreciated in version 6, if not we'll punt until version 7. During my investigation I found little evidence that those still using database-depreciated had moved to 5.0 stable; I've decided to drop for 6.0.
• How different would the "lazy" modules actually be? Can we just migrate over to them in 6 rather than have them be optional until 7?
• Require the user import 'firebase/*' themselves before use of the non-lazy modules, this would allow us to export all the packages under @angular/fire and mark them as having no side-effects. ngcc no longer has issue with this
• Shallow up the exports, if we're entirely side-effect free we can export everything in @angular/fire rather than having sub-packages.
• Strong type support in the vanilla Firestore SDK is available now with FirestoreDataConverter. Can we leverage this to get some of our Firestore type work for free in AngularFire & make the guarantees "stronger"? Can we use this for production-worthy state-transfer?

[vikerman]

@mgechev - Maybe add Cloud functions/run support for Angular ssr as part of ng deploy?

[mgechev]

@jamesdaniels, I'll be happy to push SSR support with Cloud functions (at first) as part of the next major release.

Cloud functions seems like a good incremental rollout of a more complete & robust dynamic SSR solution. We're a step away from making deployments with pre-rendering generally available. As the next step, we can re-iterate on the dynamic SSR to optimize for cold start.

WDYT?

[rubenheymans]

looks great! Better documentation on how to use the firebase emulator with angularfire, local database and firestore triggers would be nice too

[jamesdaniels]

@vikerman @mgechev absolutely. In v6 too I'll change the default setup instructions to be ng add @angular/fire. I'm eager for all the Universal 9 improvements.

@rubenheymans great point. I've been meaning to work on those docs also move our tests over to the emulator by default so they're less flaky (and we're dogfooding the emulator integrations).

[Timebutt]

What is the current approach/timeline towards v6? I see there's one big PR here #2282.

What I'm interested in the most right now is the change to ng-packagr for the build, as it's blocking me (and probably others) from building my application using Bazel in Angular 9. I see it the original issue #2117 got closed in favor of #2282, does that mean the work in that branch is close to being done, or it wasn't possible to move to ng-packagr without doing lots of other changes?

Can we contribute in any way right now?
Thanks for your great work!

[jamesdaniels]

Timeline is the rehaul commit going on master in the next day or two, which will mean canary builds on NPM.

Helping test those builds against ng9 would be very helpful, as I’ll probably have too much on my plate to thoroughly dogfood before the first RC.

[jamesdaniels]

FYI I've cut an initial build of version 6 on NPM 6.0.0-next.0

[jamesdaniels]

Version 6 development is now happening on master. I'm writing the changelog entry now and will be cutting the first RC shortly.

[jamesdaniels]

6.0.0-rc.0 is now up on NPM! And we have release notes.

[rubenheymans]

more documentation for multiple tenant apps and angularfire would be nice too. So every user has his own database/storage/auth, and a common project where can manage the tenants

[hiepxanh]

multiple tenant apps @rubenheymans what do you mean?

[rubenheymans]

@hiepxanh https://cloud.google.com/identity-platform/docs/multi-tenancy-quickstart
Create separate databases/storage/... for multiple tenants/clients

[johanchouquet]

@rubenheymans , i saw in the docs that Firebase doesn't manage multi-tenancy.

[puchesjr]

@rubenheymans the identity platform and firebase authentication do support multi-tenancy. However, Firestore does not offer the ability to create multiple databases in the same project. If you want to have multi-tenancy in an application with Firestore you would need to do it with your data model. The recommendation from the Google Cloud Docs has always been to use separate Projects for each client application "Tenant" - https://firebase.google.com/docs/projects/learn-more#multi-tenancy

[jamesdaniels]

AngularFire's DI pattern supports linking to multiple apps, this will be a lot easier in 6.0 now that we're using "providedIn: any" will def write some more docs up on this.

[puchesjr]

@jamesdaniels we store client configurations in a global firestore collection when users are attempting to authenticate they provide the organization name - similar to Slack's workspace sign-in. e.g., acmecorp.slack.com. After retrieving the client config for the identity platform it will load the appropriate firebase configuration for authentication.

[255kb]

Not sur if it's too late or not, but I find the remote config documentation a little bit vague on some points:

• a full example of how to provide settings would be great, the code below is not working even when replacing REMOTE_CONFIG_SETTINGS by SETTINGS imported from the package:

{
  provide: REMOTE_CONFIG_SETTINGS,
  useFactory: () => isDevMode() ? { minimumFetchIntervalMillis: 10_000 } : {}
}

• how does the above config plays with the filterFresh(x) operator? During dev, using the config with a short interval didn't refresh the config, but adding the operator refreshed it immediately.

Note that this is not a support request 😃 . I will solve my problems, but I must admit that documentation could be more detailed, with some examples.

Thank you.

[johanchouquet]

HI everyone!

Just a quick queston here: do we get closer to the v6 for AngularFire ? It'd be so great to be able to upgrade to Angular 9 with all the benefits of Ivy :)!

[rubenheymans]

@rubenheymans the identity platform and firebase authentication do support multi-tenancy. However, Firestore does not offer the ability to create multiple databases in the same project. If you want to have multi-tenancy in an application with Firestore you would need to do it with your data model. The recommendation from the Google Cloud Docs has always been to use separate Projects for each client application "Tenant" - https://firebase.google.com/docs/projects/learn-more#multi-tenancy

Thanks I also found this solution and tried to implement this into my all but it's a bit difficult. I don't know how to programmatically manage all the different projects / customers.

[puchesjr]

@rubenheymans I'm happy to provide you with a few scenarios to consider - each has its own pros and cons.

Scenario 1. Single Project using Firebase Auth Multi-tenancy
In this scenario, you will need to use database security rules/authorization to ensure data is only read by the appropriate tenant. You can do this by either placing a tenantId on a collection doc for example. Or, you could create tenants as a top-level collection with sub-collection under each tenant. In this example, you can store the tenantId in root collection called something like tenantConfigs, when a user comes to authentication you can do something similar to slack and present them with an input field to enter their tenant name and retrieve the tenantId from your tenantConfigs you now use this with firebase.auth().tenantId = tenantId from firestore to authenticate the user.

Scenario 2. Single project per tenant without hosting
In this scenario, you will use Google Cloud Platform api to create a new project and enable the services you need to use, you will also need to use the firebase api to set project details and then you will capture all of the connection details for connecting to the client and persist in a global firestore identified by a tenantId for example, typically your only organization has access to this global firestore and your client-side interacts with it through an api using Cloud Funcs or CloudRun as example. This global store is beneficial as it can be used by you internally to track things like organization details, payment status, organization aggregate data (e.g., total users) etc. The Firebase SDK provides the ability to use multiple firebase projects which you can inject into your application

Scenario 3. Single project per tenant including hosting
In this scenario, you will do everything similar to Scenario 2 - you will use the Google Cloud Platform api to create a new project and enable the service you need to use, you will need to also use the firebase api to set project details and then you will deploy your code - you could use something like Google deployment manager to automate a good amount of this. Once the project is launched you now have the task of keeping multiple projects update anytime you deploy new code / bug fixes, etc. I would reserve this method for large Enterprise or Government as an example.

Here is a Workflow you can use for Scenarios 2 and 3

I hope the information helps.

[rubenheymans]

@puchesjr Thanks! I started with the first solution before, but I did not really like it.

The second solution is perfect for my case, I found this on stackoverflow too, and it's this solution I'm trying to implement.
It would be nice if we could select angularfire in the code examples too:

[johanchouquet]

HI everyone!

Just a quick queston here: do we get closer to the v6 for AngularFire ? It'd be so great to be able to upgrade to Angular 9 with all the benefits of Ivy :)!

Hey there!

Seriously, where are we with the v6 ? It's been more than 1 month since the last commit in the master. @jamesdaniels , is everything ok ? I really hope so and that nothing related to Covid-19 is affecting you or others.
Are there any big issue to continuing the road to v6 ?

[ArtisanvsDev]

I also hope everything is going well @jamesdaniels and hoping for new updates soon. Let us know if there is anything the community can do to help with AngularFire v6.

[hiepxanh]

@jamesdaniels I would like you to authorized me to have right to close issues, there's so many unresolved problem. I can help to clean it.

[jamesdaniels]

Hey all, sorry for the radio silence. My family and I are doing well, there's been some minor symptoms that had us worried, but we all seem to be in good health now. Thanks for your concern! :D Hope all our community members are safe and healthy.

Honestly adjusting to WFH, preparing for ng-conf, and the changes w/re to Google I/O and Cloud Next have ate up a lot of my time lately. Jumping back into Github now & will cut what I hope to be the last RC shortly. Aiming for 6.0 stable next week.

[jamesdaniels]

@hiepxanh I'll discuss with other stakeholders at some point, see if that's something we're open to.

We are aiming to be more diligent with errors, documentation, and Stackoverflow once 6.0 is out the door.

[hiepxanh]

@jamesdaniels I'm glad you're fine. That's so good to know that. Just feeling happy you are safe out there. Be healthy, and let us know anything we can help.
BTW, I just want to help you resolve some issues. Since David East seem to be busy. Hope that everything is fine.

[johanchouquet]

@jamesdaniels , so glad that you're ok and your family too! Working from home is indeed a bit challenging, with this situation from one part, and also when you have kids to deal ^^.

About the lib: great news and excellent planning for the community

[EdricChan03]

Hey @jamesdaniels, I see that you've just landed v6.0 of AngularFire (0be51e6). However, could you detail how to update our apps to use AngularFire v6.0? I see that there are many breaking changes, but no description detailing exactly how to migrate our apps.

For e.g., the changelog mentions that:

AngularFireAuth has dropped the auth property and instead Promise Proxies the underlying Firebase auth.Auth instance; allowing your development experience to more closely mirror the JS SDK. Similar changes have been made to AngularFireFunctions, AngularFireMessaging, and AngularFirePerformance.

However, there's no detailed description of how exactly to migrate functionality related to the service.

(And there aren't any typings for the underlying firebase.auth.Auth class? For e.g. I'd tried accessing the current user via the firebase.auth.Auth.currentUser property, but found out that there was no such property in the typings as per the error below)

Property 'currentUser' does not exist on type 'AngularFireAuth'.

EDIT:

Turns out that the issues were caused by me updating AngularFire while Angular CLI was still serving my app. I solved the issue by terminating the serve process then reissuing the command.

EDIT No. 2:

It seems that the properties in the Firebase JS SDK now return Promise versions of their counterparts.

For e.g. AngularFireAuth.auth.currentUser used to return User | null. However, AngularFireAuth.currentUser now returns Promise<User | null>. Is this intentional?

[jamesdaniels]

@EdricChan03 sorry about that changelog entry being dense & not well explained. I'll make sure to document that better.

Re your edit no. 2, yes that's intentional. Our plan is to lazy-load the Firebase JS SDK while we are waiting for them to become more modular / tree-shakable; hence our "promise proxy". No timeframes but hoping that our work there will begin bearing fruit soon. I will absolutely do a doc push but just had to get this release out the door, don't mind any rough corners & feel free to send any PRs if you have an idea on how to better communicate this!

[curiouscod3]

currentUser returns null.

#2378

[hiepxanh]

Hello, I just experience some buggy or not clearly on the "How Angular Fire work". Specificly:

1. There is some cache problem if you using take(1) with angularfire. It's just not refresh the data.
   snapshotChanges trigger twice #2336
   unexpected: AngularFirestore#collection() returns cached value on initial subscription #2012
2. I just create an issue here explain which have video which explain the problem [Bug or Feature] sometime value not update after refesh, only display cached data, have video record (tested with angularfire 6) #2387
   And then trying to debug and I find out that It return data twice instead of one. If I undestand correctly, so we should take the second If we dont want to get realtime update. For example: if you get the data using take(1) it only return cache value (added data). If you want to get fresh and not want to subscribe on everytime data update. use take(2) to get modifed data.

Don't you mind if you looking into this, sir? @jamesdaniels can you confirm my idea above and help me to explain the idea behind? that could help us update the docs on this angularfire 6 version. And close 3 issues above

[yasinkocak]

Feature request:

i have multiple angular projects (admin/frontend/mobile) and they have separate firebase hosting.
added deploy section on all projects in angular.json but ng deploy do just 1 project. And pick up the first hosting target on firebase.rc does not match.

other requested feature is.

i have 2 firebase instance (development/production). Normally u can switch with firebase use production this does not support.

[BianchiSeb]

Feature request : fix all bugs and make an usable tool

[hiepxanh]

This project only maintain by @jamesdaniels I consider to help him to clear issues and address problem but he doesn't need

[hiepxanh]

I hope we can add this PR to coming release: #2497

[jamesdaniels]

Just cut a preview of 6.0.1 to @canary which should address some issues. Will push out a proper release and write release notes after I do some smoke tests in the AM.

[jamesdaniels]

With the recent release of 6.1 I'm really feeling happy with the 6 series and that despite some rocks in the road (that we've overcome together) it's living up to what I hoped. I'm going to close this issue.

That's not to say 6-series is done. Things I'd like to get done in minors in the coming weeks/months:

• add auto-configuration abilities to those using Hosting
• lazy versions of Storage, Database, and Firestore
• clean up our snapshot action types
• easier APIs for firestore metadata and filtering
• make FCM+NGSW work-arounds official
• server-side Auth
• more schematic work
• accepting contributions from community members like you 🌈 😄

Other than those issues, really just continuing to tighten the API, I don't foresee doing any other major API work until 7.0 (or whatever the next tick release is for us).

On the horizon we have JS SDK vNext which is a modular rewrite of the Firebase JS SDK. I'm still thinking about what this will mean for AngularFire and will start a vNext roadmap once I have enough thoughts together to take community feedback.