Should meeshkan record have --specs-dir and --mode options?

[fornwall]

meeshkan record --help
Usage: meeshkan record [OPTIONS] COMMAND [ARGS]...

  Record HTTP traffic from a reverse proxy.

Options:
  -p, --port TEXT                Server port.
  -a, --admin-port TEXT          Admin server port.
  -s, --specs-dir TEXT           Directory with OpenAPI specifications.
  -d, --daemon                   Run meeshkan as a daemon.
  -r, --header-routing           Use headers to specify target hosts.
  -l, --log-dir TEXT             API calls logs direcotry
  -m, --mode [GEN|REPLAY|MIXED]  Spec building mode.
  --help                         Show this message and exit.

[aby2s]

If you provide a mode it will create both logs and specs. So you can avoid running meeshkan build explicitly.

[fornwall]

@aby2s Thanks!

[carolstran]

Bringing this issue back to LIFE and changing the heading because I think it's a discussion worth having.

I'd vote to remove any build logic from the record functionality. While I understand the sentiment behind wanting to condense the steps, I think it makes everything a bit more confusing and more difficult to document. Personally, I'm a fan of like one command = one primary functionality.

Curious to hear others thoughts on this, particularly @aby2s because I know you implemented it in the first place. Also tagging @ksaaskil and @mikesol for more voices! 📣

[aby2s]

I don't really like running cli commands though (or because) I work on Ubuntu. And if I were a user (and I could be), an unnecessary additional step would disappoint me a lot.
It's hard to determine actual use cases at this moment to prove the usefulness of this optimization for a majority of users. And I don't know if other people are at least as half as lazy as I am to enjoy this feature, but I would appreciate it if we leave it just for personal usage.
I don't think we have to make strong accents on it in the docs. I think it is better to stick to a default pipeline everywhere. It could worth mentioning in a full reference if we have one. Something like that "This flags allows you to build OpenAPI spec in place during recordings. For details, see somewhere." Or it could be an undocumented feature at all.

[carolstran]

Fair point considering you might be our current power user @aby2s 😆

Also @fornwall and I spoke with @mikesol this morning about what the "selling point" of Meeshkan is. It seems like we want to focus on the mocking aspect, with recording and building being supplements. In that case, being able to skip steps could make sense - plus then we could add (smarter) logging to track how people are building their specs/whether the calls they are making are adding anything new to the schema (or not).

Considering all of the above, I'd maybe propose keeping it - but not focusing on it in the documentation yet. If we really lean into the mocking aspect, then we'll have to restructure the docs anyway - so then that would be a good opportunity to figure out how we want to introduce it.

[ksaaskil]

I can see how it's easier for users if they can avoid running the separate build step, with record taking care of schema building. For me, it just feels a bit awkward to write something like meeshkan record --mode replay 🤔 Here the "mode" is not related to recording (which the command's name says it does) but to the schema building so that's what's confusing me a bit... I'd maybe rather expect to have something like meeshkan mock --mode replay to be able to change the mode as needed... In general, I'm with Carolyn in that I like CLIs that do one easy-to-understand step at a time. In my opinion, if the tool provides value, users don't care if it takes one or two commands. But I could be wrong here, and of course we can keep it for now as it's useful for us!