Servantify Galley Teams [2/2]

[stephen-smith]

JIRA:

• https://wearezeta.atlassian.net/browse/SQSERVICES-1074 (search visibiliy)
• https://wearezeta.atlassian.net/browse/SQSERVICES-1078

Checklist

• The PR Title explains the impact of the change.
• The PR description provides context as to why the change should occur and what the code contributes to that effect. This could also be a link to a JIRA ticket or a Github issue, if there is one.
• changelog.d contains the following bits of information (details):
  • A file with the changelog entry in one or more suitable sub-sections. The sub-sections are marked by directories inside changelog.d.

[pcapriotti]

Looks good!

One thing I'd like to improve is the use of NoContent, which is a bit of a hack in servant, and it contaminates the handler code with servant-specific nonsense. We have created a MultiVerb combinator to solve this and other limitations of servant, and here it works pretty well (in its MultiVerb1 incarnation, which is for a single response).

I've taken the liberty of adding a commit to this PR which removes the uses of NoContent. As you can see, a lot of meaningless glue code around the handler just goes away.

[fisx]

Looks good!

One thing I'd like to improve is the use of NoContent, which is a bit of a hack in servant, and it contaminates the handler code with servant-specific nonsense. We have created a MultiVerb combinator to solve this and other limitations of servant, and here it works pretty well (in its MultiVerb1 incarnation, which is for a single response).

I've taken the liberty of adding a commit to this PR which removes the uses of NoContent. As you can see, a lot of meaningless glue code around the handler just goes away.

Definitely a good change, but the glue code you removed was mostly historical: when we were preparing the wai-route code for servant in the past, we had two functions: a wrapper handlerH that had a signature accomodating wai-route, and handler with a signature accomodating servant and containing all the application logic. Or the other way around, not sure at the moment, there has been so much refactoring. :)

With the removal of wai-route, we probably want to remove all the wrappers.

[stephen-smith]

With the removal of wai-route, we probably want to remove all the wrappers.

Some I've been able to drop and call the underlying function directly. Some have status code manipulation or Maybe handling, and I've been leaving that in the ...H function. I haven't looked at the NoContent elimination, but that should let me remove a few more ...H functions that were just converting () to NoContent.