Together with a friend I recently built Dropshare Cloud. We offer online storage for the file and screenshot sharing app Dropshare for macOS/iOS. After trying out Django for getting started (we both had some experience using Django) I decided to rewrite the codebase in Rails. My past experience developing in Rails made the process quick — and boring.
It's hard to find something that has not been done with Rails before. Awesome user management? Devise. Asynchronous job processing? Sidekiq. Creating certificates via Let's Encrypt? acme-client. This makes implementing services almost feel like playing with lego. Take this brick, grab that one, put on another one — done.
Stumbling upon strange behaviour almost never happens. The enormous user base, from startup to Fortune 500 company mean it's stable and well tested. Finding solutions for almost all exceptions that can happen is as simple as copying the error message to Google and reading the first 3 results, tops.
Building a product is not about using the latest and greatest technology. I really love Elixir and Phoenix for example, but we still chose to implement Dropshare Cloud in Ruby on Rails. The maturity of the framework and widespread use outweigh the great performance of Phoenix/Elixir for us. The challenge when creating a product is not achieving sub-ms response times, it's about getting stuff shipped. Software architecture, awesome test coverage and great performance are all nice. They are also worthless if your idea doesn't stick.
Reducing the cycle time is king. As a small company we can only win in the market if we move faster than the competition. Implementing ideas like free SSL certificates in just 2 evenings is just what sets a small company apart from bigger competitors. We don't have a sprint planning, requirements engineering or UX reviews (we really should have those, though :D) — we decide to build something and just do it. Having a reliable framework back all those ideas and make it easy is what is key.
Benchmarking one server serving our Rails front page leads to ~50 RPS. "That’s so slow" I hear you say. And yes, it is. But: No one cares. If we had 50 requests per second for any time other than me testing we would spend enough money on this issue to just make it go away (scaling out is possible for us in the current situation). 50 requests/second means 3,000 requests/minute, 180,000 requests/hour or ~4.3 million hits per day. Even with mediocre conversion rates a few of those people would hopefully subscribe to our service and start paying money that could immediately be thrown at more hardware or motivate us to implement a caching strategy, rewrite parts of the service or maybe just optimize the database queries.