Future idea: Optional server-based mode (offline-first with optional sync & multi-device support)

[MarcinSachs]

Hi everyone 👋
I’d like to start a discussion around a possible future direction for Beanconqueror and get some thoughts from maintainers and the community.

This is not a proposal to change the current architecture, but rather an exploration of an optional extension that could coexist with the existing offline-first design.

💡 Background / motivation

Beanconqueror works extremely well as a standalone, offline-first app, and that should absolutely remain its core strength.

At the same time, some recurring feature ideas and use cases (e.g. richer metadata for brews, sharing data across devices, long-term aggregation or analytics) naturally raise the question of whether an optional server layer could help in the future — without breaking or replacing the current workflow.

🧠 The idea (high level)

• Keep Beanconqueror offline-first by default
• Local storage (IndexedDB / SQLite) remains the primary source of truth
• A backend/server is entirely optional
• When enabled, the app could act as a client, synchronizing data with a central server
• This would allow:
  • multi-device usage
  • shared datasets (e.g. household setups)
  • server-side aggregation or analytics

In short:
one app, two modes — standalone or client–server, chosen by the user

🏗️ Conceptual outline

• No separate “server version” of the frontend
• Same app, same UI
• Server mode only adds:
• optional sync
• central storage
• Offline mode remains untouched

This keeps complexity away from users who don’t need these features.

🔬 Related experiment

I’ve started a small, separate experimental project to explore this idea:

👉 https://github.com/MarcinSachs/beanconqueror-server

Right now it’s only a very simple HTTP server that serves the existing Beanconqueror frontend.
The long-term goal is to experiment with optional synchronization and central storage, while keeping the offline-first behavior intact.

This is not a fork and not intended to replace anything — just a sandbox to test ideas.

🤔 Why I think this might be worth discussing

• preserves the current offline-first philosophy
• avoids maintaining two different apps
• enables optional multi-device workflows
• allows future features without forcing them into the core app
• can remain completely opt-in

❓Open questions for discussion

• Does this align with the long-term vision of Beanconqueror?
• Would such functionality be better suited as a community-driven extension rather than part of the core project?
• Are there architectural or philosophical concerns I might be missing?

I’m very open to feedback — including reasons why this might not be a good fit.
The main goal here is to start a thoughtful discussion, not to push a specific solution.

Thanks for reading 🙏

[graphefruit]

Hello @MarcinSachs,

first of all, thank you for the initiative and the very thoughtful write‑up – and a wonderful New Year to you as well!

Long‑term vision
To your first question, “Does this align with the long‑term vision of Beanconqueror?”

Yes, it definitely aligns with the long‑term vision.
The dream has always been to keep Beanconqueror offline‑first, but to eventually offer an optional online solution: multi‑device sync (iOS, Android, maybe Web), easier backups, and space for more “social” or sharing‑oriented features.
​
Core vs extension
For “Would such functionality be better suited as a community‑driven extension rather than part of the core project?”

There are two perspectives here:

• On the one hand, contribution levels to BeanConqueror are currently not very high (since 7 years), and many contributors only appear once for a single PR. Designing a fully community‑run sync backend around that reality would be risky for long‑term maintenance.
  ​
• On the other hand, an official BeanConqueror‑run instance with the option for self‑hosted instances feels like the more sustainable direction: a clearly defined reference implementation, and then community‑maintained extensions or alternative backends on top.
  ​

So the way it looks from today’s standpoint:

• The sync/server part should live as a core project (governance, copyright, and long‑term direction stay with BeanConqueror).
  -> Reference to top: Social features / Sharing, etc.

• It can absolutely be extended by the community (extra adapters, tooling, deployment recipes, etc.), and self‑hosting should remain possible for users who prefer that.

Money and sustainability
Since you explicitly touched on this:

Running a central BeanConqueror instance with user accounts, storage for databases, images, and shot profiles, plus monitoring, backups, and support is ongoing work and real cost (servers, storage, domains, legal/compliance overhead, etc.).
​
To keep the app free and ad‑free, a hosted “BQ‑Instance” would almost certainly need to be paid (e.g. subscription or contribution‑based) so that infrastructure and long‑term maintenance are covered and the product remains sustainable next to a full‑time job.
​

Self‑hosted instances would of course be under the control and responsibility of their operators.
For the “official” instance, the idea would be:

-> Clear terms around copyright (+code) and branding, so the “BeanConqueror” name and core components remain protected while still being open source where feasible, anyway there will be a point of having things open or closed - But thats a far vision right now.

Regarding “Are there architectural or philosophical concerns I might be missing?”, a few important ones:

• It is not only about database sync; file sync is equally important (images, brew graphs, etc.).

• The offline‑first nature of BeanConqueror must not be broken: the app should work fully without a server, and sync should be an optional layer on top, not a requirement.

• Conflict resolution, versioning, and migration across platforms will need careful design so that users do not lose data or get confused when devices diverge.

Thought:
Maybe also a reference like Visualizer is doing it?

If something is unclear, please feel free to ask, else I'm happy for a further discussion here, or also via Discord or a direct call.
Thank you again for the initiative, all the thoughts to this, and also the willing/invest into this topic!

Have a great cup of coffee
Lars

[MarcinSachs]

Hi Lars,

thank you very much for the detailed and thoughtful response — and happy New Year to you as well ☕

I’m really glad to hear that the idea of an optional server / sync layer aligns with the long-term vision of BeanConqueror, especially with the strong emphasis on keeping it offline-first.

Your point about core vs extension makes a lot of sense. A clearly defined, official reference implementation (with governance staying within the BeanConqueror project), combined with optional self-hosted instances and community tooling around it, feels like a very healthy and sustainable model.

I also fully agree that sync is more than “just database rows” — handling files (images, graphs), migrations, and conflict resolution will be the real hard parts, and those need careful, conservative design to avoid data loss or user confusion.

Regarding Visualizer: I see it as a great complementary project. As far as I understand, it focuses mainly on visualization and analysis of existing data, whereas a sync/server component would act as a stateful backend for the app itself (ownership of data, multi-device consistency, backups). I think both approaches could coexist nicely in the ecosystem.

For my part, I’m happy to keep experimenting on the technical side (e.g. offline-first sync models, data contracts, server architecture) and share findings or prototypes if that’s useful — without assuming that anything should immediately become “official”.

I’d be very happy to continue the discussion here, on Discord, or in a more technical format if that helps.

Thanks again for the openness and encouragement — and for building such a great app.