Skip to content

Commit 38b9bf5

Browse files
authored
docs: add week 5 blog post (#928)
1 parent 504e7f5 commit 38b9bf5

1 file changed

Lines changed: 72 additions & 0 deletions

File tree

Lines changed: 72 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,72 @@
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

Comments
 (0)