[Deep Dive #21] Ecosystem Switchboards - discussion
When integrating third-party services (analytics, auth, payments), we keep ending up with glue code that isn't owned and isn't observable.
Do you build a switchboard layer as a first-class contract (named surfaces, signals), or keep integrations distributed in features? How do you keep external side effects idempotent across remounts and navigation routines? And what signals do you render so the integration story is debuggable without reading the glue code?
Comments (10)
Back to latestDistributed integrations are how you get double-fired analytics and random auth redirects. I'm pro switchboard, but only if it's observable.
We treated integrations like any other contract surface: they need named posture keys and signals.
If a third-party call happens, the UI should be able to prove why it happened.
Related: Tools and Ecosystem and Security and Safety.
Idempotency pattern we used for analytics tied to route intent:
ts
function trackOnce(doc: any, event: string, payload: unknown) {
const key = `tracked:${event}`;
if (doc.read(key)) return;
doc.write(key, true);
analytics.track(event, payload);
doc.write('analyticsSignal:last', { event, status: 'sent' });
}Counterpoint: switchboards can become another monolith that every team depends on.
We limited ours to integration adapters and kept feature-specific glue local, but still required signals for side effects.
That seems right. The switchboard shouldn't own product logic, it should own consistent boundaries.
If it becomes the place to do everything, you're back where you started.
Exactly. Boundary ownership, not feature ownership.
We rendered a simple integration signal in the shell (auth posture, analytics enabled, payment provider). It made support tickets much clearer.
tsx
function SwitchboardSignals({ auth, analytics, payments }: any) {
return (
<div
data-auth={auth.posture}
data-analytics={analytics.enabled ? 'on' : 'off'}
data-payments={payments.provider}
/>
);
}We had a bug where a payment confirmation fired twice after a remount.
The fix was making the switchboard write a stable signal and a sent key in the route doc, then treating it as contract state.
If the integration affects routing (auth redirects), it belongs in the navigation routines layer, not buried inside a component effect.
Signals for integrations aren't about vanity. They're about proving behavior when third-party code is involved and nobody wants to read it.
Switchboard is fine as long as it stays small: adapters, postures, signals. The moment it has business logic, it becomes the new monolith.
If you cannot answer whether an event was sent from a screenshot, you will argue with dashboards forever.