There are a lot of options for Rails serialization these days. However, depending on your needs, you may find, in the end, that your viable options are pretty slim.
You could go with the out-of-the-box standard, jbuilder. But it can be pretty slow. You could go with the popular Active Model Serializers, but it's current development status is less than ideal. Plus, it can also be slow and and don't count on caching to rescue you.
You might decide to turn to Netflix's Fast JSON API, which is not a bad idea at all. But you'll have to conform to the JSON:API specification, which might be a major breaking change for your frontend and/or your API consumers. I know the frontend teams I worked with weren't too happy about the prospect of switching to JSON:API when I floated the idea to them. And for good reason! That sort of thing can be a lot of work for relatively little benefit. And if it's a hassle for your own team members, imagine your unhappy API-consuming customers.
One of the things that made me fall in love with Ruby and Rails is the fact that if you're thinking to yourself "there's got to be an easier way to do this", there probably is. The Ruby community does a great job of fulfilling the lazyness virtue. If something seems hard to do, chances are some pioneering Rubyist has already done it and open sourced it. Between RubyGems, GitHub and StackOverflow, we've got a great toolbox to pull from.
One of the problems I still haven't found a great tool for is transforming complex hashes. I'm not sure if I'm not Googling the right thing, not looking in the right places, or just not thinking outside the box enough but every time I have to transform a hash, it comes out looking kludgy. But still, some code is better than others. Let's take a look at a method I wrote recently.
Rack middleware is one of those things that's actually very simple. We'll see how we can implement the basic concept in just a few lines of code. But because of sparse documentation and an unclear API, getting started with Rack middleware is a confusing endeavor for anyone new to the concept.
But fear not. We're going to boil all the core concepts of the Rack middleware stack into an easy to run and understand code example. Along the way, we'll get some insight into what's going on under the hood.
My experience with debugging code has come a long way. Many of you probably share in my painful memories of throwing echo lines into one PHP file after another. Ah, those were the bad old days.
Thankfully, we rarely ever have to resort to that in Ruby. But Ruby does have its own aspects that make debugging tricky. One of the hardest things for a new rubyist to deal with is when the problems go beyond the comfort of your own hand-written code and into the endless abyss of third-party gems. Once you've crawled your way up the stack trace and hit lib/active_support/how/many/directories/are/there/in/this/gem.rb, many throw their hands up and head to Stack Overflow. But don't click that Ask Question button just yet. Exploring other people's code (especially good code) is one of the most rewarding things you can do as a programmer and as a member of the open source community. So let's get our hands dirty and maybe learn a little something along the way.
Like many web developers, I got my start programming on the web with PHP. When you're working with PHP it's obvious how to start from scratch on a simple web app. Get out a .php file, two cups of HTML, a pinch of <?php ?> tags. Throw it in the oven and you're done.
With Ruby, things aren't so obvious. Virtually every Rubyist gets his or her start with a framework. You go along happily pecking out one line of code after another, never understanding what lies beneath the surface.
A few years ago when I was working for a university and we were rolling out CAS authentication for our apps. I headed to the internet to read up on anything I could find about CAS. Unfortunately, what I did find was a jumbled and overly complex mess of documentation. So, for the sake of those who will come after me, I'm going to do my best to explain, in as simple terms as possible, how CAS client authentication works. I'm assuming you have at least a basic understanding of HTTP requests, responses and cookies.
As I write this, I'm sitting at home in the dark. Sweat beads forming on my forehead as the 90° weather outside suddenly discovers there's no air conditioning to keep it at bay. Yes, I am the victim of a power outage. An all too present reminder that downtime happens.
Downtime is an unfortunate reality of working in IT. Whether it's planned or not, even the likes of Amazon and Google can't be up 100% of the time and neither can you.