Better UX for DNS
Opened this issue · 14 comments
How about we allow 2 formats? The current one and the dig format.
Current
globalping dns google.com --resolver 9.9.9.9 --type A --trace --protocol tcp
Dig format
globalping dns google.com @9.9.9.9 A +trace +tcp
This means the user doesnt have to learn a new format and just use the dig that everyone is used to.
That's fairly brittle since we already support a non-standard from format. I think it unnecessarily adds too big of a surface area for bugs and edge cases. It breaks away from a lot of modern CLI flag conventions too.
Cant we just limit this logic to dns? It wouldn't affect any other command. I just think that the UX benefit from this would be really worth it and make switching to our tool a lot easier. It literally becomes a drop-in replacement of dig
dns google.com from belgium+google @9.9.9.9 +tcp +trace --latency --resolver 1.1.1.1
Even though this command is unlikely to be used, there are so many edge cases to account in arg and flag parsing that the complexity would exceed the code written for the CLI already.
For example, I cannot differentiate between +trace and +tcp automatically and know where it goes in the POST request to the API. I'd need to read the dig spec and hardcode every flag to know where it goes.
Or having two flag parsing systems. Which one takes precedence in resolver here? Etc.
Perhaps more shorthand flag usage would be an acceptable compromise?
The --resolver part is not needed because thats the @9.9.9.9 part.
So it would be something like this
dns google.com @9.9.9.9 +tcp +trace --latency from belgium+google
You can hardcode "+trace and +tcp" and look them as is without parsing every single + parameter. These are the only 2 flags, so no need to go through the whole spec.
Perhaps more shorthand flag usage would be an acceptable compromise?
Got an example?
The --resolver part is not needed because thats the @9.9.9.9 part.
We still have to account for weird combinations like that.
dns google.com @9.9.9.9 +tcp +trace --latency from belgium+google
You can hardcode "+trace and +tcp" and look them as is without parsing every single + parameter. These are the only 2 flags, so no need to go through the whole spec.
That makes sense. Although I think it hugely defeats the purpose of making the command simpler to use if we are mixing dig flags, usual CLI flags and from args in one command like that example.
Got an example?
globalping dns google.com --resolver 9.9.9.9 --type A --trace --protocol tcp could be shortened to:
globalping dns google.com -R 9.9.9.9 -X A -P tcp -T
Admittedly, it isn't super pretty. But I still feel a little on the fence about introducing a completely different format since it feels like unnecessary complexity both on the user and codebase.
That makes sense. Although I think it hugely defeats the purpose of making the command simpler to use if we are mixing dig flags, usual CLI flags and from args in one command like that example.
We're inventing a new format basically, as simple as it is it will never be simpler than what the user already knows. I think dig has the most unique format that most people are used to.
The examples are just shorter, but they do nothing to help with the experience. My point is not that the current format is too long, but that it would be a lot easier for someone to start using us if we supported a familiar format.
But I still feel a little on the fence about introducing a completely different format since it feels like unnecessary complexity both on the user and codebase.
How complex it would be? From my point of view it's basically a few hardcoded aliases.
@9.9.9.9 == --resolver 9.9.9.9 meaning if one is set the other would be a duplicate.
The examples are just shorter, but they do nothing to help with the experience. My point is not that the current format is too long, but that it would be a lot easier for someone to start using us if we supported a familiar format.
I disagree since giving users more options to achieve the same results makes things less simple. It's more complex because the user has to understand there are two ways to do the same thing. You'll have to write extra documentation for the quirk. If they want to use any of the other GP commands, they will have already learnt the regular format.
I feel we should get more opinions on this to see if maybe my perspective is wrong here. If we implement this, it won't be very easy to revert once this tool is more popular.
Will also add the shorthand flags for those who do want the convenience of typing less.
How complex it would be?
Now that I think about it more, yeah resolver and the two flags should be simple. As for choosing the DNS type, if we enforce an order such as dns google.com cname from world, it's doable.
I see the benefit here but have two concerns:
- We don't support most of the dig options. If users see the input supports dig format, they are likely to incorrectly assume all options are supported.
- Similar arguments could be made for supporting ping/mtr/curl options. If we were to do this, it should be for all tools and as a first step, an exact list of all mappings should be discussed.
It's more complex because the user has to understand there are two ways to do the same thing. You'll have to write extra documentation for the quirk. If they want to use any of the other GP commands, they will have already learnt the regular format.
It should be as simple as this I think.
Performs DNS lookups and displays the answers that are returned from the name server(s) that were queried.
The default nameserver depends on the probe and is defined by the user's local settings or DHCP.
Has limited support for dig's format: "@resolver, +tcp, +trace".
Examples:
# Resolve google.com from 2 probes in California
dns google.com --from California --limit 2 --resolver 1.1.1.1 --trace`,
# Same command in dig format
dns google.com @1.1.1.1 +trace --from California --limit 2`,
I see the benefit here but have two concerns:
- Maybe, but after checking the command's manual they will realize only the basic (and most used) stuff is supported
- I would not be opposed to that. But our current format is already pretty close to those tools. dig is the most unique and most popular so I wanted to start with it.
As a compromise we could also globally replace --resolver 1.1.1.1 with @1.1.1.1. That parameter is the most used dig parameter anyway.
@jimaek a few comments:
- Is supporting the
<hostname> from <locations>format necessary in the CLI ? I find it confusing given there is already a--fromflag. Removing support for this would probably simplify adding more advanced per-command formats in the future, like the one proposed here for dns. - Regarding the dig suggestion we can support something like
dns google.com @9.9.9.9 A +trace +tcpas long as the supported dig parameters list is well defined. - If we start supporting more advanced per-command formats, in order to avoid errors and simplify the parsing, I would suggest requiring the "query" (ie that text field we're currently using for the target) to be quoted when it contains more than a single word/contains spaces, for example
dns "google.com @9.9.9.9 A +trace +tcp" --from California --limit 2. This way it's a bit clearer where the command specific query is and where the rest of our cli flags are.
- I think its the cleanest option, especially since we use it in the Slack app and we advertise it as human friendly.
- Good, we only have few options we need to support.
- The UX would be pretty bad then. I want to build a super simple tool that anyone can use intuitively.
I think its the cleanest option, especially since we use it in the Slack app and we advertise it as human friendly.
It's a weird format no other CLI uses, hardly human friendly. Chatbots and command line tools are entirely different categories, and trying to match their format is just confusing. That said, I'm not much in favor of adding the dig format, either - it would add confusion over time as well.
Lets start by adding an alias for --resolver 1.1.1.1 to @1.1.1.1 globally to all commands that support the resolver option. I think this is the most critical. I keep using the dig format when trying to set a resolver