use chi router instead of ShiftPath

[butonic]

I stumbled over https://benhoyt.com/writings/go-routing/ which examines the different ways routing can be done in golang.

IMO implementing the ocs / ocdav and other http endpoints with the ShiftPath approach makes it hard to understand what code is going to be executed for a given URL. We are using chi in some ocis services, eg the graph and our ocs implementation. We plan to fully move the latter into reva. An overview of what only the additional routing part looks like with shift path can be found in https://github.com/cs3org/reva/pull/1969/files#diff-6462df320ad761b651f59bdd74b3bd9123b0630538b7af253378a039a822b7f6R72-R151.

For readability (and performance) I'd vote to switch to chi. It has no further dependencies, supports quite a few middlewares and wrapping things like the opentelemetry api is easy.

But I'd like to get an opinion from @labkode @ishank011 @refs @C0rby and @rhafer before moving the user provisioning part from ocis to reva. We could make the switch as part of that work as it will touch a lot of the code anyway.

[refs]

I believe the most compelling arguments to adopt chi instead of a trim-based approach are readability (already mentioned) and navigation. When browsing the codebase I rely on ⌘ + f and a combination of the endpoint I'm trying to access and case "<slug>". I always find what I look for but 90% of the times that is just an entry point and I have to navigate my way down.

With a router, finding an endpoint is trivial as they would all be in the same location, and so will their handlers. A single unidimensional location with little need to traverse more files to find the function you're trying to fix.

It would also make adding endpoints more trivial. Right now we have clear defined endpoints, but in the future, as more functionality is added, adding new routes means touching n files, where n is potentially as many parts the path has (i.e: /remote.php/webdav/spaces/list) -> case "spaces" -> case "list" inside the case "spaces" handler and so on, sort of like a russian doll problem.

I would however be interested in the performance gain / loss of using chi as opposed to the current routing, I wouldn't adventure to say chi is faster than this because I have not had a look at their code base.

All weighed in, I think bringing Chi to the mix would be a nice addition, with no dependencies.

[labkode]

@butonic can you prepare a PR for that, let's start with a small service to see how it behaves.

[rhafer]

can you prepare a PR for that, let's start with a small service to see how it behaves.

I am working on that.

[labkode]

@rhafer awesome!