After Alpha launched in Korea, arcade correction requests began arriving at roughly 20 or more a day. Reading each request and directly changing stored values made the operator's input work grow with demand. With more than 150 arcades, game and region filtering also became increasingly useful.

The September 2 Beta moves from Firebase to PocketBase in response. Before choosing the replacement, we considered how to organize the data and how an admin interface would update it.

Growing requests and data relationships

A form does not remove interpretation work when reports arrive as free text. Operators still need to understand the correction and locate the relevant values. Processing more requests requires improving both entry tools and data organization.

Treating a game series and its versions as one concept, for example, forces repeated matching when searching by series. The existing model did not separate these sufficiently. Conditions used by game and region filters needed corresponding distinctions in storage.

flowchart TD
    accTitle: Two problems behind the migration
    accDescr: Growing requests and search conditions exposed limits in manual updates and the existing model.
    A["More correction requests and arcades"] --> B
    B["Manual updates and model-management burden"] --> C
    C["Reorganize relationships and APIs"]

Original capture of the early input form, showing input units used while organizing the data model. Original Korean screen; Alpha supported Korean only.

PocketBase and the selection criteria

From July, we investigated REST APIs and SQL databases. A REST API provides address-based operations for reading and writing data; a SQL database supports queries over structured information. Building these along with authentication and management tools would expand the migration considerably.

PocketBase combines SQLite with authentication, a REST API and an SDK, a programming tool for using that API. This suited the task of connecting admin editing while reorganizing relationships. We also separated information with different purposes, including series and versions.

flowchart TD
    accTitle: Criteria for choosing PocketBase
    accDescr: Use normalized storage together with authentication REST APIs and an SDK.
    A["Relationships organized on SQLite"] --> B
    B["Authentication REST and SDK"] --> C
    C["Connect admin editing"]

Admin editing and Beta discovery

In August, we moved the Firebase admin form to PocketBase SDK requests. Alpha could already send values to Firebase, but the revised form updates fields according to the reorganized relationships. Authentication serves administrators; this does not introduce general user accounts.

The resulting data supports search, advanced game filters and regional filters by province and city. Selections persist for later visits and Home presentation is adjustable. Reports can be submitted inline alongside the information being viewed instead of requiring another page.

flowchart TD
    accTitle: Beta reads and writes
    accDescr: Users narrow conditions and administrators update through the SDK while review remains necessary.
    A["Search game and region filters"] --> B
    B["Structured correction reports"] --> C
    C["Admin SDK updates"] --> D
    D["Review changes"]

Review and recovery after direct updates

Administrators can update values through the editor, while visitors narrow candidates using conditions. Finding games or regions becomes less dependent on reading each venue's description individually.

There is still no way to undo an incorrect change. Operators must continue checking edits, and authentication sessions can disappear after roughly two days without a visit. Easier updating creates a need for ways to identify what changed and restore appropriate data.

Reference: Musecat engineering notes.