Interface to render

[kenn]

I like the concept, but here's one thing that gives me a pause.

render json: MyObjectSerializer.new(my_object).serializable_hash

I know where you're coming from, but comparing that with the vanilla Rails way:

render json: my_object

The current API looks overwhelming.

I usually abstract out render json: with render_ok and render_error to sprinkle metadata on it, and for that, it should work type-free.

def render_ok(hash={})
  render json: { status: 'ok' }.merge(hash)
end

# render_ok user: @user   # => { status: 'ok', user: { ...} }
# render_ok users: @users # => { status: 'ok', users: [ ... ] }

def render_error(status, message = nil)
  render json: { status: status, message: message || status }, status: status
end

# render_error :bad_request, 'invalid param' # => { status: 'bad_request', message: 'invalid param' }

If simple_serializer just overrides as_json, my code will work just fine. Otherwise, I can't see how I can keep this simplicity.

In other words, how can we add common structures to the JSON without adding a log of complexity?

[wmakley]

Yes, SimpleSerializer implements #as_json and #to_json. The example is more verbose than it needs to be.

I will not be implementing automatic serialization (inference of Serializer class) for render json: @user, because it was the source of half of my problems with active_model_serializers. KISS.

Since there is already a gem named simple_serializer that does more or less the same thing, I'm working on a new name and differentiating my library in some clear way before I push to rubygems, and I will update the example.

[wmakley]

Also, does that answer your question?

The verbosity becomes a major plus in a bigger codebase. It is critical to know for sure if it is using the correct serializer class, and verbosity speeds up understanding of the code rather than hiding the serializing fields in some magic somewhere.

[kenn]

Then it doesn't solve my problem. It's like typed vs duck-typed discussion, and I respect your opinion. I see problems with active_model_serializers in other areas (complexity, version gotchas), but the inference of Serializer class has been the best part. Thanks for your explanation.

[wmakley]

Well, there are things I'm perfectly happy to duck type, but complex rendering behavior not so much. My issue with AMS was I could never be sure if it was using the Serializer classes. Sometimes it would, but if it didn't there wouldn't be an error, I'd just get totally unexpected JSON, and its behavior with nested collections and relations was often totally unexpected to me. I would preload my data and it would still trigger N+1 queries, or not use the correct serializer. The point of this gem is completely deterministic control.

I'd really recommend fast_jsonapi, or jsonapi-rb over my gem. I just created this thing so I could ditch the horrific AMS memory leaks and over-engineered (under-engineered? its programmatic interface is just confusing) complexity, but I would use those or graphql if I were starting from scratch, and still intend to for new API endpoints.

[kenn]

Yeah I just looked into fast_jsonapi, it looks great. Thank you!