Hacker News Reader

Comment by izietto | Hacker News Reader

First, if the author is going to read this, let me thank you for your work. As a Rails developer, I find the premises very relatable.

Again, as a Rails developer, a pain point is different naming conventions regarding Ruby hash keys versus JS/JSON object keys. JavaScript/JSON typically uses camelCase, while Ruby uses snake_case. This forces me to perform tedious and often disliked transformations between these conventions in my Rails projects, requiring remapping for every JSON object. This process is both annoying and potentially performance-intensive. What alternative approaches exist, and are there ways to improve the performance of these transformations?

View on HN

I don't have a solution for the performance problem. But for the camelCase to snake_case conversion, I can see potential solutions.

1. If you are using axios or other fetch based library, then you can use an interceptor that converts the camelCase JavaScript objects to 'snake_case' for request and vice versa for response.

2. If you want to control that on the app side, then you can use a helper method in ApplicationController, say `json_params`, that returns the JSON object with snake_case keys. Similarly wrap the `render json: json_object` into a helper method like `render_camel_case_json_response` and use that in all the controllers. You can write a custom Rubocop to make this behaviour consistent.

3. Handle the case transformation in a Rack middleware. This way you don't have to enforce developers to use those helper methods.

I believe his point is that this transformation could be done maybe in C and therefore have better performance, it could be a flag to the JSON conversion.

I find the idea good, maybe it even already exists?

It could be done relatively efficiently in C indeed, but it would be yet another option, imposing et another conditional, and as I mention in the post (and will keep hammering in the followups) conditions is something you want to avoid for performance.

IMO that's the sort of conversion that would be better handled by the "presentation" layer (as in ActiveModel::Serializers and al).

In these gems you usually define something like:

    class UserSerializer < AMS::Serializer
      attributes :first_name, :email
    end

It wouldn't be hard for these libraries to apply a transformation on the attribute name at almost zero cost.

> Again, as a Rails developer, a pain point is different naming conventions regarding Ruby hash keys versus JS/JSON object keys. JavaScript/JSON typically uses camelCase, while Ruby uses snake_case.

Most APIs I've come across use snake_case for their keys in JSON requests and responses. I rarely come across camelCase in JSON keys. So I'm happy to just write snake_case keys and let my backend stay simple and easy, and let the API consumer handle any transformations.

I use the same approach another comment points out, using Axios transformers to convert back and forth as necessary.

I love Rails, but if I could go back in time and tell them to avoid one thing it would be their strict adherence to naming conventions.

I've spent more time in my career debugging the magic than I would have by simply defining explicit references.

> if I could go back in time and tell them to avoid one thing it would be their strict adherence to naming conventions

Monkey paw curls. Rails probably wouldn’t have reached popularity were it not for the strict adherence to naming conventions. The Rails value prop is productivity and the ethos of “convention over configuration” is what makes that possible.

“Convention over configuration” was coined by DHH himself. https://en.wikipedia.org/wiki/Convention_over_configuration Without it, you don’t have Rails.

The problem is the convention is not always clear or consistent. When it breaks, it can be very difficult to debug.

In most cases, we're talking about trivial amount of extra code. Things like a handful of config lines at the top of a class.

To each their own, but “a handful of config lines at the top of every file” sounds like misery to me.

I guess I’ve just drunk the koolaid - but also, there has been a lot of work to make things more predictable, e.g. zeitwerk.

This skit on rails conventions is ancient, but I will never think it's not hilarious

https://www.youtube.com/watch?v=obOd7WrrTWQ

There's been arguments over the years that push back to rails magic led to a new generation of explicitness. You're also correct in saying that it's part of the value prop for productivity. But there's an overhead to learning the conventions in the first place and these days there is no denying less and less people are coming to Rails and even less learning Ruby. That's just the lifecycle of software I suppose. I'm extremely grateful for the large companies with massive ruby codebases that continue to move the language and ecosystem forward.

I'm ok with most of the naming conventions, but the pluralization is one I loathe. The necessity of custom inflections should have been a strong smell, IMO.

Semantically it makes sense. It's not Rails' fault the English language is a terrible serialisation format.

But it can be Rails' fault for choosing to default to a terrible serialisation format.

What would you propose as an alternative?

Singular table names?

Esperanto.

I agree. I think it also would have been better to explicitly name "collections" as unique from "items".

GooseCollection is more meaningful than Geese (or Gooses).

Sounds like something you could fix once and for all with some metaprogramming converting between the two case cases?

We use a gem called olive branch. Yes it’s going to give you a performance hit, but it keeps you sane which is very worthwhile

This one? https://github.com/vigetlabs/olive_branch Looks interesting, unfortunately its latest update is from 3 years ago

If you look at the source [1], you'll see what it's doing is very simple (the file I linked is basically the whole library, everything else is Gem-specific things and tests). You can even skip the gem and implement it yourself, not a big dependency at all, so no need for constant maintenance in this case :p

[1] https://github.com/vigetlabs/olive_branch/blob/main/lib/oliv...

I don't understand the issue with it not being updated for 3 years. Perhaps it's stable and requires no updates?

If the author says it's no longer maintained, then that's something different.

This is my concern: https://github.com/vigetlabs/olive_branch/blob/8bd792610945f...

No guarantee it's going to work with Ruby > 2.7 || Rails > 6.1.

When I upgrade components I want to know other components are not going to break anything.

Ok, updates regarding dependencies is definitely a good point.

Me too. And even crystal language has the same issue.

Reply on news.ycombinator.com