This is my first post to Haskell-Cafe, so pardon me for any
errors. I'm writing on behalf of my company, CentralApp, to
pitch our job
opening. We're a small company and I'm the sole back-end
engineer so far, and we're investing heavily only in Haskell
as our back-end language of choice. A large part of our
codebase is in Scala, since that was the choice I made 4-5
years ago. Since then, I got introduced to Haskell and I'm
only considering it as the programming language of choice for
our back-end infrastructure.
We have plenty of engineering challenges in the pipeline since we're undergoing good growth. We serve millions of API requests per week and we're scaling the product out further. We also don't have much in the way of technological debt going forward. Some of the recent interesting Haskell projects we've introduced to our infrastructure are:
Lazy SSL engine based on LetsEncrypt
This is a Haskell program that issues SSL certificates using LetsEncrypt by doing on-the-fly and lazy certificate issuance. This allows us to vastly simplify HTTPS for 100's of domains we serve.
API Gateway for request pipe-lining
We're a service oriented architecture. This usually entails
that most of our API requests need to be serviced by a
combination of back-end services, instead of just one. A
trivial way to solve it would be: say a request needs to be
passed to service A and then to B, then the responses from
each of these services need to be accumulated into one client
response. A can first receive the client request, do
something, and then make another request to B to do something
else. A can then accumulate the response from B along with its
own response, and reply to the client.
As one might imagine, it becomes increasingly cumbersome and
hard to debug this kind of setup. Not only do you introduce
dependencies between services A and B, coupling them tighter
than you'd like, but it gets really messy when you're going to
deal with authentication, authorisation and rapid changes in
either A or B. In the worst case, you end up with request
cycles (e.g. B makes a request to A), which are requests that
never terminate and can bring down large parts of your
infrastructure.
The other big elephant in the room is also service discovery
in a distributed environment. What makes sure that service A
can reach a healthy instance of service B?
To address this growing pain, we wrote a Haskell API Gateway service, which we lovingly call Quasar (I'm a fan of astronomical names) which flattens request pipe-lining at the API gateway level. What it does is:
We leverage Haskell's elegant abstraction over operations
like this (STM in particular) to ensure the responses are
accumulated and returned to the client.
--
These are some of the ways we're using Haskell and how it has benefited us. Going forward, given we have a fairly large codebase in Scala, we'd embark on replacing a service with its Haskell equivalent given the amount of changes required in the Scala counterpart is larger than a threshold. All new services that go into our infrastructure, however, will be written in Haskell.
So far, our staple libraries of choice are:
... and the usual suspects (Wai/Warp, Aeson, etc.)
--
Other than that, we're based in the heart of Brussels, which is a fantastic city to work in, and we will offer a competitive compensation. Free weekly Belgian beers are on us.
If this sounds interesting, please feel free to apply on the
link above (https://centralapp.workable.com/j/9AFEDD1C3C).
Or if you have any questions, please ask!
While we'd prefer colleagues based in Belgium, or
willing to relocate, we're still open to considering all
applications.
Thanks!
-- Best, Ashesh Ambasta Founder (Engineering) CentralApp SA