Day 05 - Ads [Phoenix/Elixir]


  • Application: Complete and tested with one endpoint
  • CI: Complete
  • Deployment:
    • Dev: Complete
    • Production: In-progress


We've made it one week and four applications. Our fifth was completed with the help of Matt Purdy and his Elixir skills. Matt has been working with elixir longer than I have and brought a great deal to the project. In complete honesty, we had started out with a different api topic, but after some discussion, there weren't any viable use cases for it, so we switched to an Ad Resolver.

Matt and I quickly looked at the current use cases and put together an app with two end points that seemed to fit the bill.

One problem... the data backing our current ad resolver was implemented in a view without a primary key.. This was completely new to us in a phoenix project. All the data was generated using a database Stored Procedure, so we could remove create, update and delete from our app. This also made a show endpoint irrelevant. Our app had become super small, which was perfect for this project. #reducescope

Learnings of the day:

Environment variables

In our previous Phoenix applications, we used System.get_env('SOME_VAR') and the "${SOME_VAR}" but to be honest, we didn't really understand what the difference was. Upon configuring this app, we skipped the latter and only left System.get_env('SOME_VAR') for our database configs. Since we moved relatively quickly through building the endpoints, we were onto dockerizing and deployment. Over and over we tried to configure and rebuild the docker image, but each time the app could not connect to the database. Well, it turns out the difference of the two environment variables syntax's is quite important.

System.get_env /1 pulls the system variable at compile time, or when we are building the container.

"${SOME_VAR}" loads the environment variable at run time.

These two distinctions could have saved us a lot of time debugging our docker containers.

Stay tuned for more APIs next week!