The Serialization Mismatch: When Go's PascalCase Meets JavaScript's camelCase

A Single Diagnostic Message That Uncovered a Cross-Language Data Contract Failure

In distributed systems development, few problems are as insidious as the data that almost works. The backend returns perfectly valid JSON. The frontend receives it. The network layer is flawless. Yet the user stares at a blank screen with the message "No data available." This was exactly the scenario facing the developer building a cluster monitoring dashboard for a horizontally scalable S3 architecture — and the turning point came in a single, deceptively simple message.

The Message in Full

The subject message, message index 725 in the conversation, reads as follows:

[assistant] Now let me look at what the frontend expects for each component:
[read] /home/theuser/gw/integrations/web/ribswebapp/src/components/RequestThroughputChart.js
[read] /home/theuser/gw/integrations/web/ribswebapp/src/components/RecentEventsTimeline.js

At first glance, this appears to be nothing more than a developer reading two frontend source files. But in the context of the debugging session, this message represents a fundamental shift in strategy — moving from assuming the problem was in the backend to verifying the contract between backend and frontend.

The Context: A Dashboard That Refused to Render

To understand why this message matters, we must reconstruct the situation that led to it. The developer had just spent considerable effort implementing a real-time metrics collection system for a distributed S3 storage cluster. The architecture consisted of:

• Kuri storage nodes (backends that store data)
• S3 frontend proxies (stateless gateways that route requests)
• A React-based web UI that displays cluster topology, throughput charts, latency distributions, error rates, and recent events The metrics collector, implemented in rbstor/cluster_metrics.go, was a sophisticated piece of work: it tracked request throughput, latency percentiles (P50, P95, P99), error rates, active requests, and cluster events using a rolling 10-minute window with 10-second sampling intervals. The developer had verified via raw RPC calls using websocat that every endpoint returned real, non-zero data. The RequestThroughput endpoint showed 0.5 writes per second. The LatencyDistribution showed P50 latencies of 13 milliseconds. The ClusterEvents showed node startup events with proper timestamps. Yet the React frontend stubbornly displayed "No throughput data available," "No cluster nodes configured," and "Invalid Date" in the events timeline. The user had attached a screenshot proving the dashboard was essentially blank, alongside raw JSON responses proving the backend was sending data. This is the classic "it works on my machine" problem elevated to a distributed system: the backend and frontend were both correct individually, but they spoke different dialects of JSON.## The Diagnostic Leap: From "Is the Data There?" to "Is the Data in the Right Shape?" The message at index 725 is the moment the developer stopped debugging the backend and started debugging the serialization contract. The preceding messages (721–724) show the developer's initial hypotheses: 1. Message 721: "The frontend is receiving data but... The issue is likely that the frontend is checking for data in a specific format or the data structures don't match what the React components expect." 2. Message 722: The developer reads ClusterTopology.js and sees that the React component destructures topology into proxies, storageNodes, and dataFlows — all camelCase. 3. Message 723: "I see the issue! The frontend uses lowercase field names (proxies, storageNodes), but the Go backend returns PascalCase (Proxies, StorageNodes)." 4. Message 724: The developer confirms by reading the Go interface file (iface_ribs.go) and seeing the struct definitions with PascalCase field names like Proxies, StorageNodes, Timestamps, Total, Reads, Writes. The critical insight in message 724 is the realization that Go's default JSON marshaling uses the exact struct field names — which in Go convention are PascalCase — while the JavaScript frontend, following JavaScript convention, expects camelCase. This is a textbook example of a cross-language serialization impedance mismatch. But message 725 is where the developer takes the next logical step: instead of assuming the pattern holds for all components, they explicitly read the frontend source files for each individual component to verify exactly what field names each one expects. This is the difference between a guess and a diagnosis.

What the Developer Read and Why

The developer read two files in message 725:

1. RequestThroughputChart.js: The developer needed to confirm that the throughput chart component checked for data.timestamps (lowercase) rather than data.Timestamps (PascalCase). The React component's guard clause — if (!data || !data.timestamps || data.timestamps.length === 0) — would fail silently if the backend sent Timestamps with a capital T, because data.timestamps would be undefined, which is falsy, triggering the "No throughput data available" fallback.
2. RecentEventsTimeline.js: Similarly, the developer needed to verify the field names used in the events timeline. The component destructures event objects expecting timestamp, type, nodeId, message, and severity — all camelCase. But the backend was sending Timestamp, Type, NodeID, Message, and Severity. The nodeId vs NodeID mismatch is particularly subtle: Go's struct field was NodeID (an abbreviation), which serializes to "NodeID" in JSON, but JavaScript expected "nodeId". This explains the "Invalid Date" display — the frontend was trying to parse undefined as a date because it was looking for the wrong key.

The Assumptions That Led to the Bug

Several assumptions, reasonable in isolation, combined to create this failure:

Assumption 1: "JSON is JSON." Both Go and JavaScript speak JSON, so the developer assumed the data would flow seamlessly. This ignores the fact that JSON field naming conventions differ between ecosystems. Go's encoding/json package, by default, uses the exact struct field name as the JSON key. The Go community often uses PascalCase for struct fields, but the JSON output is whatever the field name is — there's no automatic camelCase conversion.

