[FEATURE][Haskell] Add Middleware support for the haskell servant generator

[Fjolnir-Dvorak]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.
• • @jonschoning <-- You are not responsible but the only official haskell maintainer mentioned in the documentation :D

Description of the PR

I added middleware support to the haskell servant generator and extended the example to handle the additional middleware parameter.

[jonschoning]

reviewers/cc: @gibiansky@f-f@mandrean

[f-f]

I'd say instead of changing the signature of this function we could add a run{{title}}ServerWithMiddleware function, and provide the default implementation of the middleware here

In this way we wouldn't have to document how to get a default middleware, since we'd have that already implemented

[Fjolnir-Dvorak]

That would be a good Idea to keep backwards-compability, though I would keep the documentation since I think that the call with middleware should be the preferred one since an ID-function does not add any runtime overhead.

[Drezil]

In this way we wouldn't have to document how to get a default middleware, since we'd have that already implemented

The 'default'-Middleware is literally just id and the example-server would have that as default.
I fear that if one adds wrappers for this it could start to set a precedence for every case where this could be extended.

Another "clean" solution could be to add a datatype:

dataServerConfig=ServerConfig{serverMiddleware::Middleware}deriving (....)
defaultServerConfig =ServerConfigid-- or with data-defaultinstanceDefaultServerConfigwhere
def =ServerConfigid

and people using defaultServerConfig would not be affected if we change things in any way in the future. Especially if the use the Default-Pattern: http://hackage.haskell.org/package/data-default

let myConfig = defaultServerConfig { serverMiddleware = myMiddleware }
-- or with data-defaultlet myConfig = def { serverMiddleware = myMiddleware }

This way we would never have to update/break the type-signature of the implementation for all future versions.

[Fjolnir-Dvorak]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.
• • @jonschoning <-- You are not responsible but the only official haskell maintainer mentioned in the documentation :D

Description of the PR

I added middleware support to the haskell servant generator and extended the example to handle the additional middleware parameter.

[jonschoning]

reviewers/cc: @gibiansky@f-f@mandrean

[f-f]

I'd say instead of changing the signature of this function we could add a run{{title}}ServerWithMiddleware function, and provide the default implementation of the middleware here

In this way we wouldn't have to document how to get a default middleware, since we'd have that already implemented

[Fjolnir-Dvorak]

That would be a good Idea to keep backwards-compability, though I would keep the documentation since I think that the call with middleware should be the preferred one since an ID-function does not add any runtime overhead.

[Drezil]

In this way we wouldn't have to document how to get a default middleware, since we'd have that already implemented

The 'default'-Middleware is literally just id and the example-server would have that as default.
I fear that if one adds wrappers for this it could start to set a precedence for every case where this could be extended.

Another "clean" solution could be to add a datatype:

dataServerConfig=ServerConfig{serverMiddleware::Middleware}deriving (....)
defaultServerConfig =ServerConfigid-- or with data-defaultinstanceDefaultServerConfigwhere
def =ServerConfigid

and people using defaultServerConfig would not be affected if we change things in any way in the future. Especially if the use the Default-Pattern: http://hackage.haskell.org/package/data-default

let myConfig = defaultServerConfig { serverMiddleware = myMiddleware }
-- or with data-defaultlet myConfig = def { serverMiddleware = myMiddleware }

This way we would never have to update/break the type-signature of the implementation for all future versions.

[Fjolnir-Dvorak]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.
• • @jonschoning <-- You are not responsible but the only official haskell maintainer mentioned in the documentation :D

Description of the PR

I added middleware support to the haskell servant generator and extended the example to handle the additional middleware parameter.

[jonschoning]

reviewers/cc: @gibiansky@f-f@mandrean

[f-f]

I'd say instead of changing the signature of this function we could add a run{{title}}ServerWithMiddleware function, and provide the default implementation of the middleware here

In this way we wouldn't have to document how to get a default middleware, since we'd have that already implemented

[Fjolnir-Dvorak]

That would be a good Idea to keep backwards-compability, though I would keep the documentation since I think that the call with middleware should be the preferred one since an ID-function does not add any runtime overhead.

[Drezil]

In this way we wouldn't have to document how to get a default middleware, since we'd have that already implemented

The 'default'-Middleware is literally just id and the example-server would have that as default.
I fear that if one adds wrappers for this it could start to set a precedence for every case where this could be extended.

Another "clean" solution could be to add a datatype:

