11–20 of 57 posts
However, I am not too convinced about having a context for each resource. I think that should be optional, meaning that I should be able to specify a context for some related resources but at the same time, I should be able to have resources outside of any context.
Do you find it's a lot of extra writing for the contexts? I'm new to Phoenix and my first thought is it seemed kind of verbose to define every single 'meeting point' across 'models'. For simple apps it seems OK but I have some complicated apps with many models and interactions
I've wanted to use Phoenix a few times but every tutorial to get me started relied 100% on ecto which for something like a transformation API was frustrating. I didn't want the complexity of a database I wanted to learn the request lifecycle in it. Overall, it was challenging with too many resources being out of date or just so focused on a different type of API than I needed to build
[0] http://shankardevy.github.io/code/elixir-phoenix-conn-reques...
I can't wait until May[0] for the new 'Programming Phoenix' book. I found the first edition to be a great learning experience. [0] http://shop.oreilly.com/product/9781680502268.do
Best part for me is the new fallback controller plug. Really well done. That and the centralized error list. This is one of the things which is miss in Go (I think this is the same in Rust, but I am not an expert).
action_fallback seems like a great addition. It is helpful to expose all your error codes in a single place. However, I am not too convinced about having a context for each resource. I think that should be optional, meaning that I should be able to specify a context for some related resources but at the same time, I should be able to have resources outside of any context.