by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Ihor Mielientiev
    @mielientiev
    Hi @pheymann
    I'm trying to understand how typedapi works internally.
    So my goal is to get an API structure and extract it to some internal representation so I can generate a Swagger file.
    The main problem is I didn't understand how exactly I can extract necessary info from a FinalCons[H] and CompositionCons[H]
    Paul Heymann
    @pheymann
    Hi,
    yeah the API was/is an experiment to do most computation on the type-level. Therefore, you will not encounter a lot if "real" values you can work with. What that means is, that you also have to extract necessary information from the type itself by using type-classes.
    I will write a short document describing how the H in FinalCons is created and what it represents. Maybe that will help you to figure out how to work with it. Also I will add some information to your Swagger issue.
    Ihor Mielientiev
    @mielientiev
    yep, I already found the way to do this, thank you
    Paul Heymann
    @pheymann
    :+1:
    Ihor Mielientiev
    @mielientiev
    I just think about the API for generating a swagger file....
    and how to expose it
    Paul Heymann
    @pheymann
    As I wrote in the issue, it is straight forward to get the information stored in an API with some type-class, store it in some data structure and pass it to a swagger specs generator. But to find a way to add descriptions will be hard. At least I don't see a simple way to do that without rendering the API definition completely unreadable.
    Paul Heymann
    @pheymann
    But maybe you come up with a creative solution
    Wojtek Pituła
    @Krever
    Hey, I jumped in to ask a question: have you considered https://github.com/julienrf/endpoints as an alternative to creating a new library? I know that implementation differs (endpoints use values instead of types) but end result seems very similar. I may have had asked this question before, if so, apologies.
    Paul Heymann
    @pheymann

    Hi @Kreverat the time I was looking for a Scala implementation of Servant which didn't include your lib because it is not marked as such. Furthermore, I wanted (and still want) to leverage Scala's type system.

    In the end, both libraries target the same market I would say. But why not? A healthy competition is "always" a good thing ;)

    Wojtek Pituła
    @Krever
    Im not saying its not, Im more than happy to see your work :) Just wanted to point endpoints, because if I had an alternative at the time I started to work on it, I probably would not start at the first place. I personally wanted the result (endpoints definitions shared between server, client and docs) and the lib is just a mean to the end. You could also think of leveraging our set of interpreters somehow (no idea if its possible, but writing them from scratch is quite a lot of work).