Elixir in Production: Papercups
Tags: elixir, saas
Published: 2021-02-25 13:57:56

---
title: Elixir in Production: Papercups
published: true
date: 2021-02-23 00:00:00 UTC
tags: elixir, saas 
canonical_url: https://serokell.io/blog/elixir-in-production-papercups
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n00snmw368aeqx33sz1i.jpg
---

Elixir in Production is a series where we interview people that have used Elixir for significant projects: apps, services, startup MVPs.

Our today’s guest is Alex Reichert, the co-founder of [Papercups](https://papercups.io/), an open-source customer messaging tool.

In the interview, we talk about their open-source involvement, the benefits of Elixir for their startup, and which libraries they have found to be useful for their project.

### Could you tell us a little about your company and your role there?

Papercups is an open-source alternative to customer messaging tools like Intercom, Drift, and Crisp. Our goal is to make it easier for businesses to communicate and build relationships with their customers across various channels.

At the moment, our core product is a customizable live chat widget that people can embed on their websites, through which they can message their customers in real time. Being open-source, we also make it possible for people to host our app on their own servers. This is particularly important for companies that care a lot about data privacy.

Kam and I started Papercups for a couple of reasons. We had both felt the pain of building out messaging software at our previous companies and wanted to build something extremely developer-friendly and customizable. We also felt that companies should be able to own and have complete control over all of their customer data. So these are the problems we’re striving to solve.

![Alex Reichert](https://serokell.io/files/ma/majwcz4l.card.jpg)

### Could you talk a little about the stack of Papercups?

Papercups is built on top of an Elixir/Phoenix API, backed by a PostgreSQL database. At the moment, all of our frontend code is built with React/TypeScript. (Though I’d love to explore LiveView at some point!)

For authentication, we’re using the [Pow](https://github.com/danschultzer/pow) library. And for our workers and job processing, we use [Oban](https://github.com/sorentwo/oban).

### What are the benefits of choosing Elixir for a SaaS product like Papercups?

Since our core functionality revolves mostly around real-time communication, Elixir (and Phoenix) gave us a lot of super useful tooling right out of the box. Though we jumped into the project without any prior Elixir experience, I believe it allowed us to move a lot faster than we may have otherwise, even with a more familiar language.

I mean, we ended up managing to both teach ourselves the basics of Elixir and ship our MVP… all within ~3 weeks! And it’s not like we’re geniuses or anything. Most of the credit goes to the language, the tooling, the documentation, and the community support.

At a more technical level, Elixir also scales quite nicely for our use case. We use [Phoenix Channels](https://hexdocs.pm/phoenix/channels.html) to manage all of our chat threads, where each connection is backed by a lightweight BEAM process, working in parallel and maintaining its own state. As the [docs](https://hexdocs.pm/phoenix/channels.html) say:

> This architecture scales well; Phoenix Channels can support millions of subscribers with reasonable latency on a single box, passing hundreds of thousands of messages per second. And that capacity can be multiplied by adding more nodes to the cluster.

### Are there any libraries or frameworks that you would especially like to feature?

I’m a big fan of [Oban](https://github.com/sorentwo/oban), which we use for our background workers and asynchronous tasks.

I loved how easy it was to set up. In my experience, most job processing libraries require setting up something like Redis or MongoDB to manage everything, but Oban works with PostgreSQL right out of the box. I loved that it “just works” without requiring any additional dependencies. (This is especially nice for the people that want to self-host our product because it makes it simpler to maintain.)

### What was the biggest challenge while developing Papercups with Elixir?

Since we jumped into it without any prior knowledge or experience with Elixir, it took some time for me to wrap my head around GenServers and Phoenix Channels. It just wasn’t something I was used to. Reading Saša Jurić’s _Elixir in Action_ definitely helped me understand those concepts better. I highly recommend that book.

Setting up authentication was also a bit tricky since a lot of the examples I found online were written for server-rendered apps. But auth is always a challenge!

### Are you satisfied with the result?

Yes! I’m really proud of how everything has turned out so far. It’s been a lot of fun to work on.

### I’ve seen Papercups make a lot of effort in introducing new people to open-source Elixir with beginner-friendly issues and other assistance. How important is the connection to open-source for Papercups?

I’d love for our project to give more developers a chance to get their feet wet with Elixir. We still have some work to do to improve engagement with the open-source community, but we have a few ideas in the works that I’m excited about.

Kam and I really want to make our products more and more “hackable”, in the sense that developers can build completely customizable chat (and other messaging) products on top of our APIs. For example, we’ve had a few frontend developers reach out about building their own completely custom chat UI on top of our APIs. Some are using Svelte, others are using Flutter, and some want to use Vue. We want to support all of these use cases.

We’ve also had several backend developers reach out about building “plugins” that would allow them to do things like connecting their own NLP (natural language processing) APIs into Papercups to manage automating responses and building their own bots. This makes me really excited to see what the open-source community will come up with, which is why over the next couple months we want to invest more into our API documentation, webhook events, and other forms of customizability.

### If a person wants to contribute to Papercups, what are the steps they should take?

The easiest way to get started is to join our [public Slack workspace](https://join.slack.com/t/papercups-io/shared_invite/zt-h0c3fxmd-hZi1Zp8~D61S6GD16aMqmg) and let us know you’re interested in contributing! I’m always happy to help people find a good ticket to start with.

Otherwise, we try to regularly add “good first issues” on GitHub, which you can find [here](https://github.com/papercups-io/papercups/issues?q=label%3A%22good+first+issue%22).

### Any key takeaways that you would like to share with our audience?

For anyone interested in learning Elixir, I’d highly recommend first thinking of a project that excites you, rather than just jumping into tutorials. This was a game changer for me. I had personally spent a bit of time tinkering with Elixir tutorials, but I would either quickly become bored or find that I hadn’t really learned much in the end, since I was mostly just copy/pasting code.

By having the goal of building a prototype for Papercups, it very much helped me accomplish the secondary goal of learning Elixir. It really motivated me to figure things out for myself.

Also big thanks to the community on the [Elixir Slack](https://elixir-slackin.herokuapp.com/) workspace for helping me out whenever I had any noob questions :)

* * *

I would like to thank Alex for the interview and wish Papercups the best of luck in conquering the market: we love open-source projects like these. ❤️ They have recently launched [Papercups 2.0](https://www.producthunt.com/posts/papercups-2-0) on Product Hunt, so I’d highly suggest checking them out if you’re interested.

If you wish to read more stories like these, don’t forget to follow us on [Twitter](https://twitter.com/serokell), [Medium](https://serokell.medium.com/), or [Dev](https://dev.to/serokell).