dataServerConfig=ServerConfig{serverMiddleware::Middleware}deriving (....)
defaultServerConfig =ServerConfigid-- or with data-defaultinstanceDefaultServerConfigwhere
def =ServerConfigid

and people using defaultServerConfig would not be affected if we change things in any way in the future. Especially if the use the Default-Pattern: http://hackage.haskell.org/package/data-default

let myConfig = defaultServerConfig { serverMiddleware = myMiddleware }
-- or with data-defaultlet myConfig = def { serverMiddleware = myMiddleware }

This way we would never have to update/break the type-signature of the implementation for all future versions.

[Fjolnir-Dvorak]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.
• • @jonschoning <-- You are not responsible but the only official haskell maintainer mentioned in the documentation :D

Description of the PR

I added middleware support to the haskell servant generator and extended the example to handle the additional middleware parameter.

[jonschoning]

reviewers/cc: @gibiansky@f-f@mandrean

[f-f]

I'd say instead of changing the signature of this function we could add a run{{title}}ServerWithMiddleware function, and provide the default implementation of the middleware here

In this way we wouldn't have to document how to get a default middleware, since we'd have that already implemented

[Fjolnir-Dvorak]

That would be a good Idea to keep backwards-compability, though I would keep the documentation since I think that the call with middleware should be the preferred one since an ID-function does not add any runtime overhead.

[Drezil]

In this way we wouldn't have to document how to get a default middleware, since we'd have that already implemented

The 'default'-Middleware is literally just id and the example-server would have that as default.
I fear that if one adds wrappers for this it could start to set a precedence for every case where this could be extended.

Another "clean" solution could be to add a datatype:

dataServerConfig=ServerConfig{serverMiddleware::Middleware}deriving (....)
defaultServerConfig =ServerConfigid-- or with data-defaultinstanceDefaultServerConfigwhere
def =ServerConfigid

and people using defaultServerConfig would not be affected if we change things in any way in the future. Especially if the use the Default-Pattern: http://hackage.haskell.org/package/data-default

let myConfig = defaultServerConfig { serverMiddleware = myMiddleware }
-- or with data-defaultlet myConfig = def { serverMiddleware = myMiddleware }

This way we would never have to update/break the type-signature of the implementation for all future versions.

[Fjolnir-Dvorak]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.
• • @jonschoning <-- You are not responsible but the only official haskell maintainer mentioned in the documentation :D

Description of the PR

I added middleware support to the haskell servant generator and extended the example to handle the additional middleware parameter.

[jonschoning]

reviewers/cc: @gibiansky@f-f@mandrean

[f-f]

I'd say instead of changing the signature of this function we could add a run{{title}}ServerWithMiddleware function, and provide the default implementation of the middleware here

In this way we wouldn't have to document how to get a default middleware, since we'd have that already implemented

[Fjolnir-Dvorak]

That would be a good Idea to keep backwards-compability, though I would keep the documentation since I think that the call with middleware should be the preferred one since an ID-function does not add any runtime overhead.

[Drezil]

In this way we wouldn't have to document how to get a default middleware, since we'd have that already implemented

The 'default'-Middleware is literally just id and the example-server would have that as default.
I fear that if one adds wrappers for this it could start to set a precedence for every case where this could be extended.

Another "clean" solution could be to add a datatype:

dataServerConfig=ServerConfig{serverMiddleware::Middleware}deriving (....)
defaultServerConfig =ServerConfigid-- or with data-defaultinstanceDefaultServerConfigwhere
def =ServerConfigid

and people using defaultServerConfig would not be affected if we change things in any way in the future. Especially if the use the Default-Pattern: http://hackage.haskell.org/package/data-default

let myConfig = defaultServerConfig { serverMiddleware = myMiddleware }
-- or with data-defaultlet myConfig = def { serverMiddleware = myMiddleware }

This way we would never have to update/break the type-signature of the implementation for all future versions.

[Fjolnir-Dvorak]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.
• • @jonschoning <-- You are not responsible but the only official haskell maintainer mentioned in the documentation :D

Description of the PR

I added middleware support to the haskell servant generator and extended the example to handle the additional middleware parameter.

[jonschoning]

reviewers/cc: @gibiansky@f-f@mandrean

[f-f]

I'd say instead of changing the signature of this function we could add a run{{title}}ServerWithMiddleware function, and provide the default implementation of the middleware here

In this way we wouldn't have to document how to get a default middleware, since we'd have that already implemented

