<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi everyone,
    <div class="moz-forward-container">
      <div class="moz-forward-container">
        <p>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 <a moz-do-not-send="true"
            href="https://centralapp.workable.com/j/9AFEDD1C3C">our job
            opening.</a> 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. <br>
        </p>
        <p>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 <i>interesting</i> Haskell
          projects we've introduced to our infrastructure are:</p>
        <p><u><font size="+1">Lazy SSL engine based on LetsEncrypt </font></u><br>
        </p>
        <p>This is a Haskell program that issues SSL certificates using
          LetsEncrypt by doing <i>on-the-fly</i> and <i>lazy</i>
          certificate issuance. This allows us to vastly simplify HTTPS
          for 100's of domains we serve.</p>
        <p><u><font size="+1">API Gateway for request pipe-lining</font></u></p>
        <p>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. <br>
        </p>
        <p>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. <br>
        </p>
        <p>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? <br>
        </p>
        <p>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:</p>
        <ol>
          <li>recognises the request (based on verb + path)</li>
          <li>identifies the resources being affected in this request
            (based on the query params/ JSON body)</li>
          <li>authenticates the user</li>
          <li>authorises the user for access to the identified resources
            <br>
          </li>
          <li>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.</li>
        </ol>
        <p>We leverage Haskell's elegant abstraction over operations
          like this (STM in particular) to ensure the responses are
          accumulated and returned to the client. <br>
        </p>
        <p>--<br>
        </p>
        <p>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.</p>
        <p>So far, our staple libraries of choice are:</p>
        <ul>
          <li>Squeal <br>
          </li>
          <li>Servant</li>
        </ul>
        <p>... and the usual suspects (Wai/Warp, Aeson, etc.)</p>
        <p>--<br>
        </p>
        <p>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.</p>
        <p>If this sounds interesting, please feel free to apply on the
          link above (<a class="moz-txt-link-freetext"
            href="https://centralapp.workable.com/j/9AFEDD1C3C"
            moz-do-not-send="true">https://centralapp.workable.com/j/9AFEDD1C3C</a>).
          Or if you have any questions, please ask! <br>
        </p>
        <p>While we'd prefer colleagues based <i>in </i>Belgium, or
          willing to relocate, we're still open to considering all
          applications. <br>
        </p>
        <p>Thanks!<br>
        </p>
        <pre class="moz-signature" cols="72">-- 
Best,

Ashesh Ambasta
Founder (Engineering) 
CentralApp SA</pre>
      </div>
    </div>
  </body>
</html>