I wrote a similar library, want me to merge some of its features here?

[martyall]

I wrote a similar library at FOAM when we were getting off of servant-purescript, the haskell library that generates a purescript client library from a servant api type. Ultimately we had a lot of trouble using that library and it made more sense to just reimplement the parts we wanted in purescript directly.

However, I don't really want to maintain it solo or add features to it, so I'm hoping that maybe we can compare and decide if anything from that lib is worth merging into this one. In particular, I think the way we did query params was pretty nice (using purescript-heterogeneous + parameterizing over Required, Maybe, or Array).

What do you think?

[nsaunders]

Hi @blinky3713, thanks for reaching out. As it stands, @owickstrom has other priorities; and I have offered to take on some basic maintenance tasks on this project as well as related projects hyper, purescript-hypertrout, and purescript-trout-client. So far, I have managed to get all of these projects to build on 0.12 and updated most of the dependencies, but there is still much work to do.

Have you had a chance to review these other projects yet?

[blankhart]

I am new to Purescript, found purescript-servant, and put together a frontend router using its concepts at purescript-servant-routing as a way of learning the type system and language features, before knowing anything about purescript-trout.

Based on this thread and @blinky3713's comments about maintaining purescript-servant, my impulse is to consolidate everything the router needs in a new standalone library and then perhaps write an adapter that would allow users to define APIs using the purescript-trout DSL as an alternative to its native DSL.

There probably would be some duplication of HasLinks code. But if purescript-trout has a substantial following, this would allow users of both libraries to define SPA and REST routes using a consistent interface, while also allowing the router to evolve independently and with fewer dependencies.

Interested in any thoughts though.