Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proof of concept for ActiveSupport::Notifications #61

Closed
wants to merge 7 commits into from

Conversation

hmcfletch
Copy link
Contributor

This is working towards generic Skylight integration. Been wanting to take a crack at one of the skylight integrations, figured this was a good opportunity.

This is just a first pass. Opening the PR now to get feedback.

@hmcfletch
Copy link
Contributor Author

Still needs to work in the Skylight stuff.

We could also optionally define the method based on if the instrumentation is enabled or not. Would prevent a bunch of conditional checks.

self.class_eval do
alias_method :to_json_without_instrumentation, :to_json

def to_json
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we dont have a method called to_json. I think the method we use is called serialized_json to get the JSON string representation.

I like the simple and readable approach you have taken with serializable_hash can we do the same with serialized_json?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was going off the original Skylight instrumenting, here, which did serializable_hash and to_json. It would be easy enough to change.

Copy link
Collaborator

@shishirmk shishirmk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have suggested a couple of small changes. Let me know what you think

describe FastJsonapi::ObjectSerializer do
include_context 'movie class'

context 'instrument' do
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it would be more readable if the spec were named a little elaborately. It's important to test both cases.

context 'when calling serializable_hash' do
  it 'should send a notification' do
  end
  
  it  'shouldnt send a notification' do
  end
end

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course. These tests were mostly just to make sure that I was actually getting notifications. :p

TDD FTW!!!

@wagenet
Copy link

wagenet commented Feb 7, 2018

For Skylight, you can make a normalizer. The normalizer is a class that extends Skylight::Normalizers::Normalizer. In the class you'll call the register method for each AS::N instrumentation you want to track. When the corresponding instrumentation is hit in AS::N, the normalize method is called. This takes 3 arguments: the current Skylight trace, the name of the AS::N instrumentation, and the AS::N payload. The expected response is an array of [category, title, description] which are all the same as what you would pass to Skylight.instrument. If, for some reason, you don't want to instrument that request, you can return :skip instead.

Hopefully, that all made sense. I really should write some proper documentation for this!

(Also, there will be some minor changes to class names for Skylight 2.0, as well as some new available hooks. However, existing code should basically work.)

@wagenet
Copy link

wagenet commented Feb 7, 2018

See an example normalizer here: https://github.com/skylightio/skylight-ruby/blob/v1.5.0/lib/skylight/normalizers/active_record/sql.rb. You can also find others in the normalizers directory.

@shishirmk shishirmk changed the base branch from master to dev February 9, 2018 06:21
@hmcfletch
Copy link
Contributor Author

Would probably prefer #88 over this version.

@shishirmk
Copy link
Collaborator

@hmcfletch should we close this?

@hmcfletch
Copy link
Contributor Author

yeah, this was the initial work for #88

@hmcfletch hmcfletch closed this Mar 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants