Duplicated Configuration Data Solution

The Problem: Duplicated Configuration Data

I ran into a fundamental architectural problem while building BallBuilder: configuration data was duplicated between the frontend (Swift/iOS) and the backend (AWS).

Consider a simple example: an upgrade costs 100 gems. For that transaction to be secure, the backend must validate the cost—it cannot trust whatever value the client sends. This means the cost has to exist in both places: hardcoded in Swift for the UI, and stored on the backend for validation.

This creates an error-prone system. Every time you change a value, you must update it in two locations. Miss one, and the game breaks.

Observing the Problem in Practice

I noticed this pattern while using Claude to write code. Claude would make a change to a configuration value in the Swift codebase, then we'd update the mocked API call, which also required the same change. Watching this happen repeatedly made it clear: this approach is unsustainable. Two sources of truth for the same data guarantees eventual inconsistency.

The Solution: Single Source of Truth on the Backend

The fix is straightforward in concept: return all configuration data from the backend. The client becomes a consumer of configuration, not a co-owner of it.

This requires a significant refactor. Every hardcoded value in Swift—upgrade costs, energy costs, level rewards, game settings—needs to be replaced with data fetched from the backend.

Implementation: The Profile API Call

Here's the flow:

  1. User launches the app and sees a splash screen
  2. The app authenticates with Apple
  3. We exchange the Apple authentication for a Cognito JWT token
  4. That token is used for the initial API call, which fetches the user profile and level statistics

The profile table is lean—just user data. The bulk of the data (level progress) comes from a separate call. Neither response is paginated. This makes the profile call the ideal location to include game configuration data.

The critical requirement: the user cannot leave the splash screen until this API call completes. This configuration data contains everything—component costs, energy costs, rewards, summon probabilities. If somehow the app proceeded without it, the game would be broken.

Storage: Git-Managed JSON vs. S3

I considered two approaches for storing the configuration:

Option 1: JSON file in the code repository

  • Configuration changes go through the normal deployment pipeline: development → staging → production
  • Integration tests can validate the JSON structure before deployment
  • Git provides commit history for auditing and rollback
  • Changes require a deployment—you cannot modify production configuration on the fly

Option 2: S3 with native versioning

  • Built-in version control
  • Can update configuration in production without a deployment
  • That last point is the problem

The ability to hot-swap configuration in production is a double-edged sword. I could write a script that updates the config file directly in production. While that sounds convenient for emergencies, it bypasses all the controls that prevent mistakes from reaching users.

I chose the Git-managed approach. Changes flow through development and staging, integration tests validate the configuration structure, and I cannot accidentally break production with a hasty script. Git's commit history provides the same rollback capability as S3 versioning, just through a different mechanism.

Validation Strategy

The Swift client will perform strict validation on the configuration data returned from the API. If a required key is missing or malformed, the app will throw an error. This forces configuration problems to surface in development or staging, not production.

Next Steps

I've documented the migration plan in a 1,500-line planning file. The work involves:

  1. Adding the configuration payload to the Profile API response
  2. Creating a configuration manager in Swift that initializes values on login
  3. Systematically replacing every hardcoded value with references to the configuration manager
  4. Adding validation to catch missing or invalid configuration before it causes runtime failures

The result will be a system where configuration lives in exactly one place, changes are deployed through a controlled pipeline, and the frontend simply consumes whatever the backend provides.

Comments

Post a Comment

Popular posts from this blog

Solving Aspect Ratio Problems For Good!!

The Problem: Inconsistent Gameplay Across Devices BallBuilder is a physics puzzle game. Levels contain various components—triangles, rectangles, fans, portals—that players interact with to guide a ball to the goal. Consistency matters. A puzzle that's solvable on one device must be solvable on another, using the same approach. Early in development, I was building on an iPhone. When I used Xcode's device emulator to see how the game looked on an iPad, I was immediately disappointed. The layouts were wrong. Components appeared in different relative positions. The carefully crafted levels didn't translate. This was a fundamental problem that I needed to solve. First Attempt: Percentage-Based Positioning My initial approach used fixed pixel coordinates. This was obviously wrong—devices have different pixel counts, so a component placed at pixel 100 would appear in completely different locations across devices. The first real improvement was switching to percentage-b...
Read more

Designing a Scalable Community Content System

Problem Statement During development of the Ballistics puzzle game, I built a comprehensive level editing toolset for creating physics-based puzzle levels. This toolset enables efficient placement of game objects, configuration of gameplay parameters, and rapid iteration on level design. The natural progression was to democratize this capability—enabling players to create and share their own levels while maintaining quality standards and preventing abuse. The core challenge involved designing a system that would allow user-generated content while addressing several critical constraints: Ensuring published levels meet quality standards (solvability requirement) Preventing statistical inconsistencies when levels are modified post-publication Implementing efficient content discovery with multiple query patterns Mitigating cost concerns through strategic resource gating Pr...
Read more

Customizing the playing experience with special ball effects

Customizing the playing experience My original vision for BallBuilder was strict equality. Players would unlock balls through coins earned by playing, and every ball would be functionally identical—just cosmetic variety. Everyone competes on equal footing. Through discussions with my development partner and general brainstorming, I realized this approach left significant potential on the table. The ball system could offer much more than cosmetic choices. It could become a customization layer that changes how players approach puzzles. The concern with giving some balls mechanical advantages is obvious: pay-to-win dynamics. But I concluded that advantages can exist without breaking competitive integrity, as long as skill remains the primary differentiator. A better ball might make a puzzle easier, but it won't solve it for you. Passive Effects: The Core Concept Each ball in BallBuilder now has a passive effect that activates when equipped. These effects range from subtle ad...
Read more