Let's make Blocky more flexible

[ThinkChaos]

While working on #449 and #475, I touched the resolver chaining and adding resolver nesting. This has got me thinking it would be nice to be able to configure arbitrary resolver chains, or rather trees, in the config.
This means making createQueryResolver in server.go configuration driven.

I haven't done any code work on this, but have been thinking about it for a while and think I have a decent vision for an implementation.

Here's an example of what I mean by configuration driven,
Please don't pay too much attention to the syntax and names, it's nothing concrete, just a draft to explain what I'm thinking.

resolvers:
- log:
- metrics:
- rewrite:
    rules: [...]
    resolvers:
    - hostsFile:
    - cache:
    - customDNS:
      mapping: [...]
    - conditional:
        home: <router ip>
    - parallel:
      upstreams: [...]

This would make blocky much more flexible, and, I think, easy to understand without looking at createQueryResolver.
My main confusion source while using blocky has been the order in which resolvers run. Having the user decide would help alleviate that IMO.

What do you think of this idea?

P.S. please do not take this as me not liking blocky. On the contrary, I really enjoy using it, and want to help build it into something even greater!

EDIT: sorry accidentally pressed Ctrl-Enter. Filled out the rest!

[0xERR0R]

I have thought about it several times in the past. Making the resolver order configurable can help "power users" with solving of some special problems. But on the other side, they need deep technical understanding about blocky's internal structure and it can lead to unpredictable results. For example: if you move loggingResolver or metricsResolver, you'll get wrong metrics result or incomplete query logs.

I don't know, what is the right way. I tried always to keep things simple (KISS principle), but I see, there are different use cases in the wild and each user has unique network infrastructure.

Perhaps the point has also come where we can think about a completely new concept, maybe some kind of plugins or microservice approach, where the user can decide, which parts of the system he wants to run or to customize.

I am completely open to constructive suggestions or further discussion.

[ThinkChaos]

Yeah I understand your concern. I think the defaults should stay unchanged, and that this should be opt-in to respect KISS without limiting power users.
With that in mind I think generally the people that setup their own infra like this are technical enough to understand that the logging must come early in the chain. Especially with docs and example that would explain how the resolvers are actually called.

I think the plugin idea is good, but I don't personally have the need for it right now, and think it's another major step on top of the custom chain/tree feature.
And I think having plugins will require a way to tell blocky what and in which order plugins should be used. So, at least the way I envision it, plugins would require what I'm proposing.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue was closed because it has been stalled for 5 days with no activity.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue was closed because it has been stalled for 5 days with no activity.