Interfaces between systems that don’t know each other
Two programs that need the same data and know nothing about each other. In most organisations that is the actual job.
How I work
The format is rarely the problem. The hard parts are the cases the specification says nothing about: the other side answers twice, the order arrives twice, the network drops halfway through a sync. So I build interfaces where a second call breaks nothing and where you can read back afterwards what actually happened.
In DualStream, three completely different video players sit behind one shared interface, and dropped connections pick themselves back up. Connecting a legacy application to a new portal needs the same thinking: a facade that keeps the other side’s quirks where they belong.
Typical jobs
-
01
Providing a REST API other departments can actually use
-
02
Connecting a legacy system to a new portal without touching it
-
03
A nightly data sync between two databases
-
04
Import and export for CSV, XML or a list out of Excel
-
05
Webhooks and notifications that still arrive after an outage
With what
REST and OpenAPI, JSON and XML, SOAP if the other side insists, message queues, scheduled jobs, SFTP, webhooks
Where you can check this
The workshop has DualStream: one adapter for three player types, where the audio and layout logic never learns which source is playing. Built on broadcast day, in use that evening.
MoreOften goes with this
All servicesWhether it’s a specific project or just a question for now, write it down the way you’d tell a colleague. You’ll get a reply from me, not from a mailbox.