-
Notifications
You must be signed in to change notification settings - Fork 298
feat(per-js-sdk): Add support for bid state and raw bid submission #1329
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
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 2 Ignored Deployments
|
throw new Error(`Invalid private key: ${argv.privateKey}`); | ||
} | ||
const DAY_IN_SECONDS = 60 * 60 * 24; | ||
client.setBidStatusHandler(async (bidStatus) => { |
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 define these things within a simple searcher class, just makes it easier to find and read then an inline function
if (this.websocketBidStatusCallback !== undefined) { | ||
await this.websocketBidStatusCallback(message); | ||
} | ||
} else if ("id" in message && message.id) { |
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.
can you add some comments here for what this path is supposed to be?
express_relay/sdk/js/src/index.ts
Outdated
}); | ||
} | ||
|
||
async submitOpportunityBidViaWebsocket(bid: OpportunityBid): Promise<BidId> { |
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 there's probably better clearer naming here, but that probably depends on us developing clearer terminology for these different parts of the server. rn the terms OpportunityBid vs Bid are not very clear at first inspection, maybe something like submitLiquidationAdapterBid vs. submitBid?
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 agree that our terminology is a bit confusing but not sure about your suggestion. the term adapter
has never been exposed in the api so I think it makes it more confusing here. I guess I have made a decision early on the summarise the LiquidationOpportunity term by dropping the liquidation part. LiquidationOpportunityBid is more verbose but also a bit long. I'm open to suggestions but terminology changes should be consistent across different docs and services.
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 this depends on what we call the LiquidationAdapter server to differentiate it from the auction server. maybe we ought to refine that naming distinction, and that will make it clearer: for example, naming it "Liquidation Forum"?
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.
exposing the viaWebsocket
to users seems like it's exposing an implementation detail of how this works. There's a functional difference between this and the post method below though, which is that you get updates on the bid if you use websocket.
I think a better way to expose this functionality would be to have one method like submitOpportunityBid
that has a default parameter like subscribeToUpdates = true
, and then switches between websocket and post depending on that.
express_relay/sdk/js/src/index.ts
Outdated
/** | ||
* Represents a raw bid on acquiring a permission key | ||
*/ | ||
export type Bid = { |
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 type is in the generated types. we should use that and maybe perform some validation atop that
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 not quite the same type unfortunately. there is a snake_case
-> camelCase
conversion and I chose types that made more sense in a js sdk instead of the general openapi types. I'm not sure if there is an easy way to apply these changes on top of the openapi type.
bid: OpportunityBid | ||
): components["schemas"]["OpportunityBid"] { | ||
return { | ||
amount: bid.bid.amount.toString(), |
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.
does the type generation have a way to auto convert to json format? or do like json.stringify or something? then you don't have to rewrite this whenever the type changes in versions
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.
They just suggest using snake_case everywhere but it's a bit too late for that. I guess anything magical here would remove the current type safety checks we have. Do you have anything in mind?
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.
nit: I think if the type is identical to server type you can consider using https://quicktype.io/ to generate types with conversion based on the JSON Schema of the API.
express_relay/sdk/js/src/index.ts
Outdated
} | ||
|
||
async submitBidViaWebsocket(bid: Bid): Promise<BidId> { | ||
const result = await this.sendWebsocketMessage({ |
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.
nit nit: i think sendWebsocketMessage
can be renamed to something that indicates there is a response but I can't think of a good name myself.
bid: OpportunityBid | ||
): components["schemas"]["OpportunityBid"] { | ||
return { | ||
amount: bid.bid.amount.toString(), |
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.
nit: I think if the type is identical to server type you can consider using https://quicktype.io/ to generate types with conversion based on the JSON Schema of the API.
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.
Nice!
I left some minor inline comments.
Looking at the sdk I also have a mixed feeling about having two ways of doing things. This can also appear confusing to people (and the trade-offs are not very clear). Do we still need to maintain HTTP apis. If so, I recommend documenting the trade-offs.
this.client.setBidStatusHandler(this.bidStatusHandler.bind(this)); | ||
this.client.setOpportunityHandler(this.opportunityHandler.bind(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.
I still think that this is not a non-intutive API and recommend moving it to the constructor of Client.
} | ||
|
||
async bidStatusHandler(bidStatus: BidStatusUpdate) { | ||
console.log(`Bid status for bid ${bidStatus.id}: ${bidStatus.status}`); |
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.
log the result when the status is submitted
express_relay/sdk/js/src/index.ts
Outdated
*/ | ||
export type TokenQty = { | ||
contract: Address; | ||
export type TokenAmount = { |
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.
let's move these types into a different file
express_relay/sdk/js/src/index.ts
Outdated
* All the parameters necessary to represent a liquidation opportunity | ||
* All the parameters necessary to represent an opportunity | ||
*/ | ||
export type Opportunity = { |
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.
make a separate OpportunityParams
struct for supporting surfacing opportunities
} | ||
|
||
async opportunityHandler(opportunity: Opportunity) { | ||
const bid = BigInt(argv.bid); |
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 doesn't need to be a cl arg, it's just a constant for the purposes of illustration in this script
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 was useful internally as a dummy test to make sure auction server ignores lower bids. I'd run two scripts with different bid params and see who wins. I removed it from the docs, but will leave it here since there is some default value and it will not complicate the users testing flow.
No description provided.