search

imalsogreg / servant-reflex

Generate reflex client functions for querying a servant API
BSD 3-Clause "New" or "Revised" License
79 stars 59 forks source link

Example project sends XHR requests when built with reflex-platform but not with haskell.nix #113

Open tfc opened 3 years ago

tfc commented 3 years ago

Hi,

i have a little example project that consists of a backend and a frontend with a shared API definition.

https://github.com/tfc/reflex-servant-backend-frontend-example/tree/haskell-nix

Now it does work really well when built with reflex-platform, but for different reasons i would like to build it with haskell.nix. It is very easy to switch between both nix libraries, but the haskell.nix-built version of the app does not send any XHR requests. I don't see anything in the browser console that makes sense.

When running the same thing with jsaddle in ghc and simpleCors activated, it does work. But that is not how i could deploy it.

I put both nix libraries into the linked branch for others to reproduce, and i also put the pkg versions into the folder pkg-diffs for further inspection (apart from servant-reflex which i use from the master branch here via overrides). Of course there are compiler differences but i was unable to compile both with the same compiler version.

I am not expecting anyone to fix that for me but i am currently simply clueless how to debug this problem at all. Any advice?

imalsogreg commented 3 years ago

Hello! Interesting problem.

My first thought is for you to fork servant-reflex and wrap some of my internals in traceEvent, to validate assumptions about the the times when requests should be triggered.

Another thought, not about debugging, is whether haskell.nix could treat reflex-platform as a dependency? reflex-platform/default.nix is something that can be composed into a larger set of packages managed with nix (it doesn't necessarily have to be the top-level tool that you use to compile reflex projects). However, the reflex-platform package set is fairly complicated and has a large number of haskell packages pinned at versions that may or may not work for you, as well as its own pinned version of nixpkgs. Depending on how tightly coupled your reflex project is with the non-reflex parts, it may be hard to fit reflex-platform in as a nix dependency. I also don't know how haskell.nix works, so I might be way off base about my idea of adding reflex-dom as a dependency under a haskell.nix setup. Looking at your repro case, I see you've done exactly this already.

Thank you for the repro case, maybe this is a good time for me to try out haskell.nix and see if I can help with the AWOL-XHR's problem.

tfc commented 3 years ago

My current workaround in my other project is to compile the linux and windows binaries using haskell.nix - and the JS parts are managed by reflex-platform. So that works for now, but it would of course be great to not have to mix platforms.

I will also tinker around with the traceEvent stuff, as soon as i get to it.

imalsogreg commented 3 years ago

Yeah, that sounds reasonable but not fun.

One quick observation while building your haskell-nix branch is that it seems to be compiling ghc-8.4.4 from source. Is this expected?

tfc commented 3 years ago

One quick observation while building your haskell-nix branch is that it seems to be compiling ghc-8.4.4 from source. Is this expected?

they have their own patches on ghc etc., and they have their own binary cache. you will have long waiting times if you don't use that, see their docs/github project page