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

Implement the ability to provide a query with no filtering #7

Merged
merged 29 commits into from
Nov 15, 2021
Merged

Implement the ability to provide a query with no filtering #7

merged 29 commits into from
Nov 15, 2021

Conversation

p0mvn
Copy link
Contributor

@p0mvn p0mvn commented Oct 22, 2021

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.

  • allow for no filter passed by implementing a Query interface
  • refactor to reduce code duplication
  • add gomega module to use its matchers in unit tests
  • unit test new functionality
  • all unit tests pass
  • minimize duplication in newton.go
  • unit test Do
  • implement CancelOrder (missing from API)

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

@dhiaayachi
Copy link
Owner

Thank you for this @akhtariev. I will spend some time during the weekend on this.

  • About the BDD tests give it a try and let's see how it look.
  • 👍 on the CI job for public API, I guess we can introduce a flag that filter out non public tests

Copy link
Owner

@dhiaayachi dhiaayachi left a 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!!

newton.go Outdated Show resolved Hide resolved
newton.go Outdated Show resolved Hide resolved
newton.go Outdated Show resolved Hide resolved
newton.go Outdated Show resolved Hide resolved
newton.go Outdated Show resolved Hide resolved
newton.go Outdated Show resolved Hide resolved
@p0mvn
Copy link
Contributor Author

p0mvn commented Oct 24, 2021

Thanks for reviewing @dhiaayachi ! Will address the comments in the next couple of days

@p0mvn p0mvn changed the title Implement the ability to provide a query with no filtering Draft: Implement the ability to provide a query with no filtering Oct 25, 2021
@p0mvn p0mvn marked this pull request as draft October 25, 2021 06:37
@dhiaayachi
Copy link
Owner

👋 @akhtariev, are you still interested in pursuing this PR? I can do another pass of reviews whenever it's ready.

@p0mvn
Copy link
Contributor Author

p0mvn commented Nov 12, 2021

Hi @dhiaayachi ! Yes, I'll finish it up in the next couple of days. Sorry I've been busy lately

@dhiaayachi
Copy link
Owner

No worries. Take your time and ping me when you have something ready for a review.

Thank you for contributing !!

@p0mvn
Copy link
Contributor Author

p0mvn commented Nov 14, 2021

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 httpClient Do right away. I also implemented CancelOrder endpoint.

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 TEST_AUTH environment variable. I added more info on that in the README.

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

Copy link
Owner

@dhiaayachi dhiaayachi left a 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())
Copy link
Owner

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...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Created issue

Copy link
Owner

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
Comment on lines 143 to 147
if toParseTo == nil {
return parsedResponse, nil
}

body, _ := ioutil.ReadAll(res.Body)
body, err := ioutil.ReadAll(res.Body)
Copy link
Owner

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.

Copy link
Contributor Author

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?

Copy link
Owner

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks for the explanation

query/actions.go Outdated Show resolved Hide resolved
query/actions.go Outdated Show resolved Hide resolved
export_test.go Outdated Show resolved Hide resolved
@@ -0,0 +1,3 @@
#!/bin/bash

TEST_AUTH=true CLIENT_ID=$1 CLIENT_SECRET=$2 go test
Copy link
Owner

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

Copy link
Contributor Author

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

Copy link
Owner

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 😃

@p0mvn
Copy link
Contributor Author

p0mvn commented Nov 15, 2021

@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

@p0mvn p0mvn marked this pull request as ready for review November 15, 2021 08:20
@p0mvn p0mvn changed the title Draft: Implement the ability to provide a query with no filtering Implement the ability to provide a query with no filtering Nov 15, 2021
Copy link
Owner

@dhiaayachi dhiaayachi left a 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.

@dhiaayachi dhiaayachi merged commit 24823e5 into dhiaayachi:main Nov 15, 2021
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.

3 participants