SerializationContext: request url info, content type, query params, api version, namespace, etc

[bf4]

following: #1268 (comment)

• rename options[:context] in the controller etc. to options[:serialization_context] rename context to serialization_context and add url helpers #1289
• test an example of passing in a custom serialization_context rename context to serialization_context and add url helpers #1289
• create a SerializationContext object that wraps the request and exposes original_url and query_parameters rename context to serialization_context and add url helpers #1289
• consider using the SerializationContext to expose the request media_type and api_version and url_helpers
  • ref api version: Add controller lookup. #1265 (comment)
  • ref media type: Add option to select adapter by the request header #1082
  • ref url helpers: Add supports for :links and :data options to has_many associations for jsonapi adapter #1282 Auto-include url_helpers for Rails-apps. Fixes #563 #666 rename context to serialization_context and add url helpers #1289 (comment)

[jsdir]

👍

[vasilakisfil]

Btw why context is always passed down using default Rails render? I am using JSON adapter. Not an expert but I think it's useless to JSON adapter and adds memory for no reason.

[beauby]

@vasilakisfil It does not add that much memory though, does it? If I'm not wrong it's just a reference.

[vasilakisfil]

@beauby I don't know how much memory it adds but it's a bit huge object. And not used at all (again I am using JSON adapter). I can always remove it by setting context: nil but not sure why it's added by default. Maybe have an option for that just like serializable_scope ?

[vasilakisfil]

Just looked up and I really think context shouldn't be included at all :) Why we need it? The only reason I saw was to get the query_parameters. Getting the query_parameters in order to create the pagination links shouldn't be AMS responsibility. If you have a paginated object you can retrieve the current/previous/next page/per_page and size numbers and then create the links. Unless I am missing something.

[tchak]

I d'like to work on this. Several questions:

• Are we sure about name request_context? Maybe serialization_context as mentioned in Add supports for :links and :data options to has_many associations for jsonapi adapter #1282 by symmetry with serialization_scope?
• Should we expose url helpers on this object? I find that in rails app, generating urls in serializers is pretty common. It is a "view" layer after all :) If not, what are other options?

[tchak]

@vasilakisfil for top level pagination, yes in theory you could provide links from the controller via links option, but in case of relationship level pagination, things are not that simple. You want to build links in the context of the association, it's parent and you need access to request context at the same time.

[bf4]

@tchak I'm thinking serialization_context is the superior name (disclaimer: I made the suggestion :)

Yes, it should have url helpers.

Part of the purpose of this object is to expose a defined interface for serialization_context (url_helper, request_url, query_params) without any danger of the encapsulated object(s) being used elsewhere not-as-intended. i.e. if we passed around the controller instance, we'd be inclined to use it everywhere (to the great dismay of grape users and general separation of concerns), but with an object, we are forced to decide what the serialization_context can do

[bf4]

@tchak Just start working on it. You can probably do the bare minimum in one small commit that renames the option and sets it to a SerializationContext object instead of controller.request

[tchak]

@bf4 my initial work is in #1289

[vasilakisfil]

@tchak have you or anyone else here ever worked on APIs that serve tons of resources using json-api from AMS branch 0.10 ? because then you really want to inject your own pagination. Kaminari or will_paginate work really great but if you need performance optimizations the way these do pagination is not good at all. There have been many threads about it on Kaminari about changing the way it counts the rows on SQL and get an estimation instead.

Or to take it an extra step, usually you don't even need (and you shouldn't if you want to optimize on a db with millions of rows) the last page (or total_count/total_pages in non-hypermedia api).

So 👎 from me once more.

[vasilakisfil]

hmm now that I took a look on the code, the implementation is not tight to will_paginate or kaminari so I could include my own pagination module on ActiveRecord::Relation. So it's 👍 but we could explain which methods are needed on the wiki.

[NullVoxPopuli]

@vasilakisfil when you get something implemented, if you could post your findings / maybe even a documentation PR, that would be fantastic. :-)