Hi,
I’m trying to resurrect the servant-purescript project and right now I’m wondering which HTTP library I should use for the helpers.
Right now it uses purescript-affjax which is probably fine but comes with dependencies to argonaut and we where thinking about switching to foreign.
Is there an alternative to affjax with fewer dependencies? Something that would enable http-request returning just String would be enough.
Thanks
You can use Affjax while setting the response type to just be a String and it’ll work fine, but you could also use my library Milkis, which a couple different companies are now using for work.
thank you
your first option is what the helper library uses right now - it seems a bit silly to first fetch a string and then use foreign - I already have an adapted version in PR
concerning: Milkis: I’ll have a look into it - not sure what node-fetch is all about and if this actually is what I need (being most likely on the browser)
node-fetch is a dependency only if you want to use it from node, otherwise you use the window fetch binding defined and apply it. there should be some example usages in the README
oh ok - thanks I’ll check it out
Hey @CarstenKoenig, what are your reasons for moving from Argonaut to Foreign? (and I assume you mean purescript-foreign-generic, right?)
(sorry for posting here, I couldn’t find a way to PM)
hey @fsoikin no problem
right now I’ll stick with argonaut. The reason why I was looking into moving to foreign was, that it’s not really easy to get a working version right now, because a few of the generic-rep changes are not yet merged/implemented.
So the idea was to maybe find a lib with fewer dependencies, so that it’ll be easier to keep it up to date in the future.
Moving to (yes) purescript-foreign-generic would of course mean, that I’ll have to find a http-lib not depending on argonaut (which would defeat the purpose a bit).
In the long run I’ll hope to find a way for people to pick what they want - so I think I’ll try to have a argonaut/affix, foreign/whatever and a generic template without implementations for the bridge generator.
But of course I’ll want something workable at first.
I’ve put an PR to purescript-argonaut-generic (https://github.com/purescript-contrib/purescript-argonaut-generic/pull/8) and I’ll still hope this is some time gonna be merged (does not have to be my code obviously - I understand that you don’t exactly have time to check code from people you don’t know, but I need the functionality) - I think we talked about this there already.
But it seems that not many people are using servant-purescript so there is little pressure (well my pet projects but oh well)
PS: this is no rant or finger-pointing or anything (I understand that my comments sometimes seem to suggest this) - I really try to help out - more or less because of this - and I’m knee deep in yak wool
PPS: fixed link
I think there is a misunderstanding here that persists for some reason.
purescript-argonaut-generic is not my repo. I personally like your PR (I even formally “approved” it), but I have no power to merge it.
Just like you, I am very interested in that library being updated for 0.12, and just like you I’m waiting for a repo owner to merge.
no I did understand that’s not your repo - you asked why I thought about switching and the reason is, that right now this functionality is missing.
As you did approve it (very much appreciated) I assumed that you either knew the maintainer or are a maintainer - sorry.
Can you program around an HTTP client type class, rather than a specific implementation? If so, your job as a library writer (servant-purescript?) could be more stable. I don’t know what servant-purescript really is or how to use it, so my comment might be not terribly helpful.
yes something like that might be the 3rd option I mentioned above, but this should not be the default
servant is a Haskell web-framework that allows you to describe your API using types.
From those types you can then automatically generate clients, documentation, etc. (a bit like swagger and indeed there is a package that let’s you create swagger definitions from your API type).
And of course there is/was a package that let’s you create a purescript client (it’s not written by me but I try to get it purescript 0.12, as the original author is not using purescript at the moment (AFAIK)).
So as the idea is to point a few lines of haskell code at the types and api you want and have it generate a working purescript module the default should have “batteries” (http access) included.
The original used argonaut and affix together with it’s own version of argonaut-generic so for now I thought it best to stick to something similar (but I don’t want the argonaut-generic copy for obvious reasons).
But it was not exactly easy (and it’s not done at all) to make the move during the migration of the purescript ecosystem, so I’ll hope to give a second option to use a setting with fewer transitive dependencies - hence my question here.
@CarstenKoenig This is awesome. I am currently using servant for my backend and I have played around with your library.
How does this interoperate with Aeson? Can I get away with just doing:
instance ToJSON X
where toJSON =
genericToJSON defaultOptions { unwrapUnaryRecords = False }
Or is there something else I need to do?
Hi,
I’m not the author - I just try to get it working again.
I have not touched this part yet. The purescript-bridge package is ready to work with 0.12/generics-rep and I’m working on the helper-modules for purescript (actually I wait and see if the argonaut-generic PR will be accepted or if I have to look for something else)
But yes I’ll try to mirror settings like that in the servant-generators (we have to find a way to mirror this setting in argonaut or whatever purescript-json lib we gonna end)
The next goal for now is to just get it working again and next probably to see what happens with the websocket wrapper eskimor (the actual hero/creator) build, as this one is used as an example for servant-purescript
I’ve got a few days off and I hope I’ll get a working version by the end of next week.