Hacker News new | ask | show | jobs
by rajaravivarma_r 549 days 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.

1 comments

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.