Lagniappe is a Flask/Jinja application with server-rendered HTML and vanilla JavaScript modules on the frontend. It uses Google Cloud for hosting, storage, auth, tasks, OCR, and optional AI, plus Redis for search, filters, cache, and sync state.
The architecture is intentionally conservative. The tradeoff is fewer frontend framework assumptions in exchange for some cloud-service and operational ones.
Stack
- Backend: Python, Flask, Jinja, Datastore, Cloud Storage, Cloud Tasks.
- Frontend: server-rendered templates, vanilla ES modules, Rollup, Tailwind CSS.
- Editor: TipTap/ProseMirror with Yjs for collaborative document state.
- Search/cache: Redis with search and JSON features.
- Auth/updates: Google Identity Platform and adaptive polling.
- AI/OCR: Vertex AI and Document AI when configured.
Why Server Rendering
Pages have real URLs, links work normally, and the browser is not responsible for deciding what private data exists. The server loads the entity, checks permission, and renders only what the user can see.
JavaScript adds interactivity: widgets, forms, sync, editor behavior, offline queues, uploads, and dynamic table updates. It is not the source of permission truth.
Durability
The app is built to keep working with minimal routine change: ordinary HTML, CSS, JavaScript, Python, and managed cloud services rather than a large single-page-app framework.
Every so often, things outside the app shift — cloud APIs, OAuth rules, cloud APIs, Python runtimes, AI models, security patches, or billing policies. The architecture is meant to make those shifts small chores rather than rewrites.
Data Ownership
Your records live in your Datastore, your files in your Cloud Storage buckets, and AI requests go through your Vertex AI configuration. Lagniappe itself does not have a hosted control plane or licensing server.
That is a real advantage. The other side of it is that you also own the small ongoing housekeeping: backups, account recovery, billing alerts, domain renewal, and making sure someone can pick up administrator duties if needed.
When Something Else May Fit Better
A few situations where a different tool is probably a smoother match:
- You need contractual uptime or vendor support guarantees.
- Occasional cloud-provider setup or billing work is not something you want on your plate.
- You need an app that runs entirely without Google Cloud.
- You want to customize the code without ever maintaining a fork.
- You need formal compliance features beyond what your own cloud controls and procedures cover.