Building the Foundation for Git and Scan Sync in API Dash (GSoC 2026)

Shashwat Pratap Singh — Mon, 20 Jul 2026 19:25:06 +0000

Git was not the most difficult part of my Google Summer of Code project.

The greater challenge was recognizing that our storage layer could not support the collaboration experience we intended to deliver.

Git, Scan Sync, and live filesystem updates all followed from addressing that foundation first.

Where I started

I'm a Google Summer of Code 2026 contributor with API Dash, working on Git Support, UI Workflow Builder & Collection Dashboard.

The midterm objective was not a single feature. It was a shared architectural spine:

Make collections real, shareable workspaces so desktop teams can use Git, and your phone can stay in the loop without fighting the stack.

In practice, that meant one folder on disk that desktop Git, phone Sync, and the UI could all treat as the same source of truth.

The problem

API Dash previously persisted data in Hive. That approach worked for a single machine, but the data was binary and neither human-readable nor suitable for Git. Introducing a conversion layer on top would have created two sources of truth and ongoing translation overhead.

In discussion with mentors, we chose a clearer path: own a filesystem workspace instead. See PR #1695 (storage migration).

A workspace is simply a folder: collections, environments, and workflows as readable JSON. Secrets stay in secure storage on the device, not in those files , so sharing a workspace does not accidentally share keys.

Why JSON?

Flutter and API Dash were already oriented around this model. Domain models already exposed toJson / fromJson. The architecture already used maps and JSON for requests, imports, and code generation. Writing that same shape to disk was not a new serialization dialect; it was aligning persistence with what the application already trusted.

The approach was fast to implement, straightforward to diff, and easy for users to inspect. It avoided maintaining a parallel serialization path.

That decision unlocked the rest: Git for desktop team collaboration, Scan Sync for laptop and phone, and disk-to-UI synchronization so folder changes appear in the application - all on the same workspace.

A workspace you can actually open and understand.

Git vs Scan Sync

Git for teams (desktop)

Desktop Git is the natural collaboration path: system Git, OS credentials, clone / commit / push / pull, and Visual/Raw diffs in a Collaboration tab. See PR #1734 (scan sync / collaboration).

The workspace folder is the repo. History and local-only files stay out of Git by design; what you review and push is the same JSON you can open in Finder.

Review before you push or pull. Same diff language everywhere.

Scan Sync for your phone

Full Git on mobile appeared consistent in theory and awkward in practice authentication, SSH, and conflict resolution on a small screen for a job that is usually simply "get this workspace onto my phone."

We therefore built Scan Sync: same Wi‑Fi, QR pairing, a device-to-device link, the same review diffs as Git, then Apply. Under the hood, file hashes (SHA) keep a shared baseline so later syncs can show only what changed—Send or Receive without copying the whole workspace every time.

Git: collaborate with a team over a remote
Scan Sync: move your workspace between your devices, quickly

Same files. Right tool for each side.

Scan Sync: pair on the same Wi‑Fi, review, Apply.

Watching the filesystem

A filesystem-first design only works if the interface remains accurate. We added an event tracker on disk so the desktop app notices when a collection or request is added or removed outside the UI; the catalog updates accordingly. The application's own writes are filtered out so autosave does not conflict with the watcher.

Whether the change comes from Git pull, Scan Sync Apply, or an edit in Finder, the expectation is the same: the UI matches the folder.

Delete on disk. The UI follows.

What I learned

Do not paper over the foundation. A Hive-to-file bridge would have deferred the real design. Mentors advocated filesystem-first. That was the unlock.
Use what the architecture already provides. JSON was not a fashion choice. toJson / fromJson was already familiar ground for Flutter and API Dash.
The filesystem must be usable for humans, not only correct for Git. Folders and names should make sense in Finder so users always know what they are looking at and where their data lives. If they cannot tell what a file is, the workspace is incomplete.
One truth, several doors. Storage, Git, Scan Sync, and disk-to-UI are connected by design, not bolted on separately.
Match the tool to the job. Git where teams collaborate. Scan Sync where phone speed matters.
Reuse the review path. One Visual/Raw mental model for pull and for phone Apply.

What's next

Land the pull requests, then Workflow Builder and Dashboard on a workspace we can trust.

Looking back

In retrospect, Git was not really the project.

The project was building a workspace architecture that Git, Scan Sync, and future features could all rely on.

Along the way, my priorities also shifted. I previously optimized primarily for clean, maintainable code. That still matters. I now place greater weight on user experience: Can someone open the folder and understand what they are looking at? Can they sync to their phone without fighting the application? Does the UI remain accurate when the disk changes?

Maintainable code is how you get there. Usability is why it matters.

DEV Community: Shashwat Pratap Singh