Servant project ideas for Summer of Haskell 2017?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Servant project ideas for Summer of Haskell 2017?

jasper van der jeugt

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

--
Reply | Threaded
Open this post in threaded view
|

Re: Servant project ideas for Summer of Haskell 2017?

Alp Mestanogullari
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?

- 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.

- 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 <[hidden email]> 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

--



--
Alp Mestanogullari

--
Reply | Threaded
Open this post in threaded view
|

Re: Servant project ideas for Summer of Haskell 2017?

Julian Arni-2
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 <[hidden email]>
> 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
> >
> > --
> >
> > "haskell-servant" group.
> >
> > email to [hidden email].
> >
> >
> > com
> > <https://groups.google.com/d/msgid/haskell-servant/8c126bcb-69de-415f-b10d-291f44451adc%40googlegroups.com?utm_medium=email&utm_source=footer>
> > .
> >
> >
>
>
>
> --
> Alp Mestanogullari
>
> --
>
>
>
>
>
--
Julian K. Arni
Haskell Consultant, Turing Jump
https://turingjump.com

--






signature.asc (465 bytes) Download Attachment