Extra (maybe obvious) tip for #7: Get yourself a free Slack/Hipchat account and start curling those errors and exceptions to it. Super easy, way less hassle than email, and free push notifications to your phone if you've got the app installed.
Good writeup for your experience with Rails and EBS.
I've built my project, Zejoop dot com, in Java/Groovy/Grails and deployed on AWS Elastic BeanStalk - and I'm very happy with my setup so far.
As for your comment about the multitude of services available on AWS, I agree. They've recently added ACM certificate manager which simplified my maintenance considerably.
Their ACM easy implementation probably saved me at least 20 hours of cert renewal agony, plus it was free!
You're going to cry the day when you try to clone your Elastic Beanstalk environment to do a rolling upgrade, and the termination of the first wipes away your RDS db with it.
It's undocumented, but you'd be better off creating the db separately, not within the beanstalk wizard, to avoid this
Take one of your RDS daily snapshots (which you're taking of course), and recreate a new instance from it. Point your app to it, and you should be good.
Thanks for the insight into Elastic Beanstalk; I'm looking into it now.
Regarding Coffeescript and classes, I think that's a really poor reason to use it. IMO Coffeescript has had its day and if you want class sugar, just use ES6. You're already using a compilation step in your process so why not use it to work with something standard?
You're probably right indeed! I was just looking into refactoring some code, found that and thought it was pretty cool. Plus Rails comes with CoffeeScript by default.
ES6 is pretty sweet (pun intended) and will probably make CS kinda useless in the future. I'll look into it however I think that currently CoffeeScript is a bit of a standard in the Rails world.
That is a fair point, if I'm using Rails I actually just use plain old JS as I don't personally like CS.
I just found a comment by a Rails contributor [1] which says ES6 will be supported out of the box in Rails 5, which would be ideal. I can't find anything newer to back that up though. I think it might be via ES6 support baked into sprockets.
Off topic in regards to this specific blog post but if you haven't already check out mr money mustache's blog. I think his philosophy mirrors your own based on reading through the rest of your posts on creating financial freedom.
Yes, you can just use Rails as an API and create a frontend SPA. But in my opinion, it's faster to write in the 'old way' for a MVP instead of creating 2 different applications (one frontend, one backend). For the future, I'm actually thinking about rewriting the frontend using SPA technologies.
Way faster. We are using a rails API and a React+Flux app as a front end. The whole setup time alone is a considerable pain. I feel that the JS tooling is still too fragmented and sometimes messy, but I'm probably biased by years of rails and iOS development.
Writing the app takes more time since you need to write everything from the ground up (e.g.: no Devise views to just style and forget), but I really hope that in the future the investment will pay. I wrote about it a while ago (although now we are using the more terse Alt implementation): http://fancypixel.github.io/blog/2015/01/28/react-plus-flux-...
Completely agree - just setting up a workable environment for webpack is a disastrous exercise. Even things like cache-busting signatures, etc are a implement-it-yourself deal.