Question About the Use Cases

[berniechiu]

I have a question about a use case in this example
https://github.com/khiav223577/case_register#isolate-methods

class User < ApplicationRecord
  def money_info
    { value: money, rate: gain_money_rate }
  end

  def notification_info
    { msg_count: new_msgs_count, last_recieved_at: last_recieved_at }
  end
end

class UserController
  METHOD_WHITE_LIST = [:money_info, :notification_info]
 
  def refresh
    result = params[:needs].slice(METHOD_WHITE_LIST).index_with{|method| current_user.send(method)  }
    render json: result 
  end
end

Wouldn't it be more generic to have separated API to handle those cases since they actually have completely different responses 🤔, and might not need any switch case after all

Something like

class RefreshController 
  def money_info
    ...
  end

  def notification_info
    ...
  end
end

[khiav223577]

It would be more suitable to have one API to have one responsibility in general, though some may want to combine APIs and fetch data with a single API call for the sake of performance. GraphQL is good at doing this, while in RESTful API, you may end up find that you have to use many switch-cases or if-statements to deal with this kind of requirement.

This use case may be uncommon in real life. It would be nice if we can add more common use cases to improve the documentation. Any ideas?

[berniechiu]

Since modern usage for people uses serializers to format different/complicated APIs (of course GraphQL already solve this problem 🥺), but we don't want to create so many serializers which can be hard to manage, I think can be a good use case for API?

https://github.com/jsonapi-serializer/jsonapi-serializer

class UserSerializer
  include JSONAPI::Serializer
  include CaseRegister

  register_case(:money_info) do |object|
    attribute :value { object.money }
    attribute :rate { object.gain_money_rate }
  end

  register_case(:notification_info) do |object|
    attribute :msg_count { object.new_msgs_count }
    attribute :last_recieved_at { object.last_recieved_at }
  end
  ...
  ...
end

# Example
render json: UserSerializer.new(@user).invoke_case(:money_info)
# Or
render json: UserSerializer.new(@user, options: { invoke_case: params[:need] })

I don't think we could do it this way, this is just a popup idea

Not sure if this is a good use case lol, but just a thought 😆

[khiav223577]

jsonapi-serializer has already had some built-in ways to select fieldsets, such as passing fields options or use conditional attributes. You don't have to use case_register, but it is possible to use case_register in the serializers.
Possible usage may be:

class UserSerializer
  include JSONAPI::Serializer
  include CaseRegister

  attribute :money 
  attribute :gain_money_rate
  attribute :new_msgs_count
  attribute :last_received_at

  register_case('money_info') do 
    fields = @fieldsets[self.class.record_type.to_sym] ||= []
    fields << :money
    fields << :gain_money_rate
  end

  register_case('notification_info') do 
    fields = @fieldsets[self.class.record_type.to_sym] ||= []
    fields << :new_msgs_count
    fields << :last_received_at
  end
end

class UsersController < ApplicationController
  def show
    serializer = UserSerializer.new(@user)
    params[:needs].each{|need| serializer.invoke_case(need) }
    render json: serializer.serializable_hash
  end
end

I can not tell whether it is a good design pattern or not since I do not use jsonapi-serializer in any of my projects. It may need more discussion before this example being added into the documentation. All thoughts are welcome :)