Skip to content

Conversation

m30m
Copy link
Contributor

@m30m m30m commented Feb 29, 2024

No description provided.

Copy link

vercel bot commented Feb 29, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

2 Ignored Deployments
Name Status Preview Comments Updated (UTC)
example-oracle-amm ⬜️ Ignored (Inspect) Visit Preview Mar 14, 2024 7:08pm
xc-admin-frontend ⬜️ Ignored (Inspect) Visit Preview Mar 14, 2024 7:08pm

throw new Error(`Invalid private key: ${argv.privateKey}`);
}
const DAY_IN_SECONDS = 60 * 60 * 24;
client.setBidStatusHandler(async (bidStatus) => {
Copy link
Contributor

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) {
Copy link
Contributor

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?

});
}

async submitOpportunityBidViaWebsocket(bid: OpportunityBid): Promise<BidId> {
Copy link
Contributor

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?

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

Copy link
Contributor

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"?

Copy link
Contributor

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.

/**
* Represents a raw bid on acquiring a permission key
*/
export type Bid = {
Copy link
Contributor

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

Copy link
Contributor Author

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(),
Copy link
Contributor

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

Copy link
Contributor Author

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?

Copy link
Collaborator

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.

}

async submitBidViaWebsocket(bid: Bid): Promise<BidId> {
const result = await this.sendWebsocketMessage({
Copy link
Collaborator

@ali-behjati ali-behjati Mar 1, 2024

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(),
Copy link
Collaborator

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.

Copy link
Collaborator

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

Comment on lines 15 to 16
this.client.setBidStatusHandler(this.bidStatusHandler.bind(this));
this.client.setOpportunityHandler(this.opportunityHandler.bind(this));
Copy link
Collaborator

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}`);
Copy link
Contributor

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

*/
export type TokenQty = {
contract: Address;
export type TokenAmount = {
Copy link
Contributor

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

* All the parameters necessary to represent a liquidation opportunity
* All the parameters necessary to represent an opportunity
*/
export type Opportunity = {
Copy link
Contributor

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);
Copy link
Contributor

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

Copy link
Contributor Author

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.

@m30m m30m merged commit f14dd35 into main Mar 14, 2024
@m30m m30m deleted the per-js-sdk-updates branch March 14, 2024 19:15
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.

4 participants