I use the same architecture... DRF for the API, admin for quick data manipulation, Ember for the interface and I enjoy it immensely. I am learning Phoenix because it would allow me to handle bidirectional communication in the same codebase along with other Erlang advantages. So far it doesn't seem to have anything comparable to DRF.
> I'm curious why JS is picking up so much for backend development?
The reason I reach for Node on a project is to handle my websockets. I use Django REST Framework + Ember as my main tools (super fast to build with) but, based on my testing, Python can't hold a candle to Node when working with thousands of websockets. It works great for what it was designed for.
Have you tried using Tornado/Twisted for the websockets? I'm curious about performance.
I'm building a side project right now and I'm using Django running inside Tornado (it's pretty simple to setup, really) so I can both have my cake and eat it (easy APIs, and a layer I can use to maintain websockets.) I wonder if the performance would be comparable to Node?
I tried every variation I could get to work including tornado, asyncio, and pypy. In my simple "how many websockets can I open" tests python would start erroring by 10,000 (no Django, just an empty websocket) while node hit 40,000 and was still climbing. Eventually I concluded it was a case of "with sufficient thrust pigs fly just fine". I still like python; just doesn't seem to be worth the effort to try to adapt blocking libraries into a non-blocking use case.
That makes sense. I'm actually very pragmatic when it comes to this kind of stack and I'll be happy to replace my current Tornado frontend with a Node frontend when I hit the limit (for now it's a very niche usecase, just me and a few friends, so it might be that I never need to improve it.)
I use/have contributed to this project: https://github.com/hendrix/hendrix which is a wsgi wrapper that uses twisted to serve django apps. Websockets are among the first things you get out of it.
I ended up with my primary tools being DRF + React/Redux. I'm genuinely curious about Ember, but haven't had a chance to play with it. What do you think of it? How's it stack up versus React-based frontend setups, if you've evaluated them?
For new SPAs Ember rocks. Also keeping up with the latest and greatest Ember is a breeze. I would not however like to refactor an existing front end application to use Ember. Probably React is better suited for integration with existing front end applications.
Although Ember really feels like idiomatic Javascript to me and they try hard to adhere to new web standards (e.g. web components, ES6 modules) it is also very opinionated about what should go where and how.
I primarily use Django REST Framework for APIs... has anyone moved from Django to Phoenix and can give a report on how the developer productivity compares currently? If it's not there yet I'm sure it will get there as the community grows but how is it now?
Phoenix is more like Flask in that regard and definitely doesn't come batteries included like Django (no auth, no admin, no cache backends etc) so it would be more work to build something as full-featured as DRF on top of it.
Having said that, I've found it easy to get along with retuning JSON and the actual speed of responses is incredible. Completely anecdotal and unscientific but one service I recently converted from DRF to Phoenix saw drops in avg response time of 350ms to about 15ms.
If you are doing REST apis and are interested in Elixir I'd recommend checking out Trot (https://github.com/hexedpackets/trot). If is a lightweight wrapper around Plug (Exilir's middleware framework) and Cowboy (Elixir's native http server).
Not surprising. That was the same case with John Paul Larkin whose stage name Scatman John[1] probably rings a few bells. Although his style of singing lent itself well to (ab)use of stuttering. Very curious how that works, though.
One option: get a part time job in an interesting industry.
I discovered this by getting a contract (few days a month) doing onsite work for a small/medium size organization. I asked lots of questions about things that I perceived as broken and found out what processes and software they hated. Then I worked on a prototype (evenings, for fun) and showed it to them. Now a year or so later that organization is my first customer for a SaaS I saw that they needed.
Also, make friends with other vendors while you're there. A company that already serves that industry can give valuable feedback and even market your app to their other clients if it integrates well with their solution.
Real-time asset tracking (GPS) with a non-terrible user interface. I'll get a good marketing page done someday; currently it's spreading via a vendor I made friends with (see above).
I've also found the convention over configuration feature to help when I'm a lone developer working multiple projects. I often work on something (perhaps a side project) and then abandon it for a couple months. When I return I just run `ember serve` and dive in. In the past with my homegrown or invent-your-own-structure frameworks I first had to figure out what I had done on this particular project before I could be productive.
