3 ms·
I also work on a Rails system. It does the job and the nice part about it is whenever I need to make tweaks I can easily dive into the code and implement said f
by SnowingXIV 8y ago
I also work on a Rails system. It does the job and the nice part about it is whenever I need to make tweaks I can easily dive into the code and implement said feature quite quickly. There are a few services I wrote that have a bit of overhead but that's my fault - these typically go untouched as they are part of the backbone. I run this system on two different instances and I will say the difference between a few thousand records and a few million records is noticeable. There isn't any memory leaks that I could detect or n + 1 queries, so I've kind of thrown my hands up. Most importantly though, it's been super reliable. I'll take the slight delay for robustness.
Recently I went the other way and built something with Flask because I felt I only needed something tiny (plus python and ruby are both friendly to read) and kept hearing the negatives about monoliths. It started out refreshing because I only added in what I needed but eventually this started to get a bit annoying as it grew, I felt I was rewriting the wheel often, and I missed the organization and forced convention of Rails. Not to mention gems seemed to have more support and often were more recently updated compared to flask imports. I now want to convert this over to a Rails application.
I think a lot goes into picking what to use, size of team, size of users being served, verasility, and development productivity. It's not always only performance at massive scale (you may never need to handle the traffic Twitter does and if you do I think you're doing pretty well and can weather that storm).