As a developer, there is one issue that I tend to notice in many codebases: logic coupled with a specific communication layer.
This issue is espec...
For further actions, you may consider blocking this person and/or reporting abuse
Great article!
In my case, I find it very useful to have a second line of public methods.
Imagine something like reacting to an article. I'd have:
react_to_article(user, article, reaction)that does exactly that, provided the user and article exist.http_react_to_article(auth_token, article, reaction)that takes care of token-based authentication before calling the first one.cli_react_to_article(ssh_key, article, reaction)that uses public SSH key as an authentication method.My point is, some things are related to the communications protocol and some others are pure app behavior, and having the latter isolated allows you to:
Those are my 2 cents on this.
I use the same principle, but in the other direction. Instead of avoiding the coupling so that I can build a CLI, I build the CLI so that I cannot couple.
For a desktop app with a GUI, for example, I add a CLI. Both interfaces can work only if the logic is in neither. That keeps me "honest."
That's a good exercise. CLIs and HTTP are different enough that it forces you to "stay abstract".
When you couple HTTP and logic, you're trading off maintainability for easy initial development.
Why would popular frameworks recommend it as a best practice is where I get lost.
I think that is a bad tradeoff for anything beyond a small prototype or a proof of concept.