mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
abf99d05fc
Restructured from flat .tex/.pdf files into per-paper subdirectories. Added Antje Worring as co-author on all papers. Synced PDFs to pdfs/ for download site.
59 lines
3.0 KiB
TeX
59 lines
3.0 KiB
TeX
\section{Introduction}
|
|
\label{sec:intro}
|
|
|
|
Firebase changed how developers build applications. Before Firebase, building
|
|
a real-time collaborative app required provisioning servers, configuring
|
|
databases, implementing WebSocket synchronization, building authentication
|
|
flows, and managing deployment infrastructure. Firebase collapsed all of
|
|
this into a single SDK: import the library, initialize with a project ID,
|
|
and start writing application logic. Firestore for data, Firebase Auth for
|
|
identity, Cloud Functions for server-side logic, Firebase Hosting for
|
|
deployment. The developer experience is excellent.
|
|
|
|
The developer experience is excellent because the developer has ceded
|
|
control over every layer of the stack to Google. Firestore data is stored
|
|
on Google's servers, encrypted with Google's keys, accessible through
|
|
Google's APIs. Firebase Auth identities are Google-managed---the developer
|
|
cannot export the authentication state, the password hashes, or the session
|
|
tokens. Cloud Functions execute in Google's runtime, with Google-controlled
|
|
cold start latency, memory limits, and pricing. Firebase Hosting serves
|
|
static assets from Google's CDN with Google-controlled caching, routing,
|
|
and availability.
|
|
|
|
This is the bargain: zero infrastructure complexity in exchange for
|
|
complete infrastructure dependency. The cost becomes apparent when:
|
|
|
|
\begin{enumerate}[label=(\roman*)]
|
|
\item Google changes pricing (as they did with Firestore reads in 2023).
|
|
\item Google deprecates a feature (as they did with Firebase Dynamic Links in 2025).
|
|
\item A regulation requires data residency that Google's infrastructure
|
|
cannot guarantee.
|
|
\item A user requests data deletion and the developer discovers they
|
|
cannot verify that Google actually deleted the data from all replicas.
|
|
\item The application grows beyond Firebase's pricing tiers and
|
|
migration to a cheaper provider requires rewriting the entire data layer.
|
|
\end{enumerate}
|
|
|
|
Supabase, Convex, Neon, and PlanetScale address some of these concerns
|
|
(open-source core, PostgreSQL compatibility, edge deployment) but retain
|
|
the fundamental architecture: the provider holds the data, the provider
|
|
manages the keys, the provider controls the runtime. Switching from
|
|
Firebase to Supabase is a lateral move, not an exit.
|
|
|
|
This paper presents the actual exit: migrating from cloud-dependent
|
|
architectures to local-first cryptographic applications where the user
|
|
owns the data, holds the encryption keys, and can switch providers
|
|
(or run without any provider at all) without losing access to their
|
|
application or its state.
|
|
|
|
Section~\ref{sec:right} acknowledges what Firebase gets right.
|
|
Section~\ref{sec:wrong} identifies what it gets wrong.
|
|
Section~\ref{sec:mapping} defines the component mapping.
|
|
Section~\ref{sec:migration} provides the migration guide.
|
|
Section~\ref{sec:performance} benchmarks performance.
|
|
Section~\ref{sec:offline} analyzes offline-first advantages.
|
|
Section~\ref{sec:cases} presents case studies.
|
|
Section~\ref{sec:related} discusses related work.
|
|
Section~\ref{sec:conclusion} concludes.
|
|
|