The PEEP Stack
Since everyone seems to love going on about the latest stackronym: LAMP, LAMAR, or the newly popular MEAN. I thought i’d take a minute to go over the stack we use at http://struct.tv
One of the major goals of Struct.tv was to handle as much traffic as possible, provide a rich end user experience, and spend as little money as possible since we don’t have any, and want to stay true to our goals of keeping the interests of our users above those of any VC firm or 3rd party.
For the job we chose Elixir as our primary language. Elixir if you are not familiar is a functional programming language created to pair a lot of the things developers love about the Ruby syntax with the massive parallelism and 0 downtime philosophies of the ErlangVM.
Coming from a Ruby background our developers were able to get up to speed on writing Elixir. It was much easier to Grok than raw Erlang, and there is a budding community forming around the development of Web Applications written in Elixir.
The choice of web framework seemed to be a default to the Phoenix framework. Phoenix today seems like a mashup of Rails MVC, in terms of the extensible router and controller structure, however we havent touched much of the view layer as our whole application is rendered client side. Phoenix does not ship with an ORM however most people use Ecto, which has a Microsoft Linq feel which admitedly I was fairly familiar with. Ecto best supports Postgres which seemed like a great option, so on we forged.
The last major issue to take care of was having some sort of asset pipeline and view layer. Being big fans of SASS and Coffeescript our options were a bit up in the air. Before we decided to do a Client side application, the options were Gulp/Grunt or manually compiling everything.
Unlike Rails, the Phoenix ecosystem is still very young, we don’t have a proper Asset Pipeline so the most logical choice seemed to be to take advantage of a more established ecosystem.
Being a long time fan and developer with EmberJS their new Ember-CLI tooling seemed like a great option for building our front end templates and assets. By constructing a simple API between our EmberJS application and Phoenix backend we’ve made another major advance in maximizing our efficiency. We basically only deal with data on our servers and leave the heavy dom construction to the client, we also get a huge win on realtime dom manipulation and data updates with Ember’s 2-way data binding.
One of the really awesome things we get for free with Phoenix is Web sockets. Web Sockets are first class citizens in the Phoenix framework, just like a controller. We use these to send real time data to our clients to create a much richer Live Streaming experience. For example, when a Streamer updates the description the change is pushed to all clients. This allows a simple mechanism for live Show Notes. We also use sockets for chat.
I’ll write more about the other parts of Struct’s tech stack later but for now I leave you with the PEEP stack.
Got a fun Ember or Phoenix project you are planning?
Hire me to help: firstname.lastname@example.org
I’ve decided to open source the work I did on creating a PEEP stack application. Its a bit dated but hopefully is helpful to someone.
Source code: https://github.com/j-mcnally/struct-tv
Thoughts, feels, hate mail about another cheesy stack acronym?
Feel free to find me on twitter @j_mcnally
Stackronym is not a registered trademark of @and1mal yet.