5 ms·

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 develop

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?

rajaravivarma_r 2y ago
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.
- thiago_fm 2y ago
  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?
  - byroot 2y ago
    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.
xcskier56 2y ago
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
- izietto 2y ago
  This one? https://github.com/vigetlabs/olive_branch https://github.com/vigetlabs/olive_branch Looks interesting, unfortunately its latest update is from 3 years ago
  - sensanaty 2y 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/olive_branch/middleware.rb https://github.com/vigetlabs/olive_branch/blob/main/lib/oliv...
  - werdnapk 2y ago
    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.
    - izietto 2y ago
      This is my concern: https://github.com/vigetlabs/olive_branch/blob/8bd792610945ff3dc7b379a0aa7e039aa79a4e94/.travis.yml#L3-L16 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.
      - werdnapk 2y ago
        Ok, updates regarding dependencies is definitely a good point.
revskill 2y ago
Me too. And even crystal language has the same issue.
SkyPuncher 2y ago
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.
- caseyohara 2y ago
  > 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 https://en.wikipedia.org/wiki/Convention_over_configuration Without it, you don’t have Rails.
  - SkyPuncher 2y ago
    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.
    - sethherr 2y ago
      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.
  - gregors 2y ago
    This skit on rails conventions is ancient, but I will never think it's not hilarious https://www.youtube.com/watch?v=obOd7WrrTWQ 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.
ysavir 2y ago
> 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.
BurningFrog 2y ago
Sounds like something you could fix once and for all with some metaprogramming converting between the two case cases?
deleted 2y ago
[deleted]

rajaravivarma_r 2y ago

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.

thiago_fm 2y ago
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?
- byroot 2y ago
  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.

xcskier56 2y ago

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

izietto 2y ago
This one? https://github.com/vigetlabs/olive_branch https://github.com/vigetlabs/olive_branch Looks interesting, unfortunately its latest update is from 3 years ago
- sensanaty 2y 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/olive_branch/middleware.rb https://github.com/vigetlabs/olive_branch/blob/main/lib/oliv...
- werdnapk 2y ago
  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.
  - izietto 2y ago
    This is my concern: https://github.com/vigetlabs/olive_branch/blob/8bd792610945ff3dc7b379a0aa7e039aa79a4e94/.travis.yml#L3-L16 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.
    - werdnapk 2y ago
      Ok, updates regarding dependencies is definitely a good point.

revskill 2y ago

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

SkyPuncher 2y ago

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.

caseyohara 2y ago
> 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 https://en.wikipedia.org/wiki/Convention_over_configuration Without it, you don’t have Rails.
- SkyPuncher 2y ago
  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.
  - sethherr 2y ago
    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.
- gregors 2y ago
  This skit on rails conventions is ancient, but I will never think it's not hilarious https://www.youtube.com/watch?v=obOd7WrrTWQ 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.

ysavir 2y ago

> 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.

BurningFrog 2y ago

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

deleted 2y ago

[deleted]