[Haskell-cafe] [Job] Senior back-end engineer at CentralApp

[Ashesh Ambasta]

Hi everyone,

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. 
<https://centralapp.workable.com/j/9AFEDD1C3C> 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:

 1. recognises the request (based on verb + path)
 2. identifies the resources being affected in this request (based on
    the query params/ JSON body)
 3. authenticates the user
 4. authorises the user for access to the identified resources
 5. performs a request based pipeline flow: which is just a traversal of
    a request-tree, where each node is an "operation" to be performed on
    an input and output. The input being the response of the previous
    operation, and the output being the response of this operation.

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:

  * Squeal
  * Servant

... 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20190123/a73da52b/attachment.html>