Functional Workplaces: Bluecode - Working on the Future of Mobile Payments

Bluecode is building the first European mobile payment scheme that enables cashless payments combined with value-added services.

With an easy-to-use mobile app and integrations in a vast number of applications of partner banks, merchants and various multipliers, Bluecode offers consumers a revolutionary way to pay in stores, at vending machines, in webshops and earn instant rewards via their smartphone. Users simply activate Bluecode for iOS or Android, connect their bank account in seconds and can then use the services anywhere where accepted.

It's a solution for and from Europe, accepted at 20.000 locations, from large and small department stores and supermarket chains to famous events like Oktoberfest.

The Switzerland-based company has recently raised a €20 million investment with the Hopp Family Office leading the round. Their goal is to strengthen the product offering and become the go-to provider for the European banking and commerce sectors.

You can watch, Christian Pirkner, the CEO at Bluecode pitching at the NOAH startup conference in 2018 to better understand the idea behind the company.

We recently chatted with Daniel Müller, CTO at Bluecode about their use of functional programming to develop the product and why Bluecode is a great company to consider working for.

What functional programming language are you using and what prompted you to choose it?

Our backend is currently written predominantly in Elixir (other systems are EOL’d).

Elixir sits at an interesting intersection in the programming language space. It has a low barrier to entry (the syntax is trivial to learn, and the core of the language is well structured (inspired by Clojure)), but it’s also sitting on top of a very robust VM especially for naturally highly concurrent systems (like implementing transactional communication over HTTP) which also require clear failure semantics and have to be highly available. The actor model without shared writable memory helps to keep code easy to reason about, because you can write essentially blocking code, but execute concurrently.

I know you weren't using Elixir from the got go, how did that transition happen?

Our system has gone through a few iterations, the most recent was a combination between Java and Groovy. The transition for us was done in two steps. Since the old system was monolithic, but operational requirements of our domain forced us to separate the core platform from integration adapters, we materialized that split when we rewrote the system in Elixir. So the launch was essentially done in two phases, about 6 months apart. I’m happy to say that we transitioned without major problems.

What advantages/disadvantages, or trade offs have you faced by using Elixir?

I already mentioned some of the platform advantages above. Given that it’s not quite a mainstream language, you may not always have 10 frameworks to choose from (I’m looking at you, Javascript), but just one, though I actually see that as a benefit, as it doesn’t fragment the community that much and doesn’t requires so much effort to compare the tradeoffs between the different implementations.

If I were to mention some other disadvantages we’ve seen, there are no type inference or type checking (except for Dialyzer which is slow), no data structures beyond struct, metaprogramming is at a low-level: it boils down to manipulating AST which looks nothing like a program, limited options for abstraction, limited options for limited polymorphism: protocols.

But overall I believe it’s a good choice for the type of system we’re building, and the tradeoffs work for us.

What are you using for the rest of your technology stack?

We’re using Postgres, Vue, Svelte, Typescript, AWS, Kubernetes, and Pulumi. We also are actively increasing our investment into property based testing.

What other technologies in the functional space are you excited about?

Personally I think Free (and Freer) Monads don’t get enough attention. They’re an extremely powerful abstraction, and I wish many times that people were more aware of them. Case in point: We use Pulumi to build our infrastructure as code. It’s a great tool, and has largely the same execution strategy as Terraform. Meaning that you’re constructing a resource graph, compute the diff between the new graph and the one that you have stored from the previous execution, review the diff, and then execute the diff against the cloud provider’s APIs.

This works nicely for concrete execution, but it’s really annoying if you’d like to test your code, because the graph isn’t actually available as an API. There are already two interpretations of the code, one to compute a diff and present it to the user, and the other to actually run the execution against the cloud provider. I wish that I could just plug different interpreters under the resource graph to test different resource relationships across the graph. Can two resources talk to each other given their networking? Given the current resource graph and my proposed changes, will this affect the database configuration (and if yes, require an extra manual review of the PR)?

Given two resource graphs I would also like to be capable of hooking into the execution of transforming from old to new. Current tools always assume it’s a direct relationship, but many times with infrastructure it isn’t. E.g. upgrading a cluster (DB, kubernetes, etc.) from version x to z often requires extra steps that are spelled out in the upgrade instructions. But if you’re upgrading from y to z, the instructions are different. Freer monads would give us a mechanism to swap out the interpretation of an abstract program, and thus would be tremendously helpful to implement these useful validations, and maybe hook into the computation of steps to effect the materialization of the new graph. It’s something I’d love to be able to use.

Have you seen any difference when hiring functional engineers compared to other more mainstream languages?

Elixir is also an interesting ecosystem for finding talent. Because it’s probably the most widely used, deployed, and known actor model implementation, it attracts people that are interested in that type of programming model. Given that Elixir itself has functional semantics, it attracts functional programmers naturally. But it also allows us to tap into communities like the Ruby community given the similarities in syntax and its heritage. This mixing of historically separate communities is quite fruitful in terms of libraries and idea exchange.

Besides that I find that functional programming tends to attract people that care about their craft.

And finally, since I know you’re hiring, tell us why should someone work at Bluecode?

I will mention a few bullet points of why you should consider working for us:

• Actual distributed highly concurrent system,
• Production system with real world footprint,
• As much ownership and responsibility as you can take,
• Join the conversation and influence technical decisions from Day 0,
• Freedom to pursue your ideas about how to improve the system
• Make a real impact on what we do, how we do it, and on the world outside!
• Freedom to rewrite our system in a language of your choice (in your spare time),
• Company with enormous global potential: secure your place in it while it is still small!
• Flexible working hours, 25 days of mandatory leave per year,
• Easy going team, friendly environment, great personalities, lovable CEO,
• We’re helping Africa to have their own payment system,
• Amazing office in Innsbruck: come visit the mountain trails,
• Team in Thailand: come and enjoy endless local holidays,
• Fully remote: every engineer is digital nomad,
• Books, annual conference budget,
• Dream team: work alongside legendary Bram Verburg!

If you are intrigued by all these, you should check out Bluecode’s open roles on Functional Works!