|
| 1 | +--- |
| 2 | +title: "GSoC '26 Week 5: Hari - Connecting the Global Planet & Designing Offline Git" |
| 3 | +excerpt: "This week I wired up the Music Blocks Global Planet to all eight backend endpoints, got projects showing up with thumbnails and live search, and finalized the design for the offline Git system I'll start building after the frontend is complete." |
| 4 | +category: "DEVELOPER NEWS" |
| 5 | +date: "2026-06-30" |
| 6 | +slug: "2026-06-30-gsoc-26-harihara-vardhan-week-5" |
| 7 | +author: "@/constants/MarkdownFiles/authors/harihara-vardhan.md" |
| 8 | +description: "GSoC'26 Contributor at SugarLabs working on Git-Based Backend for Music Blocks" |
| 9 | +tags: "gsoc26,sugarlabs,week-5,musicblocks,git-backend,express,sqlite,global-planet,offline,indexeddb" |
| 10 | +image: "assets/Images/GSOC.webp" |
| 11 | +--- |
| 12 | + |
| 13 | +<!-- markdownlint-disable --> |
| 14 | + |
| 15 | +**Project:** [Git-Based Backend for Music Blocks](https://summerofcode.withgoogle.com/programs/2026/projects/JitsF3AX) |
| 16 | +**Organization:** Sugar Labs |
| 17 | +**Reporting Period:** June 24, 2026 to June 30, 2026 |
| 18 | + |
| 19 | +--- |
| 20 | + |
| 21 | +## Introduction |
| 22 | + |
| 23 | +Hey everyone! Week five was mostly about connecting things together. After spending the last few weeks building out backend endpoints and testing them with a debug widget, I finally turned my attention to the actual frontend and wired the Global Planet up to the new backend. By the end of the week, projects show up with thumbnails, search works, forking works, and the full publish flow is up and running. I also put together a proper design for the offline Git feature that I'll build once the frontend work is done. |
| 24 | + |
| 25 | +## Wiring Up the Global Planet |
| 26 | + |
| 27 | +The Global Planet is where students browse and remix each other's projects. It was previously talking to the old Sunjammer backend, and this week I replaced that with the new Express + SQLite + GitHub stack. |
| 28 | + |
| 29 | +Here are all the functions I built and what they connect to: |
| 30 | + |
| 31 | +| Function | What it does | Endpoint | |
| 32 | +| :--- | :--- | :--- | |
| 33 | +| `downloadProjectList()` | Browse with sort, filter, and pagination | `GET /allRepos` | |
| 34 | +| `searchProjects()` | Full-text search via SQLite FTS5 | `GET /search` | |
| 35 | +| `getProjectDetails()` | Single project metadata with IDB cache | `GET /project/:repoName` | |
| 36 | +| `downloadProject()` | Fetch raw project JSON with IDB cache | `GET /getProjectData` | |
| 37 | +| `addProject()` | Create new repo, step 1 of publish | `POST /create` | |
| 38 | +| `publishProject()` | Set `visible=1`, step 2 of publish | `POST /publish` | |
| 39 | +| `editProject()` | Commit updated project to GitHub | `PUT /edit` | |
| 40 | +| `forkProject()` | Fork a project on GitHub | `POST /fork` | |
| 41 | + |
| 42 | +Getting these working took more back-and-forth than I expected. The backend was fine, but the old frontend had a lot of assumptions baked in from the previous API: different field names, different pagination structure, different error responses. Rather than patching the frontend everywhere, I adjusted the Express routes to match what the frontend naturally expected. That felt like the cleaner approach since students interact with the frontend directly. |
| 43 | + |
| 44 | +## What's Actually Working |
| 45 | + |
| 46 | +The planet now loads real data. Projects show up with thumbnails, the sort and filter controls work, and the FTS5-powered search is fast. Forking creates a proper GitHub fork under the right owner. Publishing goes through the two-step flow (create, then mark visible), which keeps half-finished projects off the planet. |
| 47 | + |
| 48 | +I've been testing each function one at a time and going through edge cases: what happens with a project that has no thumbnail, what happens if you try to fork something you've already forked, what happens when the token has expired. Most of these were handled without too much trouble. A few needed fixes on the backend side that I pushed through as I found them. |
| 49 | + |
| 50 | +## Planning the Offline Git System |
| 51 | + |
| 52 | +Last week I described the offline problem. This week I turned it into a concrete plan. I'm not building it yet since that's scheduled for after the frontend work is wrapped up, but the design is done so I won't be figuring it out on the fly later. |
| 53 | + |
| 54 | +The idea is simple: **draft offline, sync when online**. |
| 55 | + |
| 56 | +When a student is offline and hits commit, the save goes into IndexedDB as a local draft. Not a fake Git commit, just a structured record with the project state, a message, and a timestamp. When the connection comes back, a sync process pushes those drafts to GitHub in order and creates real commits. From GitHub's side, the history looks normal. |
| 57 | + |
| 58 | +To keep storage under control: up to 10 pending drafts (around 2 MB) before they get auto-merged, and only the last 3 synced commit metadata entries are cached locally. Older history needs the network. |
| 59 | + |
| 60 | +The main pieces to build are: |
| 61 | + |
| 62 | +- `OfflineCommitManager.js` (new) for all draft save and sync logic |
| 63 | +- `NetworkMonitor.js` (new) to wrap the browser's `online`/`offline` events |
| 64 | +- Updates to `ProjectStorage.js` and `ServerInterface.js` to carry the new fields and offline fallbacks |
| 65 | + |
| 66 | +The plan is written up in full. Building starts once the frontend is in good shape. |
| 67 | + |
| 68 | +## What's Next |
| 69 | + |
| 70 | +Week 6 is finishing the planet-facing frontend and then starting work on the repo creation and commit workflow, the screens a student uses to create a project, write a commit message, and browse their own history. That's the piece that ties the whole backend to something students will actually use. |
| 71 | + |
| 72 | +See you in the next update. |
0 commit comments