New API Design for LazyDraft

In the last post, I discussed the project I want to rewrite using Rust. In this one, I want to focus on the API and a plan of attack for the project.

New API

The current tool has a very bloated set of commands. The most important feedback I can give myself is that writing the commands and subcommands takes time. One of the main pain points I can address is to reduce the tool’s functionality.

When I think about the simplest workflow I can think of as I am writing this piece is that:

• I create an empty file with a template.
• I usually search Unsplash for a cover photo.
• Set the assetPrefix for the file so that I can link the assets with the actual post.
• Write/Edit as I like.

Thinking of this workflow, I need two operations.

• Seeing the things I want to publish. (list)
• Copying the contents to the actual Website’s folder so that I can see how it looks like on my Website. (stage)

If I make the stage command Idempotent, I will update the latest staged post whenever I re-stage the file. So I can stage it again easily when I edit something in Obsidian.

Apart from this, there might be some changes to the locations of the folders because there is no point in making them hardcoded at this point, even though the tool is for me.

lazydraft list (-l)
lazydraft stage (-s)
lazydraft config (-c)

Running the command itself should also print something meaningful. For this, I will invoke the help functionality under the hood to easily see which actions I can take.

Implementation Path

Before implementing the list and stage commands, the first step is to continue planning and defining the config. What do I need exactly?

• I will certainly need a source folder for posts and assets.
• I keep my writing-related assets in a separate folder in Obsidian, but I use Wikilink format in my Markdown.
• I need a way to keep the name of the YAML property to track the assetPrefix for each post.
• I also need a folder prefix for assets when I convert them to regular Markdown links since they are in a separate folder inside the website’s content folder.

Combining all of the requirements above, the rough shape of the config will look like the below:

{
  "source_dir": "path",
  "source_asset_dir": "path",
  "target_dir": "path",
  "target_asset_dir": "path",
  "target_asset_prefix": "string",
  "yaml_asset_prefix": "string"
}

Take one step back

It is valuable to evaluate a project before diving in and drawing out a rough plan for the development. This thinking process and figuring out the boundaries was a nice exercise. As I mentioned in my last post, documenting these parts of the project is something I’ve meant to do.

The next step will be to build the config parsing and be able to use it in the code because all the functionality will be using that information as parameters.

When I find enough time to finish the config parsing, I will implement the list command. See you then.

---

References:

• Cover Image