feat: support vec/array impl for DnsResolver

[NOOMA-42]

Description

support vec/array impl for DnsResolver to enable chaining resolver together

Related issues

#332

[GlenDC]

Hi! thanks for picking up this PR where it was left. Left a couple of remarks already.

[GlenDC]

Different DnsResolvers probably have their own error types. So in that case, and given this is a generic feature, best to collect the errors as BoxError so that we can collect the errors regardless of the types.

[NOOMA-42]

Different DnsResolvers probably have their own error types. So in that case, and given this is a generic feature, best to collect the errors as BoxError so that we can collect the errors regardless of the types.

I have a more general question which might outside of the scope of this pull request. When do we have to implement a specific error type and when to implement only box? We could discuss in Discord if this is inappropriate to discuss here.

[GlenDC]

Minor changes still to go, other than that it seems this PR is about to be ready to be merged into the main branch! thx a lot!!!

[GlenDC]

I have a more general question which might outside of the scope of this pull request. When do we have to implement a specific error type and when to implement only box? We could discuss in Discord if this is inappropriate to discuss here.

Questions are not quickly out of scope. Also to be clear, I'm no oracle and the decisions I made and will make might be misguided or mistakes. As such it defintely is up to you and other contributors/users to scrutanise my choices and answers.

Here is how I think about it:

• for cases like this it doesn't make sense to have anything else besides a BoxError. Reason being is because we not only not know the types of errors that will be inserted, we also do not know the amount. An enum approach will therefore not work
• sometimes you do have fixed variants and you could opt-in for an enum. Question is however, is that really what you want to do. I'll get back to this kind of topic at the end.
• and then there are layers where it is very clear. E.g. think of a TimeoutLayer. In that case it is very easy to implement a TimeoutError which either is a timeout or the inner service error. Here it does make sense to make such an enum-like error, but only if you expect people to handle the error case immediately.

That last point is subtle but important. Given rama is all about layers, a giant tree of possible error variants quickly explodes. At that point you'll start using your enum pretty much like a BoxError. What do I mean with that? Well the power of an enum is normally that you type-statically can handle all possible error cases or get a compile error if you forgot some case. It's in your face. However what if you have a deeply nested enum because each layer has several variants of errors. That means that as a user of this layer stack you should really handle all these cases explicitly, which no one really does, or at least not good. So what usually happens is that you would handle at that level some specific cases explicitly and others just in a very general way. Which is what you can just as well do with a BoxError by using the source method, even though that method has its own quarks.

When I started making Rama I was defning a lot more explicit type errors, but that only really makes sense if you have a valid poossible way for your users to handle these cases. The line can be blurry though, so in case I missed the mark somewhere in rama, do feel free to open a ticket on it or discuss it on Discord or via github.

In the context of this PR and its linked ticket however, I see only one way to handle this and that is with something that unites all possible errors. This because what I highlighted at the start, you have an unknown amount of errors. Doesn't have to be like that of course. As you could also design this without a Vec/Array of DnsResolvers and instead turn it into something like a DnsChain<T> where T starts as Either, and with a builder-like pattern turn it into Either3, Either4, etc... In that kind of scenario you could also return your errors as an enum... but again at what benefit. It's gonna be pretty painful to have to develop and maintain that kind of variant tree of errors. Instead it makes a lot more sense to just use the more dynamic approach and check whather or not its some kind of type of error that you might want to handle differently (e.g. because it's temporary) vs all other ones.

[NOOMA-42]

Thanks for this detailed explanation :) @GlenDC