Discussion: Don't add a database layer to your Phoenix application

A post was split to a new topic: How to do many to many relationships with Phoenix Contexts?

@OvermindDL1 this was an old thread, but your structure sounds interesting and something I’d love to take a look at.

Do you have any open-source projects / blog-posts containing this structure?

Not really anything open source, it’s mostly my stuff at my day job. It’s the general Erlang model though. Just make functionality in distinct easily testable areas then link them together.

Wow. What a delightful discussion thread. @pragdave is very convincing in his course. Unfortunately for me I have a hard time making the leap from the small sample application to a more robust application.

I would love it if @pragdave came out with a follow-up course with a more complicated application. Something where you have other concerns like authentication, authorization, and asynchronous operations (like email notifications).

I found the Phoenix generators a useful place to start and the additions of umbrellas and contexts a good guidepost on how to refactor your application in the direction of less coupled code.

In my experience you never start a system with time for creating a “perfect” architecture. You need to implement too many features in too little time. And they all need a web interface and persistent data storage. The popularity of PHP and Rails is a testament to how much more important it is that a feature works than it was built correctly.

Phoenix is a great balance of getting it working without also getting your feet stuck in concrete. My experience with Rails has been that Active Record is awesome for getting something working but fights so hard against you as the application matures.

2 Likes