[Fjolnir-Dvorak]

That would be a good Idea to keep backwards-compability, though I would keep the documentation since I think that the call with middleware should be the preferred one since an ID-function does not add any runtime overhead.

[Drezil]

In this way we wouldn't have to document how to get a default middleware, since we'd have that already implemented

The 'default'-Middleware is literally just id and the example-server would have that as default.
I fear that if one adds wrappers for this it could start to set a precedence for every case where this could be extended.

Another "clean" solution could be to add a datatype:

dataServerConfig=ServerConfig{serverMiddleware::Middleware}deriving (....)
defaultServerConfig =ServerConfigid-- or with data-defaultinstanceDefaultServerConfigwhere
def =ServerConfigid

and people using defaultServerConfig would not be affected if we change things in any way in the future. Especially if the use the Default-Pattern: http://hackage.haskell.org/package/data-default

let myConfig = defaultServerConfig { serverMiddleware = myMiddleware }
-- or with data-defaultlet myConfig = def { serverMiddleware = myMiddleware }

This way we would never have to update/break the type-signature of the implementation for all future versions.

[Fjolnir-Dvorak]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.
• • @jonschoning <-- You are not responsible but the only official haskell maintainer mentioned in the documentation :D

Description of the PR

I added middleware support to the haskell servant generator and extended the example to handle the additional middleware parameter.

[jonschoning]

reviewers/cc: @gibiansky@f-f@mandrean

[f-f]

I'd say instead of changing the signature of this function we could add a run{{title}}ServerWithMiddleware function, and provide the default implementation of the middleware here

In this way we wouldn't have to document how to get a default middleware, since we'd have that already implemented

[Fjolnir-Dvorak]

That would be a good Idea to keep backwards-compability, though I would keep the documentation since I think that the call with middleware should be the preferred one since an ID-function does not add any runtime overhead.

[Drezil]

In this way we wouldn't have to document how to get a default middleware, since we'd have that already implemented

The 'default'-Middleware is literally just id and the example-server would have that as default.
I fear that if one adds wrappers for this it could start to set a precedence for every case where this could be extended.

Another "clean" solution could be to add a datatype:

dataServerConfig=ServerConfig{serverMiddleware::Middleware}deriving (....)
defaultServerConfig =ServerConfigid-- or with data-defaultinstanceDefaultServerConfigwhere
def =ServerConfigid

and people using defaultServerConfig would not be affected if we change things in any way in the future. Especially if the use the Default-Pattern: http://hackage.haskell.org/package/data-default

let myConfig = defaultServerConfig { serverMiddleware = myMiddleware }
-- or with data-defaultlet myConfig = def { serverMiddleware = myMiddleware }

This way we would never have to update/break the type-signature of the implementation for all future versions.

[Fjolnir-Dvorak]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.
• • @jonschoning <-- You are not responsible but the only official haskell maintainer mentioned in the documentation :D

Description of the PR

I added middleware support to the haskell servant generator and extended the example to handle the additional middleware parameter.

[jonschoning]

reviewers/cc: @gibiansky@f-f@mandrean

[f-f]

I'd say instead of changing the signature of this function we could add a run{{title}}ServerWithMiddleware function, and provide the default implementation of the middleware here

In this way we wouldn't have to document how to get a default middleware, since we'd have that already implemented

[Fjolnir-Dvorak]

That would be a good Idea to keep backwards-compability, though I would keep the documentation since I think that the call with middleware should be the preferred one since an ID-function does not add any runtime overhead.

[Drezil]

In this way we wouldn't have to document how to get a default middleware, since we'd have that already implemented

The 'default'-Middleware is literally just id and the example-server would have that as default.
I fear that if one adds wrappers for this it could start to set a precedence for every case where this could be extended.

Another "clean" solution could be to add a datatype:

dataServerConfig=ServerConfig{serverMiddleware::Middleware}deriving (....)
defaultServerConfig =ServerConfigid-- or with data-defaultinstanceDefaultServerConfigwhere
def =ServerConfigid

and people using defaultServerConfig would not be affected if we change things in any way in the future. Especially if the use the Default-Pattern: http://hackage.haskell.org/package/data-default

let myConfig = defaultServerConfig { serverMiddleware = myMiddleware }
-- or with data-defaultlet myConfig = def { serverMiddleware = myMiddleware }

This way we would never have to update/break the type-signature of the implementation for all future versions.