– Taking over the old remote.com site and rebuilding it from scratch

– Motivation for rewriting everything in Elixir and Phoenix

– Phoenix quickly became a go-to tool for Marcelo

– He first used it in another project to deal with 1000s of requests per minute

– It was pretty easy to get the rest of his team on-board with Elixir

– Writing a monolithic code base using single responsibility principles

– The code base’s lib/ folder has 500+ files and many thousands of lines of code

– Phoenix contexts are being used but with an added level of SRPs

– This will allow Marcelo to easily break up his code base later if needed

– The value in writing about things after having a lot of real world experience

– The Phoenix app is API based with a React front-end

– NextJS is also being used to have server rendered pages

– Letting developers pick and choose their dev style leads to increased productivity

– The front-end team doesn’t need to know about the Phoenix back-end

– There’s 3 different git repos (back-end, front-end and the new app)

– The front-end devs can get going easily due to excellent documentation

– Docker is being used in staging and production but not development

– PostgreSQL, Redis and Elasticsearch are being used and it’s hosted on AWS ECS

– Not super happy with AWS ECS and he wants to switch to Kubernetes eventually

– Gitlab is used for continuous integration and deployment

– Reasons for going with Elasticsearch (full text search and caching)

– Live View isn’t being used but he’s keeping an eye on it

– The core of what’s needed to make Live View amazing is there

– Everyone would still be using IE 5 if no one tried things out in practice

– The Elixir community is very helpful if you get stuck

– Keeping the ops side under control by using AWS for the DB, cache and ES

– After looking at Heroku, Google Cloud, Azure and others AWS looked good

– Serving 100k to a million requests per day for $4,000 a month before Phoenix

– The moment Remote switched to Phoenix the bill dropped to $500 / a month

– The entire staging environment runs with ~512 MB of memory

– The production environment runs on 2-4 instances with 2 GB of memory each

– Exq is being used to process jobs and it’s running in its own service

– 2 web servers and 1 worker is enough to serve things with a ~150ms response time

– Redis is being used to cache a few things (nothing like Rails level caching)

– Elixir / Phoenix are incredibly efficient with memory usage and releasing it

– AppSignal’s notifications help with giving a general peace of mind

– Searching and applying to jobs is free but posting jobs require a payment

– Payments are handled with Stripe using the stripity_stripe library

– Walking through a code deploy from development to staging to production

– The Docker images are being stored on Gitlab’s registry service

– Secret management is done with Gitlab’s secret management tool

– Elixir releases are created using Docker multi-stage builds

– Having small Docker images helps a lot due to their deployment strategy

– Everything is backed up and the cache can be recreated from the DB

– Mail Gun is used for transactional emails and customer.io is used too

– Sometimes you get used to a service or tool always existing

– Best tips? Be careful about over engineering and keep your eyes on the prize

– Mistakes? Not enough tests, too many tests, finding a perfect structure, etc.

– Coming to acceptance that Elixir and Phoenix has a fairly new ecosystem

– Check out the remote.com blog or follow Marcelo on Twitter @marcelo_lebre