I've been working in Rails for almost a decade now (which was a sobering realization) and for most of that time I’ve always used gems as a selling point on why Rails is a great framework to learn. With such a rich and active community, there’s a gem for everything — authentication, e-commerce, file uploading, you name it and we got it.
Before my current position as a senior developer at Spatial Networks, I was a lead developer with a startup and the push to get code on the server ASAP was unrelenting. So gems were most often the answer just to get the site in working order.
One of my first projects I was charged with at SNI was integrating Postmark, a system for managing transactional emails, with an application under development. I was familiar with similar apps like Mailgun and figured it’d be an easy plug and play with a gem right? The gem is maintained actively by Wildbit, the creators of Postmark, so there shouldn’t be much issue with the gem decaying. Still, the director of engineering insisted we could (and should) develop the implementation without a gem.
That challenge caused a gut check in how I code and deal with gems.
The beauty of open source is that solutions are crowdsourced, so that everything you could possibly think of is probably out there as a gem. More likely than not, someone else has already had that same problem and found a solution for it.
Unlike Ruby and Rails, though, that gem was usually made by a lone coder just looking to solve a simple problem, not by a full-time team. At some point, that coder is most likely to lose interest and stop maintaining the gem. An unmaintained gem becomes a time bomb, especially if you regularly maintain your project.
There was a great article last year that went over how Kickstarter upgraded to Rails 5 and a vital step was checking to make sure that every gem still would work with the upgrade. The more you rely on gems, the more your code base is likely to be stuck in an older version or it’ll just outright stop working for you. This, of course, wasn’t the issue with Postmark and Wildbit’s coverage of it, but it is an issue I’ve come across anecdotally in the past and other seasoned coders might echo.
As anyone that’s had to work with a legacy project with a checkered history in any platform will tell you, applications have a way to run wild in scope and size if not constantly criticized for every addition of code. This works with gems as well. Sometimes they’re a module tool for fixing one problem (like with the Postmark gem) but sometimes they’re a one-size-fits-all tool (like Devise or Spree) and come with a lot of bells and whistles that you might not necessarily need or that might have issues with one another.
I once was working on an application that desired blog functionality and e-commerce functionality. The client insisted I use the Spree gem, and my supervisor suggested I use Refinery, a content management system gem. The issue came where both were not only handling their own jobs but each wanted to handle authentication, too, each building their own version of a User and each having their own backend. Trying to reconcile the two modules was a headache for a novice developer when it could have all been simplified by building my own blogging platform. I mean, it’s not like it should take longer than fifteen minutes, right?
There are a lot of moving parts in development. Anyone that expects you to learn everything from server to screen is asking far too much out of you, especially as a brand new and shiny developer.
Abstraction is important to prevent yourself from getting overwhelmed. That’s where gems become very useful. Want to make an app with authentication but don’t really have the bandwidth to learn all about it? Just install Devise! How does it work? Magic! And not just sleight-of-hand card kind of stuff, I’m talking “dark magics that are the secrets of the universe that drive you kind of mad” kind of magic. That’s how it feels when you’re starting out, at least. The longer you let it remain sorcery, the more foreboding it becomes. You begin to forget that it’s not incantations but actual code written by a fellow mortal.
With Postmark, we just really needed to make a single curl request since we didn’t need all the services. In the end, you don’t really need a gem for that kind of work.
As a follow up of demystification of your project, sometimes it’s a great learning opportunity to tackle a feature instead of relying on a gem and to code it yourself. I had relied on Devise so much that I thought that making user authentication “the old fashioned way” was going to be a Herculean task. However, I found a surprisingly simple primer that walked me through the whole process, revealing the secrets behind the magic trick and it got me excited to customize the process for my own needs, even looking forward into playing with Omniauth by hand.
I don’t want to have you walking away thinking that I want you to swear off gems now and forever. Far from it! Gems are still wonderful tools for when you need them. In my Spree/Refinery example, it was only a nightmare because I tried to use both massive gems at once. Spree, alone, would have cleared up a lot of headaches for that project. It’s more a question of when you need them versus when it’s just easier to use them.
Many Rails advocates much smarter than I encourage you to make a gem as a part of your path as a developer and it’s something I echo. Not only does it present itself as a fun coding challenge and personal milestone, it’s a little way to give back to the bigger community when you find a problem you can fix your own way. But next time you open up that gemfile, just take an introspective moment to consider the pros and cons.
Fulcrum is a data collection platform that enables businesses to reduce costs, access critical data in real time, and improve decision making at every level. With Fulcrum, you can create custom apps using our simple drag-and-drop builder to turn your paper documents into digital forms that your field teams can quickly complete on mobile devices.