Most software integrations are built backwards.
Say a user wants Product A to work with Product B. The usual expectation is that the team behind Product A will build the integration.
This forces Product A’s team to learn how Product B works, anticipate how every user might want the two connected, and write Product B-specific integration code into Product A.
Repeat this for every integration, and Product A accumulates a bloated mess of code for every external product and every workflow its users might need.
This is why modern applications remain more isolated than they should be: every native integration must be designed, built, and maintained by the product team.
Making Product A’s integration system more configurable would only deepen the same problem. The problem can be solved only when Product A’s team is no longer responsible for understanding Product B or encoding the user’s workflow.
The user who owns the workflow should be free to connect Product A to any external product and define exactly how they work together. Because the resulting integration serves one user, it can stay small. It doesn’t need a configuration system general enough to accommodate everyone.
They can provide that integration as a user-specific server.
When Product A needs to synchronize or act, it calls the server. The server applies the user’s workflow, turns the request into calls to Product B, and sends the results back.
Product A gets a native integration without owning Product B-specific code or the user’s workflow.
Each server may connect to a different product and implement a different workflow. But from Product A’s perspective, they must all look like the same server. Otherwise, Product A would again need custom integration code for each one.
Normally, a server defines its API and the client adapts. But these servers are built for Product A. Why should Product A adapt to them?
Instead, Product A can define one server API for every user-specific server to implement — a client-defined server API.
One client, written once, could work for any user.
We wrote the full argument — including where existing approaches fall short and the protocol we’re developing to make this model practical.
The case for client-defined server APIs:
https://t.co/8PbjY5adHy
An update for Nodify Calendar is coming soon.
We’re introducing a refreshed calendar UI and a new warning system that helps you spot scheduling issues and quickly resolve them.
The goal is simple: help you build more realistic plans faster and understand what you can actually get done.
More soon.
We’re launching Nodify Calendar: a local-first calendar with on-device schedule autocomplete.
You define the structure of your week. The scheduler fills it with individual tasks while respecting meetings and manual decisions.
$30 perpetual early-adopter license:
https://t.co/sVk6hitCiG