Posts

Flutter Web, a Dart gRPC server and Firebase Authentication

Image
OK, not the sexiest title, but here is a quick overview of how you can create a flutter web application (or mobile for that matter, but more on that later), using Firebase authentication , talking to a pure Dart server using gRPC.   The goal here is to: Create a SPA Flutter web application. Leverage Firebase authentication. It's inexpensive (essentially free for most users), and supports a wide variety of social login providers. Support a native Dart Server, using gRPC and protobufs. Proxy from gRPC web to gRPC "native" using envoy. Putting it together, it looks something like this: Why the choice of gRPC here, instead of json/REST?  This comes down to personal preference, but I have always liked the contract first approach of gRPC of defining interfaces using protobufs. In theory, you can do this with OpenAPI - but I've yet to see a moderately complex interface where the generated API stubs look even remotely usable. gRPC does a good job of generating usable client a...

Firebase Authentication with a custom Dart Server

Image
  This post describes my experiments using  Firebase Authentication  with a  Dart  Server application (for example, a  shelf  based web app). The scenario is that you have a client application (a Flutter Web app, for example) that you want to authenticate using Firebase, but the backend is your own custom web application instead of hosted Firebase services. Firebase Authentication is essentially free, and offers social login with all the usual suspects  in addition to username/password and phone number authentication. Why roll your own IAM when you can get it for free? There are examples of this hybrid scenario for other languages where there is a Firebase admin SDK, but I couldn't find detailed notes on how to do this using Dart on the backend. Before we get to the solution (which turns out to be fairly simple), a quick detour into some of the workings of Firebase AuthN. Once Firebase successfully authenticates your client, it issues it an JWT Id...

Notes on Firebase auth for Flutter Web

Flutter Web and Firebase Authentication with Google. Issue "not a valid origin" Notes to self... Despite registering the IntelliJ web server origin in the client OAuth2 settings in the  Cloud Console ,  (for example http://localhost:53006),  sign in with Google produces the error: Error: PlatformException(idpiframe_initialization_failed, Not a valid origin Not sure why the origin did not take in the console,  possibly because of firebase integration with google cloud?  Stackoverflow to the rescue:  https://stackoverflow.com/questions/65132622/firebase-google-signin-localhost-not-whitelisted   This configures Intellij to run the web server on port localhost:5000, which *is* auotmatically registered by firebase as a valid origin for local development.

Introducing ds-operator, the ForgeRock Directory Services Operator for Kubernetes

Image
ForgeRock Directory Services 7.0 was a big achievement for the Grenoble Directory team.  It is the only "Kubernetes native" directory where you can add a new replica using kubectl: kubectl scale sts/ds-idrepo --replicas=3 The 7.0 deployment is assembled using standard Kubernetes primitives such as StatefulSets , Persistent Volume Claims, and Services.  This is all built and orchestrated using Skaffold and Kustomize .  An emerging pattern in the Kubernetes world is the use of Custom Resources and Operators .  Broadly speaking, a custom resource is the declaration of the desired system state, and the operator's job is to observe the current state and bring the system into alignment with the declared state: source: https://blog.container-solutions.com/kubernetes-operators-explained The Kubernetes API server (the thing that responds to your kubectl commands) can be extended to handle new custom types.  A custom resource definition (CRD) describes to the API se...

Hot Take: Dart makes a Great Server Side Language

Image
Google promotes  Dart as a client-optimized language for fast apps on any platform .  This makes a ton of sense. Bootstrapping a language ecosystem is an enormous task that requires laser like focus on where the language adds the most value. Right now, that is  Flutter .  Sometimes, when a language finds success in one domain it can cross over to another.  One can argue that NodeJS  would never be a thing had Javascript not been adopted in the browser.  Can Dart cross over to the server? I think it can.   Recently I created a Cloud Run service to perform smoke tests against another REST service. Golang would be the obvious choice here: Container friendly, small native binaries and a great http library out of the box.   Now Go is a fine language, and this is a purely subjective thing, but I find Dart much more enjoyable and productive to work with.  There are of course fewer server side libraries, but the ecosystem is growing ...

Yes we can: Writing Firestore Admin functions in Dart, and using the Firestore Emulator

Image
Thanks to the awesome Firestore Admin Interop library,  you can write Firestore admin functions in Dart (and yes Googlers, if you are reading this, we *really* need a native Dart Firebase SDK). If you are curious how the interop library works: The dart2js compiler translates your Dart code to Javascript. The interop library wraps the native nodejs library for Firestore,  allowing you to call it from your Dart program. See here for information on the Admin SDK . As a nodejs and Firestore newbie, there were a couple of missing pieces for me on how to use this library: How do I wire this into my Firestore project? How do I use the local Firestore emulator? I won't cover this in depth (please see the example ), but here are few tips: The library is wired to your Firestore project via the service-account.json file that you download from the Firebase console (Project Settings > Service Accounts). Download and save this file (and DO NOT check it in to git !!) Yo...

Deploying the ForgeRock platform on Kubernetes using Skaffold and Kustomize

Image
If you are following along with the  ForgeOps repository, you will see some significant changes in the way we deploy the ForgeRock IAM platform to Kubernetes.  These changes are aimed at dramatically simplifying the workflow to configure, test and deploy ForgeRock Access Manager, Identity Manager, Directory Services and the Identity Gateway. To understand the motivation for the change, let's recap the current deployment approach: The Kubernetes manifests are maintained in one git repository ( forgeops ), while the product configuration is another ( forgeops-init ). At runtime ,  Kubernetes init containers clone the configuration from git and make it  available to the component using a shared volume. The advantage of this approach is that the docker container for a product can be (relatively) stable. Usually it is the configuration that is changing, not the product binary. This approach seemed like a good idea at the time, but in retrospect it cre...