Examples & Comparison about panko_serializer

[yosiat]

Hi @oyeanuj ,

The motivation behind Panko is to achieve better performance at serializing ActiveRecord objects than ActiveModelSerializers (If you want to read how this done - feel free to read: https://github.com/yosiat/panko_serializer/wiki/Design-Choices)

Currently, Panko is 20% compatible with AMS 0.9.7 - you can create serializer, specify relationships - the simple things. the complicated things like embed :ids, root elements, etc aren't supported.

Today, I am working on making Panko more stable and doing some real load tests, once it's all finished Panko will be released officially and it will have documentation.

If you have more questions/suggestions, feel free.

[oyeanuj]

@yosiat This sounds exciting, thank you for pointing me to the writeup! I am looking forward to be able to try this, especially since I am on the abandoned AMS 0.9x train.

Maybe I'll mention the things that I liked and feel like are missing from AMS experience so that you can consider incorporating some version of them in panko:

1. In terms of usability, how AMS infers the serializer based on the model type of the entity. So render json: @posts in the controller would automatically use the PostSerializer.

2. Again in terms of usability and mental models, I like how associations automatically work within serializers, like how they work in models. Even the polymorphic ones.

Being able to say something like this below would be super cool in panko.

class UserSerializer < Panko::Serializer
  attributes :name, :age, :email

  has_many :posts,
  only: [:title, :postable]
  
  def name
    "#{object.first_name} #{object.last_name}"
  end
end

class PostSerializer < Panko::Serializer
  attributes :post_id, :title

  has_one :postable,
  polymorphic: true,
  only: [:images, :audio, text: [:body]]

end

# This example would also have ImageSerializer, AudioSerialize, TextSerializer..

#...called in MembersController
paginate json: @members

3. You've already mentioned embeds in the comment above, but again I imagine, critical for most people?

4. Finally, caching. AMS hasn't had a clear caching solution which really hurts performance when dealing with complex objects.

Thoughts?

[yosiat]

Hi!

Panko was build to be minimal so I can get it running at my workplace and get performance improvements. therefore the features you will see in panko are minimal (and there is a new feature for some specific case).

1. Inference (first and second feature) - I want to add those before the first stable release.
2. embeds aren't supported - embedding simple ids should be fairly simple to implement today.
3. Caching - as far I see it, it's performance feature - I don't see any reason to implement this because Panko deals greatly with complex objects.

I added the inference feature requests as issues and tagged them for "Stable Release" milestone - https://github.com/yosiat/panko_serializer/milestone/1

If you want, we can discuss some missing features and I'll help you implement them via PR.

[oyeanuj]

@yosiat Thank you for the reply, all of this sounds good.

On caching: I think especially since Panko already greatly improves performance, addressing caching would be super on point (whether through a PR/Readme notes/strategy/recipe). Just my $0.02.

One more thing that came to my mind that I see used: camelCasing of keys which is super useful in integrating with JS code.

Looking forward to the stable release!

[oyeanuj]

@yosiat Just wanted to get a sense of when do you see the inference features becoming a part of the library? It would help me decide if I can start migrating now or need to wait.

Excited to be able to move to Panko!

[yosiat]

@oyeanuj it was crucial for me before working on the inference to make sure panko is working correctly, safely and fast on production.

Now that I finish with the above, I plan this week to work on the inference.
Just to make sure we are talking about the same thing, instead of writing:
render json: Panko::ArraySerializer.new(posts, each_serializer: PostSerializer).to_json

you will write:
render json: posts

The only issue I see is if Panko & AMS are installed on the same project (which make sense, during a migration process, half deployment, etc) who will take precedence?

[oyeanuj]

@yosiat Yes, talking about the same thing. Additionally, if in another serializer, I write:

has_many :posts,
except: [:body]

It should ideally be able to infer that the association has PostSerializer associated and be able to include/exclude attributes?

As for precedence, do you think a configuration setting in controller or initializer would be enough? Maybe something along the lines of?

use_panko_as_serializer_for [Post, Comment]

[oyeanuj]

@yosiat It seems like the example I was talking about above might be achieved with Nested Filters but I have a couple of questions on it -

1. Can we use except, include instead of only in nested filters?
2. Is there a way to specify that nesting with a serializer as well? Or does the performance constraint dictate it to be outside?

Here is an example of what inside the serializer would look like -

class PostSerializer < Panko::Serializer
  attributes :post_id, :title

  has_one :postable,
  polymorphic: true,
  only: [:images, :audio, text: [:body]]

end

[yosiat]

@oyeanuj

• Passing inline filters to relationships is supported as of today.
• Nested Filters support only (same as to include) and except.

[oyeanuj]

@yosiat Got it, that means the a snippet like this is supported?

has_many :comments,
  only: [:id, :author_name]

Maybe this can be added to the docs as well, in the Associations page?

[yosiat]

@oyeanuj the issue is getting longer :)

let's try to close it.. the has_many example with filters should work all we need is:

• simple unit test to make sure we won't have regressions here
• docs in Associations page.

LMK if you want to make PR if not, I'll make one over the weekend.