Pushing In and Pulling Out

I decided to build an Obsidian plugin.

Obsidian is a knowledge-management app. A significant portion of people who use YouTube for learning manage their notes in Obsidian. If StackTube's analysis results could automatically flow into Obsidian, it would be a powerful connection point for those people.

But here's what was strange.

StackTube already had an Obsidian output feature. When analysis finished, it placed a markdown file in the Obsidian folder. It had existed since the beginning. So why build a plugin too?

I posed this question to the control tower. Why a plugin when the feature already exists?

The answer that came back was interesting. "Because the direction is reversed."

I understood only after hearing the explanation.

The existing Obsidian output feature had the server write files directly into the user's Obsidian folder. Enter a folder path in the settings, and the server saves markdown to that path. The server pushes files into the folder.

This worked perfectly in the V2 era—when the program ran on my own computer. The server was my computer. Of course my computer can write files to my own folder.

But things changed when it became a SaaS. Now the server sits on the cloud. Not my computer. And a server in the cloud cannot touch a folder on a user's computer. Naturally. If any server could write files to my computer's folders, that would be a serious security problem.

So the "server pushes into the user's folder" approach was fundamentally impossible in SaaS. The existing feature worked locally but was blocked in the cloud.

Here, the direction had to be reversed.

If the server can't push into the folder, then pull from the folder's side toward the server. A plugin running inside the user's Obsidian connects to StackTube's server API and fetches the analysis results. The server doesn't know the user's computer, but the plugin inside the user's computer can know the server's address.

From pushing in to pulling out. From push to pull.

The difference in direction seemed trivial at first. Either way, a markdown file ends up in the Obsidian folder—the result is the same. But even with the same result, the structure was completely different.

In the push structure, the server is active. The server decides "when and where" to write files. In the pull structure, the plugin is active. The plugin decides "when and what" to fetch. The server merely plays the role of "keeping it open so things can be taken."

This realization brought EP.02 to mind. Back then, expanding V2 into a SaaS surfaced six structural flaws. Problems that were fine solo but broke with multiple users. This push/pull problem was exactly that lineage. Works locally, blocked when hosted.

But this time was different. In EP.02, the control tower pointed out the problem. This time, I was the one who first asked, "Why do I need a plugin when the feature already exists?" I didn't ask because I didn't know the answer—a sense that something was off came first. My sense for reading structure had grown a little. In EP.06 I learned "the language for reading structure," and now I could form my own questions in that language.

The plugin's actual structure was simple. On the server side, I just needed to add one API window. A window that receives the request "return new analysis results after this timestamp as markdown." The work of creating markdown (the core of the value) is already done by the server, so I just needed to keep it open.

The plugin side was a thin courier. Fetch new notes from the API, tidy up the filenames, save them to the Obsidian folder. Filter duplicates by video ID. Check automatically every 30 minutes, or manually press "fetch now."

The key was separating "the part that creates value" from "the part that transports it." The server creates the value of analysis; the plugin carries it. Each does only what it's good at.

Once I understood this separation, I realized I could use the same principle when integrating with other tools in the future. Notion or any other app—the principle "if the server can't push, the client pulls." Decide the direction data flows first, then build the structure.

Deciding direction comes before building. If the direction is wrong, no matter how well you build, it won't work. This isn't a code problem but a design problem, and design is a domain someone who can't read code can judge—or perhaps judge even better precisely because they can't.

If you can't push in, pull out. It took quite a detour to learn one simple principle.

And so the plugin's structure was set. But building it and releasing it were, again, separate problems. To get people to use this plugin, I'd have to open a shop in someone else's village called Obsidian. That's the next story.

---

🔧 Technical Terms in This Episode

Push vs Pull Two directions for exchanging data. Push is the sender actively pushing it out. Pull is the receiver actively pulling it in. Even for the same data movement, who leads differs, and that difference determines system structure.

API Window (Endpoint) An address through which external parties can request data. When the plugin sends a request to this address, the server returns the relevant data. In this episode, I opened one new window that "returns new notes as markdown."

Client The side that sends requests to a server. Here, the plugin running inside Obsidian is the client. A "thin client" is a lightweight program that leaves complex processing to the server and handles only minimal transport itself.

Polling A method where the client repeatedly asks the server "anything new?" at fixed intervals. The plugin checking the server every 30 minutes is polling. The opposite of the server notifying first (push).

Separation of Concerns A design principle where different roles are handled by different parts. The server handles "value creation," the plugin handles only "transport." When each does just one job, the whole becomes simpler and sturdier.