Assumption 2: "The frontend was written to match the backend." The React components were presumably written earlier in the project, possibly by a different developer or at a time when the Go interface types were still in flux. The frontend developer chose camelCase (standard JavaScript practice), while the Go developer used PascalCase (standard Go practice). Neither checked the other's work because the RPC layer abstracted away the serialization details.

Assumption 3: "If the RPC returns data, the UI will render it." The developer had verified raw RPC responses and seen valid JSON. The natural conclusion was that the frontend must be broken. But the frontend was working correctly — it was just looking for keys that didn't exist.

Assumption 4: "The pattern is consistent across all types." The developer initially identified the ClusterTopology struct as the problem (message 723), but correctly expanded the investigation to all metric types in message 725. This assumption could have led to a partial fix that only addressed topology while leaving throughput, latency, and events broken.

The Input Knowledge Required

To understand this message, one needs:

1. Go serialization behavior: Knowledge that Go's encoding/json marshals struct field names exactly as written (PascalCase by convention), unless json:"name" tags are explicitly added.
2. JavaScript/React destructuring: Understanding that const { proxies } = topology creates a variable named proxies that matches the JSON key "proxies" — if the key is "Proxies", the variable will be undefined.
3. The project architecture: Awareness that the system has a Go backend serving JSON-RPC and a React frontend consuming it, with no shared type definitions or code generation to enforce consistency.
4. Debugging methodology: The ability to trace a "blank UI" problem through the network layer (RPC responses are valid) to the data layer (field names don't match) rather than assuming the frontend rendering logic is broken.

The Output Knowledge Created

This message produced several valuable insights:

1. A confirmed diagnosis: The frontend wasn't broken; the serialization contract was broken. The fix was to add JSON tags to Go struct fields — e.g., Proxies []ProxyInfo \json:"proxies"\`` — to produce camelCase output.
2. A complete list of affected types: By reading both frontend files, the developer could enumerate every struct that needed JSON tags: ClusterTopology, ProxyInfo, StorageNodeInfo, ThroughputHistory, LatencyDistribution, ClusterEvent, and likely others.
3. A reusable debugging pattern: The method of checking frontend source files to determine expected field names, then comparing them to backend struct definitions, is a general technique for diagnosing cross-language serialization issues.
4. A trigger for broader fixes: The developer would go on to add JSON tags to all interface types in iface_ribs.go and fix type mismatches in cluster_metrics.go where anonymous structs with JSON tags caused compilation errors.

The Thinking Process Revealed

The reasoning visible in this message shows a methodical diagnostic approach:

Step 1 — Observe symptoms: The UI shows "No data available" and "Invalid Date" despite valid RPC responses.

Step 2 — Form hypothesis: The data structures don't match what the React components expect (message 721).

Step 3 — Gather evidence: Read the React component source to see what field names it expects (message 722).

Step 4 — Identify root cause: Go PascalCase vs JavaScript camelCase mismatch (messages 723–724).

Step 5 — Verify completeness: Read all relevant frontend components to ensure no other mismatches exist (message 725).

This is not a developer who jumps to conclusions. When the initial hypothesis (PascalCase vs camelCase) was formed, the developer didn't immediately start editing Go structs. Instead, they took the time to read every frontend component that consumes RPC data, ensuring the fix would be comprehensive. This is the mark of a disciplined engineer who understands that partial fixes in distributed systems often create more confusion than they resolve.

The Broader Lesson: Data Contracts in Polyglot Systems

The issue uncovered in this message is a cautionary tale for any project that spans multiple programming languages. When Go talks to JavaScript, there is no shared type system. The JSON-RPC layer provides transport but no schema enforcement. Each team (or even the same developer at different times) can make different naming choices that are perfectly valid in their own language but incompatible across the boundary.

The solutions are well-known but often overlooked:

• Code generation: Tools like protobuf, gRPC, or OpenAPI generate both Go and TypeScript types from a single schema, ensuring field names match.
• Convention documentation: Explicitly documenting that all JSON field names must be camelCase, and enforcing this with linters or code reviews.
• Integration tests: End-to-end tests that call the RPC and verify the response structure matches what the frontend expects.
• JSON tags from day one: Adding json:"camelCase" tags to all Go struct fields as a matter of policy, even if no frontend exists yet. In this case, the developer chose the pragmatic fix: add JSON tags to all interface types. But the deeper lesson is that serialization contracts deserve the same rigor as API contracts. A mismatch in field naming is functionally equivalent to a missing endpoint — the data might as well not exist.

Conclusion

Message 725 is a small but pivotal moment in a larger debugging session. It represents the transition from "the backend works" to "the system works" — from verifying individual components to verifying the integration between them. The developer's decision to read the frontend source files directly, rather than continuing to tweak backend code, demonstrates a crucial debugging skill: knowing when the problem is not in the component you're looking at, but in the interface between components.

The fix itself — adding JSON tags to Go structs — was straightforward. But the diagnostic journey that led to that fix, captured in this single message, is a masterclass in cross-language debugging. It reminds us that in distributed systems, data doesn't just need to be present — it needs to be understood.