Files
zeekay abf99d05fc papers: reorganize into per-paper dirs, add Antje Worring as co-author
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.
2026-04-18 21:50:07 -07:00

81 lines
3.8 KiB
TeX

\section{Conclusion}
\label{sec:conclusion}
Every Firebase application can become a sovereign capsule application.
The migration is incremental (six phases, each independently deployable),
the performance is superior (local reads are $10\times$--$100\times$
faster than network round-trips), and the result is an application
where users own their data, hold their keys, and can switch providers
at will.
The key contributions of this paper are:
\begin{enumerate}
\item \textbf{Component mapping.} A complete mapping from
Firebase/Supabase primitives to capsule equivalents: Firestore
to encrypted SQLite + CRDT, Firebase Auth to I-Chain DIDs,
Cloud Functions to Base Functions, Firebase Hosting to provider
market.
\item \textbf{Incremental migration.} A six-phase migration guide
that keeps the application functional throughout the transition,
with Firestore serving as a bridge during the intermediate phases.
\item \textbf{Performance evidence.} Benchmarks showing $10\times$
to $400\times$ read latency improvement, sub-millisecond write
latency, full offline capability, and comparable real-time sync
latency.
\item \textbf{Case studies.} Four concrete migrations (notes, CRM,
chat, project management) with effort estimates and key metric
improvements, demonstrating that the Firebase Exit is practical
for real applications.
\end{enumerate}
The Firebase developer experience was a breakthrough. The capsule
developer experience preserves what Firebase got right---real-time sync,
integrated auth, serverless functions, simple deployment---while
eliminating what it got wrong: vendor lock-in, provider-owned data,
no client-side encryption, and no portability. The exit is open.
\begin{thebibliography}{99}
\bibitem{kleppmann2019localfirst}
M.~Kleppmann, A.~Wiggins, P.~van~Hardenberg, and M.~McGranaghan, ``Local-first software: You own your data, in spite of the cloud,'' in \emph{Onward!}, ACM, 2019.
\bibitem{kleppmann2017automerge}
M.~Kleppmann and A.~R.~Beresford, ``A conflict-free replicated JSON datatype,'' \emph{IEEE Transactions on Parallel and Distributed Systems}, vol.~28, no.~10, pp.~2733--2746, 2017.
\bibitem{nicolaescu2015yjs}
P.~Nicolaescu, K.~Jahns, M.~Derntl, and R.~Klamma, ``Yjs: A framework for near real-time P2P shared editing on arbitrary data types,'' in \emph{ECSCW}, Springer, 2015.
\bibitem{josephg2023diamond}
J.~Gentle, ``Diamond Types: A fast CRDT for rich text,'' \emph{GitHub: josephg/diamond-types}, 2023.
\bibitem{shapiro2011crdt}
M.~Shapiro, N.~Pregui\c{c}a, C.~Baquero, and M.~Zawirski, ``Conflict-free replicated data types,'' in \emph{SSS}, Springer, 2011.
\bibitem{zetetic2024sqlcipher}
Zetetic LLC, ``SQLCipher: Full database encryption for SQLite,'' \texttt{https://www.zetetic.net/sqlcipher/}, 2024.
\bibitem{popa2011cryptdb}
R.~A.~Popa, C.~M.~S.~Redfield, N.~Zeldovich, and H.~Balakrishnan, ``CryptDB: Protecting confidentiality with encrypted query processing,'' in \emph{SOSP}, ACM, 2011.
\bibitem{popa2014mylar}
R.~A.~Popa, E.~Stark, J.~Helfer, S.~Valdez, N.~Zeldovich, M.~F.~Kaashoek, and H.~Balakrishnan, ``Building web applications on top of encrypted data using Mylar,'' in \emph{NSDI}, USENIX, 2014.
\bibitem{bernerslee2016solid}
T.~Berners-Lee, ``Solid: A platform for decentralized social applications based on Linked Data,'' \emph{MIT CSAIL Technical Report}, 2016.
\bibitem{kelling2026cloud}
Z.~Kelling, ``The decentralized cloud: Providers as relays, storage, and compute markets,'' \emph{Lux Industries Research}, 2026.
\bibitem{firebase2023pricing}
Google, ``Firebase pricing changes: Firestore read operations,'' \emph{Firebase Blog}, October 2023.
\bibitem{firebase2025deprecation}
Google, ``Firebase Dynamic Links deprecation notice,'' \emph{Firebase Documentation}, 2025.
\end{thebibliography}