A deep dive into refactoring Supabase auth in an Angular SSR/SSG app. Covers application layering (infrastructure, state, domain), provider-agnostic auth design, async guards with CanMatchFn, and why blocking app bootstrap isn't always a bug. Explains how pendingUntilEvent finally makes the native Supabase client work with server-side rendering, and walks through a testing strategy with Playwright's setup

This blog post walks through setting up a local Supabase instance with helpful new npm scripts—like schema:pull, db:seed, and start:local—and integrating Playwright via ng add playwright-ng-schematics to enable robust E2E testing with cookie consent handling. It further enhances test reliability by adding custom helpers and a comprehensive Playwright spec that verifies both UI elements and backend tag data, and shows how to conditionally trigger CI workflows when commit messages include “E2E.”

Just migrated my Angular app from Firestore to Supabase—turned out pretty smooth overall, minus some classic SSR headaches and minor Supabase quirks. Got tables and RLS set up nicely, integrated some NGRX SignalStore action, and even managed environment secrets cleanly with GitHub Actions. Life isn’t always easy, but hey, at least the database looks clean now!

In this chapter, I set up GitHub Actions to deploy my Angular blog to Cloud Run using a JSON key. I ran into a bunch of permission issues, fixed them step by step, and finally got the deployment working. I added unit tests to block bad deploys, and a PR check workflow for better control. It’s now running smoothly, and I’m ready for the next step.

Choosing the right BaaS can make or break your dev workflow—Firebase excels in simplicity and real-time features, Supabase dominates with SQL power and flexibility, while Appwrite offers full control and language diversity. For quick MVPs or mobile-first apps, Firebase is a solid bet; but if you need relational data or plan to scale, Supabase is the smarter long-term play. Appwrite is the dark horse—perfect for self-hosters and teams wanting full-stack customization without vendor lock-in.

In this update, we enhanced Dynamic Dialog with generic types (T), making it more flexible for handling different data types. This allows smoother integration of forms and custom components. We also added image insertion with alt text in Quill, improving SEO and accessibility. To boost performance, we optimized syntax highlighting, targeting only HTML, XML, and TypeScript blocks. Finally, we fixed Firebase document size issues and improved Quill’s image handling, ensuring a smoother editing experience. Stay tuned for Part 4, where a major app refactor is coming! 🚀

In Part 3, we focus on admin features, editor improvements, and unsaved data protection. We switched from p-editor to Quill, overcoming issues with highlight.js and server-side rendering. Now, syntax highlighting works smoothly. To prevent data loss, we added a before-unload warning and a CanDeactivate guard, prompting users before leaving unsaved work. A new "Save as Draft" feature lets posts be stored without publishing. Editing posts is now seamless with automatic form population when modifying an existing post. We also fixed heading styles in Tailwind and formatted dates properly from Firebase timestamps. Finally, we extended Quill to support TypeScript syntax highlighting. Another step toward making this blog app powerful and efficient! 🚀 Stay tuned for more!

In Chapter 2, we refine the project, fix issues, and add new features. We updated Angular to 18.0.6, resolving issues with withEventReplay(). The Admin role is now properly initialized using APP_INITIALIZER. We restructured PostCardComponent into a fully reusable UI component with named slots. A new Role Directive allows flexible user permissions beyond just Admin. For SSG, we implemented auto-generated routes using Firebase functions, though Angular 18.1 will soon handle this natively. We also introduced a GDPR cookie consent popup, storing settings in LocalStorage for now. This chapter was a mix of problem-solving, learning, and fun. Stay tuned for Part 3—more optimizations ahead! 🚀

Let's get started with this Angular app! In the first chapter, we'll create a new project, configure Firebase, and set everything up. The project will be built using Angular 18+ with SSG (Static Site Generation). For hosting, we'll use Firebase's new App Hosting, specifically designed for SSG Angular apps. Our goal is to create an app that will break records on Lighthouse-type benchmarks!