fossa-action VS reflex-platform

For us, there were a couple advantages. For context, I work at FOSSA (https://fossa.com/). Our core product solves software supply chain needs in enterprises (around licensing and security), and our core technology is around compiler, build, and source code analysis.

Off the top of my head, 3 advantages stood out:

1. First, if you're not going that far off the beaten low-level path, Haskell has incredible productivity benefits. Effect tracking has enormous benefits for testability and understandability. If you've ever been down a debugging rabbit hole shaped like "there's no way this logging call is sending that API request", then you might be pleasantly surprised to discover that you can statically guarantee that this doesn't occur in Haskell programs! Pattern matching, algebraic data types (sum types!), and typeclass derivation make it much easier to make it impossible to construct invalid representations of data. Other languages are finally picking this up, but their versions of pattern matching often have caveats for backwards-idiom-compatibility. And monads are a very powerful abstraction. It's like being able to write your own semantics for async-await (I've talked more about this before at https://lobste.rs/s/7cllte/monads_part_six_really_what_is_mo...).

2. Haskell was a good domain fit for us. One thing we build is the FOSSA CLI (https://github.com/fossas/fossa-cli/), which runs in customer CI pipelines to analyze their builds. It's a very compiler-shaped problem: shell out to some tools, do a lot of parsing, think very hard, and then spit out a JSON blob to send back to the API. Our first version of this was written in Go. At the time of development, writing correct, testable parsers in Go was like pulling teeth. We have a relatively small headcount-to-product-surface-area ratio, and our team was running up against the overhead of rewriting traverse in Go over and over again (that's a Haskell-flavored joke, but if you've ever been annoyed at writing yet another for-loop in Go, you get it). We decided to hack out a prototype in Haskell, and it turned out to be a good fit.

3. Lastly, the kind of people who wind up working at FOSSA and are interested in the code analysis bits tend to be the same kind of nerds who love Haskell. We had lots of people on our team who were chomping at the bit to try it, so we decided to try it out. I really can't understate how big of a productivity difference it makes when people are working with tools that they actually enjoy rather than are merely forcing themselves to use. It is night and day.

If you want to learn more, we also did an interview with Serokell on this topic (https://serokell.io/blog/haskell-in-production-fossa), and discussed it on an episode of our engineering podcast (https://fossa.com/blog/fossa-podcast-adopting-haskell/).

FOSSA scan - it is different from OWASP DependencyCheck and from Trivy scan. It is checking code for supply chain attacks on dependencies and for for license violations. For example, let's say, your project is using DependaBot tool for automatically upgrading dependencies. And you are using, I don't know, Gradle v7.6 (currently the latest version). A malicious person takes the source code of Gradle v7.6, adds some malicious stuff in it and publishes it in Maven Repository with version 7.7 . Don't know about DependaBot but some tools for sure will try to upgrade your 7.6 to 7.7 then. And often these upgrades are automated. If all the tests pass, end-to-end functionality tests pass, deployment passes, then the upgrade goes through. AND a vulnerability can be introduced to your system. FOSSA scan is for checking if the dependency supply chain is legitimate or fake. A downside is that a full scan will take many hours. So one of our teams is just testing it out, right now. It is not feasible to put a 4 hour blocker in our build pipelines. But with fast releases a vulnerability can be introduced already into the system.

We used reflex-frp, so our app was a webview that worked on localhost and Android. The docs say it also works on iOS but we don't have an iPhone.

The process was learning Functional Reactive Programming, then learning reflex-frp, then getting a contract with obsidian (creators of reflex) for one hour a week where we could ask questions.

( https://github.com/reflex-frp/reflex-platform )

We had a grant requirement to create a phone client for Tahoe-LAFS, a Python application with a bunch of dependencies, including ZFEC, a forward error correction library.

( https://tahoe-lafs.readthedocs.io/ )

( https://github.com/tahoe-lafs/zfec/ )

We needed bug for bug compatibility with the Python codebase, so I ran Tahoe on localhost and tested the Haskell client against the Python server. We used servant to build the API, since it builds both client and server side from the same description.

( https://hackage.haskell.org/package/servant )

The type classes do take a toll on performance, but in reflex-platform we change GHC's default flags to make the situation a lot better. It's still not ideal, but our performance winds up being OK for real applications. The most important part is that the performance scales reasonably well as the application grows. It might probably be good at some point to use backpack instead of a typeclass so that specialization can be enforced - though I'd prefer if GHC gave a way to just force specialization more effectively.

Obelisk / reflex-platform contain nix-based solutions to building Haskell code for mobile, so you might be interested in checking out how they do it (or just using them).

In this series of posts, we will describe how a Haskell web application can be developed using reflex-platform. reflex-platform offers reflex and reflex-dom packages. reflex package is the Haskell implementation of Functional reactive programming (FRP). reflex-dom library contains a large number of functions, classes, and types used when dealing with DOM. The packages are separated as it is possible to use the FRP approach not only for web-development. We will develop theTodo List application that allows carrying out various manipulations on the task list.

reflex-platform

To clarify the situation, the canonical way to develop reflex-dom projects is to start from the reflex-platform. See here: https://github.com/reflex-frp/reflex-platform/blob/develop/docs/project-development.rst

This might also be coming from the tests of the library (even if they can run in the browser, their tests might not). You can disabled tests using an overrides attribute in project.nix (if using reflex-stone). You can see what it should look like here : https://github.com/reflex-frp/reflex-platform/blob/develop/project/default.nix#L79. You should add this attribute at the same level where "useWarp = true;" is. This should then have lines like "diagrams = pkgs.haskell.lib.dontCheck super.diagrams;" for example if you want to disable the tests for the diagrams package.

then you compile to js using ghcjs like this, then closure compile and gzip it to get the size way down. Then it just becomes a normal script you include wherever you need it.