– Roughly half a million users are on the platform (~1.5k requests a minute at times)

– What Rails, Phoenix and .NET Core are being used for

– End users of the site interact with the Rails app and .NET Core is for authentication

– It’s an API back-end driven app and React / EmberJS is used on the front-end

– Motivation for using Phoenix and Elixir for the data ingesting app

– About 20 developers work on all of the different parts of the site

– Organizing the git repos for each of the apps

– The back-end code has many tens of thousands of lines of code

– TDD is something their company practices and they like it a lot

– A JS front-end makes sense for this app since the UI is live and dynamic

– Trying to visualize a live sheet music application that helps you learn notes

– Maybe Phoenix LiveView could have been used, but they prefer what they chose

– The TL;DR on GraphQL and why in this case it works better than a RESTful API

– Docker isn’t being used in dev, but Kubernetes is being used in production

– PostgreSQL, InfluxDB and Redis are used to manage the data and for caching

– They knew from the start that InfluxDB would be needed to store the time data

– Redis is being used as a cache through AWS ElastiCache

– nginx is sitting in front of the Rails application with Elastic Beanstalk

– Motivation for picking AWS over Google Cloud and other providers

– AWS Aurora is being used to manage PostgreSQL

– They are using the Rails 6.x feature to select multiple databases

– Rails is very nice when it comes to getting community driven features merged in

– Julien also really likes Phoenix and here’s how they use contexts

– File uploads are sent directly to S3 using the ex_aws Elixir library

– For Kubernetes, they are using the managed EKS service from AWS

– (2) pretty beefy boxes with 8 GB of memory power the EKS cluster (overkill)

– They are still feeling out the resource usage of their services

– (20)’ish EC2 instances power the Elastic Beanstalk set up for the Rails app

– CloudFront is being used as a CDN for book covers but not much else

– Walking us through a code deploy from development to production

– Getting rid of Jenkins is the next step but GitHub Actions is a bit insecure currently

– GitHub Actions is a great tool and it’s being used for more than just CI

– You can use GitHub Actions to run tasks periodically (separate from git pushes)

– Dealing with big database migrations with scheduled down time

– New Relic and the ELK stack take care of metrics and logging

– Sentry.io (self hosted version) is being used to track exceptions

– The time series data doesn’t end up getting logged by these tools

– Braintree is used as a payment gateway to handle credit card and PayPal payments

– Transactional emails are being sent through AWS SES

– In app notifications are coming soon to SmartMusic (websockets, etc.)

– Another use case for websockets and events will be for collaboration features

– The databases are backed up daily and S3 is very redundant in itself for user files

– VictorOps handles alerting if a service happens to go down

– New Relic is being used in a few of the applications

– Handling bot related issues with nginx’s allow / deny IP address feature

– Best tips? Make a solid proof of concept in your new tech before switching to it fully

– Biggest mistake? Trying to use your old coding habits in a different language

– Dealing with N + 1 queries with GraphQL using DataLoader

– Ecto Multi is awesome for ensuring multiple things happen successfully

– Check out Julien’s blog, @julienXX on GitHub and he’s on Source Hut