1. 7
  1.  

  2. 10

    tl,dr: “We had shitty legacy Rails code and moved it over to a new framework and refactored some things OMG <3 <3”.

    It’s not immediately obvious if they needed to actually leave Rails or just be smarter about using it.

    It’s also not immediately obvious if this approach couldn’t have been done with, say, Sinatra.

    (Phoenix is the future anyways so it’s a moot point, but still.)

    1. 5

      First you have to do Rails -> Go, do a few blog posts, then Go -> Elixir!

    2. 9

      I’ve spent several years working on complex APIs in Ruby, both from within Rails and without.

      In Rails, when an action uses respond_to, the context for the web UI and the JSON API is the same: they share the same set of instance variables used for rendering.

      That means you can’t easily change one of these instance variables for a component (eg the UI), without affecting the behavior of the other component (eg API).

      This is true only if you choose to write it this way. There is nothing stopping you from creating an API namespace and using totally separate controllers from your HTML ones.

      The way ActiveRecord serializes a model into JSON is straightforward: it dumps all the attributes. Again, this is easy, but as before, it comes with a cost: you can’t change a database column without breaking the JSON API backwards compatibility.

      Relying on #to_json for serialization is indeed a naive approach that you will soon regret; you should probably be using Jbuilder templates or ActiveModel::Serializers as in TFA.

      But this is not a good example of why you should be doing that. If your JSON representation needs to diverge from your database, simply overload #as_json and return the appropriate hash.

      TL;DR “we wrote a poorly architected Rails app and then blamed its shortcomings on the framework.”

      1. 1

        This is true only if you choose to write it this way. There is nothing stopping you from creating an API namespace and using totally separate controllers from your HTML ones.

        So we agree that the canonical Rails solution based on respond_to isn’t enough. Here’s why we created a new API namespace.

        simply overload #as_json and return the appropriate hash.

        This isn’t possible if you have two versions of the API up and running: one is deprecated and will be sunset by the end of the year, and the other is the new one described in the article

        1. 2

          It is possible, you just have to overload it only in the old api routes. It’s not too hard to do from scratch, but there are great libraries for it: https://github.com/trailblazer/representable.

          1. 1

            So we agree that the canonical Rails solution based on respond_to isn’t enough. Here’s why we created a new API namespace.

            The framework’s conventions tend to lead you down the wrong paths when your app grows to a certain level of complexity. That’s a fair criticism of Rails. The framework doesn’t prevent you from doing the right things, many of which you are doing. Serializer classes, command objects, separate API controllers, all good approaches that could also be done with Rails. You don’t need to switch frameworks to do these things.

            This isn’t possible if you have two versions of the API up and running: one is deprecated and will be sunset by the end of the year, and the other is the new one described in the article

            I was not responding directly to your use-case, which in this case calls for serializer classes, I agree. I was responding to the assertion that:

            you can’t change a database column without breaking the JSON API backwards compatibility.

            This is simply not true, even with the naive implementation of JSON serialization that Rails starts with.

        2. 3

          me skims article

          “Wait a second, isn’t the author of this article also the author of Hanami?”

          me checks

          “He sure is!”

          Maybe the title should be: “How I convinced my employer to use the framework I wrote”

          I’ve looked at Hanami and I like what I see, but I’m going to take this article with a grain of salt because there’s obvious bias.

          1. 3

            Actually, I’ve been hired after the decision was taken. The bias are obvious, but still the team had problems with that old API, even before I joined the team.