An app's content has a home. Often that home is ours: articles, events, podcasts, photos written and managed in the GoodBarber back office. But a lot of content already lives somewhere else — a WordPress a team has run for years, a YouTube channel, a podcast host, a shared calendar. Nobody re-types content they already maintain.
So an app has to eat from other people's kitchens. The engineering question is what language dinner arrives in.
Standards are dialects
Take calendars. iCal has been a standard since the late nineties — our oldest test file for it is dated 2002 — and in theory every emitter on earth speaks it. In practice, every emitter speaks its own accent of it: fields that shouldn't be empty but are, recurrence rules stretched past what the spec imagined, encodings from another era, dates that contradict each other inside a single event.
Our calendar connector is full of exceptions, and we don't apologize for a single one. Each exception is a real customer's real calendar — one that a spec-perfect parser would have politely refused. A connector that only accepts the standard as written connects you to nobody.
WordPress taught us the outer limit of that patience. What lives behind that name is so heterogeneous — versions, themes, plugins, half-disabled APIs — that reading from the outside eventually wasn't enough: we ended up shipping our own plugin on the WordPress side, so that at least one end of the conversation would be predictable. Even with our code at both ends, it's still delicate. When reading fails, equip the writer.
One language on arrival
Whatever the source speaks, everything lands in the same internal shape. An event from a hand-written iCal feed, an event from Google Calendar and an event created in our CMS become the same kind of object — same fields, same rules, served to the app through the same operations: fetch an item, list the categories, search. The app never learns where its content was born.
That's the actual job of a connector. Fetching is plumbing; the work is translation — from whatever dialect the source speaks into the same internal grammar everything else in the platform already reads.
Translate once, everything works
The dividend shows up everywhere downstream. A new article lands in an imported feed: the automatic push can notify subscribers, because to the push system it's just a new article. Search indexes it. The app renders it natively, with the app's design, not as a foreign web page in a frame. For compatible content, the chatbot grounds its answers in it, the same way it grounds them in content written in our own CMS.
None of these features contains a line of code about WordPress or iCal. They read the internal language, and the connector already did the translating. Import badly — pass the source's quirks through — and every one of those features inherits the quirks. Translate once, properly, at the border, and everything behind the border stays simple.
Connectors die. Content doesn't.
Deep in our oldest code sits a directory of connectors for platforms that no longer exist. Google+. Picasa. MySpace. Each was worth a connector once; each is a tombstone now. That's the quiet lifecycle rule of this whole domain: a connector dies when the far side dies. You can maintain your half of a conversation forever — if the other half hangs up, the wire goes silent anyway.
The apps those connectors fed didn't die with them. Their content had already crossed the border, translated into a shape that doesn't belong to any platform. When a source disappears, you lose a pipe, not a library.
Which is the real answer to the question we started with. The durable part of an import was never the pipe — pipes rust, sources vanish, standards drift into dialects. The durable part is the language things arrive in. That one, we get to keep.
Top comments (0)