Saturday, June 7, 2014

From Drupal to Rails

That fling with Drupal didn't last too long. I had hoped to do more with Drupal, but as I got to know it more and more (I addressed a few bugs we had), it became apparent that Drupal is a really good CMS. Since we are not centered around content, it didn't make sense to have a CMS there. Let's take a look at a few things wrong with Drupal.

The way Drupal was designed, it has horrible performance, but covers over it all with a lot of caching. This was really painful for me since I had to wait 10 seconds for my changes to render since I was constantly clearing the cache. I probably didn't need to clear all of the cache, but I didn't want to spend the time to figure out which caches I needed to clear. The main problem here is that we won't be able to cache much. (Or we will have a lot of cache invalidations flying all over the place.) We are expecting our content to constantly change.

No foreign keys. I had just come from a shop that doesn't use foreign keys, but the naming convention made it obvious which columns where referring to others. All foreign keys must have the same column name as the primary key. Drupal also has this convention, but the primary key column names are all three letters long, two of which are "id". So Node table has key "nid". That's cool if I only had 26 tables being referred to, but sadly there were 3 tables that could be the target of "aid", and I had no idea.

Drupal is very modular. With the modularity comes a lot of redirection. I know the hot thing for the past decade has been IoC, DI, interfaces, and all that stuff. That makes it hard for me and my IDE to follow what's going on. Things just happen automagically, and it hurts someone new like me.

Also along the lines of modularity, Drupal makes it sort of easy to assemble different pieces together. This is cool, but that means I had a lot of extra code that I wasn't using because we're just using one facet of many pieces to make things work. Free stuff can't be bad, right? But now there's more indirection, more tables filling up my object explorer, more possible security holes, and more options to possibly screw me over next time.

These reasons make it hard for me to work with Drupal. Nothing wrong with Drupal. We were just using it for the wrong purpose. So now we're moving to a lower level framework which will be fighting with me less.

So we were going to choose a new framework. Since I'm here to write an awesome app, not reinvent plumbing, I decided to go for one of the bigger ecosystems where every problem I will run into has already been solved. That leaves ASP.NET (the sharpest knife in my block), Java (open source alternative), RoR, or Django. Django and RoR are similar, so I chose the bigger ecosystem with RoR. I was kind of sad since I like Python a lot better than Ruby. ASP.NET and Java are fabled to more enterprise centric, so I landed with RoR, where the startup community is much more vibrant.

On my next post, I will go into why this was such a difficult decision for me. Mainly because the only reason I chose RoR is because of the community, while disagreeing with every other reason the community have for choosing RoR.

No comments:

Post a Comment