Servant project ideas for Summer of Haskell 2017?
51 views
Skip to first unread message
Jasper Van der Jeugt
Mar 15, 2017, 9:42:56 AM3/15/17
to haskell-servant
Hey all,I'm co-organizing the Summer of Haskell 2017 [1]. We'll be collecting
project ideas in a github repository so we can create a great "ideas
page", which was one of the main pain points as to why we didn't get
into the Google Summer of Code 2017.
Are there any project ideas for Servant that could use three months of
a student's time? Would anyone volunteer to mentor such a project (if
it is picked)? Please reach out to me if anything comes to mind.
[1]: https://www.reddit.com/r/haskell/comments/5wpwkq/summer_of_haskell_2017/
Jasper
Alp Mestanogullari
Mar 15, 2017, 10:28:08 AM3/15/17
to Jasper Van der Jeugt, haskell-servant
Hi Jasper!
I would not mind mentoring a student working on anything servant-related, as is the case of many (most?) servant contributors I'm sure.- Maybe making the a servant-powered server more easily configurable by default (error messages and their formats, etc)? https://github.com/haskell-servant/servant/issues/689
- Get the story straight wrt servant-client / ghcjs. End up with a feature-complete servant-client variant that's meant to be used with ghcjs. Maybe we have that already? Don't think so but please someone correct me if I'm wrong.
- Figure out a solution to having "advertisable errors" (https://github.com/haskell-servant/servant/issues/349), where each endpoint specifies what's returned in case of success but also in case of failure, and for each failure document the type of the value returned and the HTTP status code.
- Or, at the very opposite: explore the idea of making the standard monad for handlers, 'Handler', be a MonadState (StatusCode, Headers). Endpoints would be able to dynamically set the status code and headers depending on what happens. Maybe this can actually fit with the previous idea, if we remove status codes and what not from the API type. But we might still be able to advertise the different possible return types, depending on if things go well or not. This is vague, so should probably not top the list.
- Performance work? The problem with this task is that it's not really well defined, but it'd be nice to compare raw wai/warp with servant-server and see how far we're behind, spotting culprits and fixing them. Not sure it's a great SoH project, given how vague it is. There are ways to see that we could be doing better though, e.g https://github.com/haskell-servant/servant/issues/651 even though there it might be the app's fault and not servant's.
- Figure out a good, solid, definitive solution to doing redirects, possibly with the help of the discussion/code from https://github.com/haskell-servant/servant/issues/117 as well as the type-safe links.
--
You received this message because you are subscribed to the Google Groups "haskell-servant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-servant+unsubscribe@googlegroups.com.
To post to this group, send email to haskell-servant@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-servant/8c126bcb-69de-415f-b10d-291f44451adc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Alp Mestanogullari
Julian Arni
Mar 15, 2017, 8:24:06 PM3/15/17
to Alp Mestanogullari, haskell...@googlegroups.com
Hey all,
Some more suggestions:
- Custom type error (issue #576). This would make servant a lot more
user-friendly. And I think it'd would actually be quite fun. Possibly
included would be #713.
- Adding decent benchmarking to servant-quickcheck. As a stretch goal that I
think is really cool, we could try doing simple ML over features of the API
to try to figure out quite nuanced performance issues with any given
server. For example, discovering that the response time on a GET on
"somepath" has a component that's linear on the number of previous
successful POST requests on "somepath" (which might for example indicate
that the developer forgot to put an index in the DB). Or that some endpoint
is essentially single-threaded (because e.g. there's contention on an
MVar). Or even (gasp!) that you can reach a state of deadlock.
- Automatic HATEOAS support.
- Automatic versioning support. The idea is to use diff datatypes in the API,
as well as the API type itself, to discover backwards-incompatibilities,
warn the developer about them, and (somewhat automatically) use headers
with API hashes to figure out how to support multiple versions of an API.
kosmikus might want to weigh in here.
- Start writing a book?
Some notes on Alp's suggestions inline.
On Wed, Mar 15, 2017 at 03:27:27PM +0100, Alp Mestanogullari wrote:
> Hi Jasper!
>
> I would not mind mentoring a student working on anything servant-related,
> as is the case of many (most?) servant contributors I'm sure.
>
> If we put aside all project ideas that would make things more generic
> (easier to port to other backends than wai/warp, etc) but with no real, big
> immediate impact/benefit (which we should I think, given the nature of the
> summer of haskell), here's what I can come up with:
>
> - We have a fairly decent approach to authentication, both in servant
> itself (
> https://haskell-servant.readthedocs.io/en/stable/tutorial/Authentication.html)
> and in separate packages (e.g
> https://github.com/plow-technologies/servant-auth). What we don't have
> however is a whole bunch of _instances_ of those things that implement
> existing, widely used authentication protocols. We may have a couple of
> those, but really not much and this has certainly been missed by a lot of
> people. Is it finally time for servant to support many such protocols out
> of the box? We could list a reasonable number of those that could be
> implemented over the course of 2-3 months, including time to write tests on
> the server-side of things and client interpretations as well. Maybe
> supporting between 3 and 5 protocols sounds reasonable, in a summer?
There's servant-auth, which I never properly announced, but supports API keys
via JWT, cookies, and basic auth. Conspicuously missing is OAuth.
>
> - Maybe making the a servant-powered server more easily configurable by
> default (error messages and their formats, etc)?
> https://github.com/haskell-servant/servant/issues/689
+1!
>
> - Get the story straight wrt servant-client / ghcjs. End up with a
> feature-complete servant-client variant that's meant to be used with ghcjs.
> Maybe we have that already? Don't think so but please someone correct me if
> I'm wrong.
I think more generally servant-client should be separated into
servant-client-core, and then multiple backends. This would allow for
servant-client-ghcjs, as well as servant-client-haxl. Such packages already
currently exist, but they are forks of servant-client, and so annoying to
maintain.
>
> - Figure out a solution to having "advertisable errors" (
> https://github.com/haskell-servant/servant/issues/349), where each endpoint
> specifies what's returned in case of success but also in case of failure,
> and for each failure document the type of the value returned and the HTTP
> status code.
>
> - Or, at the very opposite: explore the idea of making the standard monad
> for handlers, 'Handler', be a MonadState (StatusCode, Headers). Endpoints
> would be able to dynamically set the status code and headers depending on
> what happens. Maybe this can actually fit with the previous idea, if we
> remove status codes and what not from the API type. But we might still be
> able to advertise the different possible return types, depending on if
> things go well or not. This is vague, so should probably not top the list.
I agree that there is something here, but I also think we need to flesh it out
before proposing it.
>
> - Performance work? The problem with this task is that it's not really well
> defined, but it'd be nice to compare raw wai/warp with servant-server and
> see how far we're behind, spotting culprits and fixing them. Not sure it's
> a great SoH project, given how vague it is. There are ways to see that we
> could be doing better though, e.g
> https://github.com/haskell-servant/servant/issues/651 even though there it
> might be the app's fault and not servant's.
>
> - Figure out a good, solid, definitive solution to doing redirects,
> possibly with the help of the discussion/code from
> https://github.com/haskell-servant/servant/issues/117 as well as the
> type-safe links.
>
> - XML content type (both reading and writing) ? Not sure it's that
> demanded, but sure is enterprisey and we recently got someone asking about
> it: https://github.com/haskell-servant/servant/issues/711 -- this is mostly
> not related to servant though, most of the work would go in defining a
> "FromXML/ToXML" kind of thing with some machinery for defining new
> instances using picklers or lenses/traversals or something else.
This I think is a weekend's worth of work at most, rather than a summers!
>
> This is all I have, waiting to read other people's suggestions.
>
> On Wed, Mar 15, 2017 at 2:42 PM, Jasper Van der Jeugt <jasp...@gmail.com>
> wrote:
>
> > Hey all,
> >
> > I'm co-organizing the Summer of Haskell 2017 [1]. We'll be collecting
> > project ideas in a github repository so we can create a great "ideas
> > page", which was one of the main pain points as to why we didn't get
> > into the Google Summer of Code 2017.
> >
> > Are there any project ideas for Servant that could use three months of
> > a student's time? Would anyone volunteer to mentor such a project (if
> > it is picked)? Please reach out to me if anything comes to mind.
> >
> > [1]: https://www.reddit.com/r/haskell/comments/5wpwkq/summer_of_
> > haskell_2017/
> >
> > Jasper
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "haskell-servant" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to haskell-serva...@googlegroups.com.
> > To post to this group, send email to haskell...@googlegroups.com.
> > .
> To post to this group, send email to haskell...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-servant/CADZnDvDuuVWxcMft53Qyfg2pdJn1-q_T%3DL%2BCNDcmHNfHLTbETw%40mail.gmail.com.
Julian K. Arni
Haskell Consultant, Turing Jump
https://turingjump.com
Some more suggestions:
- Custom type error (issue #576). This would make servant a lot more
user-friendly. And I think it'd would actually be quite fun. Possibly
included would be #713.
- Adding decent benchmarking to servant-quickcheck. As a stretch goal that I
think is really cool, we could try doing simple ML over features of the API
to try to figure out quite nuanced performance issues with any given
server. For example, discovering that the response time on a GET on
"somepath" has a component that's linear on the number of previous
successful POST requests on "somepath" (which might for example indicate
that the developer forgot to put an index in the DB). Or that some endpoint
is essentially single-threaded (because e.g. there's contention on an
MVar). Or even (gasp!) that you can reach a state of deadlock.
- Automatic HATEOAS support.
- Automatic versioning support. The idea is to use diff datatypes in the API,
as well as the API type itself, to discover backwards-incompatibilities,
warn the developer about them, and (somewhat automatically) use headers
with API hashes to figure out how to support multiple versions of an API.
kosmikus might want to weigh in here.
- Start writing a book?
Some notes on Alp's suggestions inline.
On Wed, Mar 15, 2017 at 03:27:27PM +0100, Alp Mestanogullari wrote:
> Hi Jasper!
>
> I would not mind mentoring a student working on anything servant-related,
> as is the case of many (most?) servant contributors I'm sure.
>
> If we put aside all project ideas that would make things more generic
> (easier to port to other backends than wai/warp, etc) but with no real, big
> immediate impact/benefit (which we should I think, given the nature of the
> summer of haskell), here's what I can come up with:
>
> - We have a fairly decent approach to authentication, both in servant
> itself (
> https://haskell-servant.readthedocs.io/en/stable/tutorial/Authentication.html)
> and in separate packages (e.g
> https://github.com/plow-technologies/servant-auth). What we don't have
> however is a whole bunch of _instances_ of those things that implement
> existing, widely used authentication protocols. We may have a couple of
> those, but really not much and this has certainly been missed by a lot of
> people. Is it finally time for servant to support many such protocols out
> of the box? We could list a reasonable number of those that could be
> implemented over the course of 2-3 months, including time to write tests on
> the server-side of things and client interpretations as well. Maybe
> supporting between 3 and 5 protocols sounds reasonable, in a summer?
via JWT, cookies, and basic auth. Conspicuously missing is OAuth.
>
> - Maybe making the a servant-powered server more easily configurable by
> default (error messages and their formats, etc)?
> https://github.com/haskell-servant/servant/issues/689
>
> - Get the story straight wrt servant-client / ghcjs. End up with a
> feature-complete servant-client variant that's meant to be used with ghcjs.
> Maybe we have that already? Don't think so but please someone correct me if
> I'm wrong.
servant-client-core, and then multiple backends. This would allow for
servant-client-ghcjs, as well as servant-client-haxl. Such packages already
currently exist, but they are forks of servant-client, and so annoying to
maintain.
>
> - Figure out a solution to having "advertisable errors" (
> https://github.com/haskell-servant/servant/issues/349), where each endpoint
> specifies what's returned in case of success but also in case of failure,
> and for each failure document the type of the value returned and the HTTP
> status code.
>
> - Or, at the very opposite: explore the idea of making the standard monad
> for handlers, 'Handler', be a MonadState (StatusCode, Headers). Endpoints
> would be able to dynamically set the status code and headers depending on
> what happens. Maybe this can actually fit with the previous idea, if we
> remove status codes and what not from the API type. But we might still be
> able to advertise the different possible return types, depending on if
> things go well or not. This is vague, so should probably not top the list.
before proposing it.
>
> - Performance work? The problem with this task is that it's not really well
> defined, but it'd be nice to compare raw wai/warp with servant-server and
> see how far we're behind, spotting culprits and fixing them. Not sure it's
> a great SoH project, given how vague it is. There are ways to see that we
> could be doing better though, e.g
> https://github.com/haskell-servant/servant/issues/651 even though there it
> might be the app's fault and not servant's.
>
> - Figure out a good, solid, definitive solution to doing redirects,
> possibly with the help of the discussion/code from
> https://github.com/haskell-servant/servant/issues/117 as well as the
> type-safe links.
>
> - XML content type (both reading and writing) ? Not sure it's that
> demanded, but sure is enterprisey and we recently got someone asking about
> it: https://github.com/haskell-servant/servant/issues/711 -- this is mostly
> not related to servant though, most of the work would go in defining a
> "FromXML/ToXML" kind of thing with some machinery for defining new
> instances using picklers or lenses/traversals or something else.
>
> This is all I have, waiting to read other people's suggestions.
>
> On Wed, Mar 15, 2017 at 2:42 PM, Jasper Van der Jeugt <jasp...@gmail.com>
> wrote:
>
> > Hey all,
> >
> > I'm co-organizing the Summer of Haskell 2017 [1]. We'll be collecting
> > project ideas in a github repository so we can create a great "ideas
> > page", which was one of the main pain points as to why we didn't get
> > into the Google Summer of Code 2017.
> >
> > Are there any project ideas for Servant that could use three months of
> > a student's time? Would anyone volunteer to mentor such a project (if
> > it is picked)? Please reach out to me if anything comes to mind.
> >
> > [1]: https://www.reddit.com/r/haskell/comments/5wpwkq/summer_of_
> > haskell_2017/
> >
> > Jasper
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "haskell-servant" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > To post to this group, send email to haskell...@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/
> > msgid/haskell-servant/8c126bcb-69de-415f-b10d-291f44451adc%40googlegroups.
> > com
> > <https://groups.google.com/d/msgid/haskell-servant/8c126bcb-69de-415f-b10d-291f44451adc%40googlegroups.com?utm_medium=email&utm_source=footer>
> > msgid/haskell-servant/8c126bcb-69de-415f-b10d-291f44451adc%40googlegroups.
> > com
> > .
> > For more options, visit https://groups.google.com/d/optout.
> >
>
>
>
> --
> Alp Mestanogullari
>
> >
>
>
>
> --
> Alp Mestanogullari
>
> --
> You received this message because you are subscribed to the Google Groups "haskell-servant" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to haskell-serva...@googlegroups.com.
> You received this message because you are subscribed to the Google Groups "haskell-servant" group.
> To post to this group, send email to haskell...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-servant/CADZnDvDuuVWxcMft53Qyfg2pdJn1-q_T%3DL%2BCNDcmHNfHLTbETw%40mail.gmail.com.
Julian K. Arni
Haskell Consultant, Turing Jump
https://turingjump.com
Reply all
Reply to author
Forward
0 new messages