-
Notifications
You must be signed in to change notification settings - Fork 1
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
Implement the ability to provide a query with no filtering #7
Conversation
Thank you for this @akhtariev. I will spend some time during the weekend on this.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for adding this @akhtariev , this is really good. I think we should get this further by having a generic Do func at the newton package level and transfer all the specifics to the query package (at that point we will rename it Request
).
That said, I'm keen to accept this as is as a first step (with some comments I added fixed) as it a good step to the right direction.
Thank you again!!
Thanks for reviewing @dhiaayachi ! Will address the comments in the next couple of days |
👋 @akhtariev, are you still interested in pursuing this PR? I can do another pass of reviews whenever it's ready. |
Hi @dhiaayachi ! Yes, I'll finish it up in the next couple of days. Sorry I've been busy lately |
No worries. Take your time and ping me when you have something ready for a review. Thank you for contributing !! |
…on only when a specific environment variable is set
Hi @dhiaayachi ! Hope your weekend is going well. I just finished addressing your comments. I ended up refactoring it ti make it look similar to In addition, I noticed that Newton now has a mock server so I switched every unit test to query that mock server. However, the mock server does not test authentication so I added another test for that that must be enabled by setting Going forward, we can automate unit tests with GitHub Actions. Also, since the mock server simply hardcodes data in response, we can make more assertions on the response in the unit tests. Just to ensure that every response has the fields we expect it to have. However, we should probably do that in separate PRs. Let me know what you think |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this great contribution @akhtariev. This is really good!! My weekend was good and you made it even better with this contribution 😃.
I made a few comments, but nothing really big, this is now really close. Can you please also gofmt the code, I'm planing on adding a linting step into the automated CI.
|
||
var r ActionsResp | ||
err = json.Unmarshal(body, &r.Actions) | ||
parsedResponse, err := n.parseResponse(res, query.GetResponse()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is for future improvements, but I think that we can make GetRepsonse
return a defined interface, that wrap map[string]interface{}
and have methods that get fields to the enduser, like GetAsString
or GetAsFloat
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created issue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to think about this a bit more. My intention is that the user don't have to cast response to the underlying type.
I think a better idea would be to make the user pass the response as a pointer and we populate it and that would be trivial. But let's do it out of this PR.
newton.go
Outdated
if toParseTo == nil { | ||
return parsedResponse, nil | ||
} | ||
|
||
body, _ := ioutil.ReadAll(res.Body) | ||
body, err := ioutil.ReadAll(res.Body) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should read the body first and then decide if we return a nil value and error if a body is returned and toParseTo
is nil
, the reason is that if the body of a request is not read properly by the client it can reset the connexion and the body is never properly freed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you elaborate on this please? I'd assume it is safe since we close response's Body in defer. Why do we need to read the body in addition to closing to ensure that it is properly freed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is a special behaviour in go http client that if you close the body without reading the buffer it will reset the underlying connexion and that could be a source of performance issues. more details in here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the explanation
@@ -0,0 +1,3 @@ | |||
#!/bin/bash | |||
|
|||
TEST_AUTH=true CLIENT_ID=$1 CLIENT_SECRET=$2 go test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is ok for the time being but I think I can make even the auth test run in automated environment, I will start a PR for this as soon as this is merged
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds great. Would be curious to see how you make it work
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some ideas, I will let you know the details if my experiment succeed 😃
@dhiaayachi Thanks for another round of review! I addressed all comments. However, the reasoning behind this one isn't exactly clear. Would you mind elaborating on that please just for me to learn |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work @akhtariev !! 🎉
I will work on the CI as soon as I can, also the small change about the Do
func signature. After that I will crank the release version to 0.10, as this is a fairly big API change.
I have a use case where I need to get all actions without any filters applied. The current design does not allow for that. As a result, for all API functions that would take queries as parameters, I refactored out a query interface that has specific implementation for each API under
query
package. This is a breaking change.gomega
module to use its matchers in unit testsnewton.go
Do
In the future, I'd like to suggest to incorporate a
ginkgo
BDD testing framework. It works well with gomega and really does simplify writing unit tests. We can also create some CI jobs to auto run unit tests that do not require Newton client and secret key.@dhiaayachi please let me know what you think