Review Docs: Writing Custom Filters for API changes

[markmandel]

When I last looked at https://googleforgames.github.io/quilkin/main/book/filters/writing_custom_filters.html

I noticed that there were a few broken links (#367 should totally be a thing), (it looks like we're missing going one level too deep on some of the links).

The main part I saw was that we've improved the experience on "Working with Filter Configuration", and I'm not sure if the current documentation matches what we have via our current API surface.

[markmandel]

I'm going to fixup the 404's, @iffyio would love to double check with you on my comments on "Working with Filter Configuration" is accurate? (i.e. we could streamline that)

[iffyio]

The main part I saw was that we've improved the experience on "Working with Filter Configuration", and I'm not sure if the current documentation matches what we have via our current API surface.

Is there anything in particular that's missing, from what I can tell it looks up to date, not sure of any related filter api changes that would need updating?

[markmandel]

Just doing a quick check through as I fix up some 404s... so I can be more clear!

Looks like the current approach will work, but the new https://googleforgames.github.io/quilkin/main/api/quilkin/config/enum.ConfigType.html#method.deserialize method definitely makes things easier, and we might want to push people in that direction.

That being said, the current approach works, so not sure if we want to block on this for the release? How do you feel?

[markmandel]

To add an extra example, here is what the LoadBalancerFactory looks like now

impl FilterFactory for LoadBalancerFilterFactory {
    fn name(&self) -> &'static str {
        NAME
    }

    fn create_filter(&self, args: CreateFilterArgs) -> Result<Box<dyn Filter>, Error> {
        let config: Config = self
            .require_config(args.config)?
            .deserialize::<Config, ProtoConfig>(self.name())?;

        Ok(Box::new(LoadBalancer {
            endpoint_chooser: config.policy.as_endpoint_chooser(),
        }))
    }
}

That deserialize is sooo nice 😄

[iffyio]

Ah I see what you mean, for this particular case the deserialize isn't exactly identical vs doing it manually only because it requires you have a mapping from config to proto but yeah it definitely makes sense to include it in the doc

[markmandel]

Started updating the example with the new API. Will PR when ready. Haven't touched Rust in a while! 😄