July 7th, 2022

I have been writing my first go app at work, which now has pain points in its architecture that make it harder to add new features.

The issue is that I started an app with CLI features that were useful during testing but didn’t make sense when an HTTP rest API was later added and targeted as the primary use case.

Supporting both usages became expensive as testing and new features were burdened by the need to keep functionality consistent across the two APIs.

So I have been thinking, is it worth keeping the CLI?

Future usefulness is objective, as the HTTP side wraps around an existing client app to do its work. If the user wants the functionality of the original app, they can just run the server locally and call with desired configurations.

I will be deleting that code for now but are lessons here:

• Consider the more traditional common, server,cli package structure for these projects.
  • Easier to set up separate testing concerns
  • Easier to add features
  • It adds a bit more complexity to management.
• Consider making future projects funnel “tasks”/“jobs” from either API from the start.
• Use Cobra or Viper from the start.
• Use a solid logging package from the start.