-
Notifications
You must be signed in to change notification settings - Fork 3
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
feat!: optimize middleware querying #126
Conversation
Deployed to https://pr-126-aescan.stg.aepps.com |
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.
Cool, seems like a lot of work 🥇 the change looks promising.
Could you also provide some measurements before and after change? How was the optimization successful?
} | ||
|
||
function processKeyblockUpdate(keyblock) { | ||
if (keyblocks.value?.[0].hash !== keyblock.prev_key_hash) { |
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 would better read it in some human readable form of what's going on 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.
Agree, I think this function should be more readable or at least have some comments. It's hard to understand what's going on.
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.
Just like in other process* functions, updating stuff fully, partially, or skipping the update entirely depends on multiple variables that represent given scenario. I'm struggling to split it into smaller chunks without going into advanced programming patterns we haven't used in the project and producing a few times more code around it.
I added the comments where the code isn't very obvious. Please, let me know if it helps or I missed some spots.
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.
Honestly, I am not satisfied with the outcome. The function is long and has many comments and it's hard to read for me
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 hard work, this will optimise the app a lot.
Please have a look at my comments, some things are not clear to me and in general I understand the issues about handling websocket data so I would suggest to add some comments to some parts which could be hard to understand.
src/stores/blockchainStats.js
Outdated
@@ -44,5 +44,8 @@ export const useBlockchainStatsStore = defineStore('blockchainStats', { | |||
const { data } = await axios.get(`${useRuntimeConfig().public.MIDDLEWARE_URL}/v2/txs/count`) | |||
this.transactionsCount = data | |||
}, | |||
increaseTotalTransactionsCounter() { |
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 would rename this to increaseTransactionsCount
but It's just a preference.
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 your suggestion, adjusted.
src/stores/recentBlocks.js
Outdated
...keyblock, | ||
}) | ||
|
||
if (keyblocks.value.length > 18) { |
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.
Why are keblocks removed if the total length is > 18?
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.
It's the limit of visibility, added a constant to make the value self-explanatory 👍
} | ||
|
||
function processKeyblockUpdate(keyblock) { | ||
if (keyblocks.value?.[0].hash !== keyblock.prev_key_hash) { |
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.
Agree, I think this function should be more readable or at least have some comments. It's hard to understand what's going on.
src/stores/recentBlocks.js
Outdated
...microblock, | ||
}) | ||
|
||
if (selectedKeyblockMicroblocks.value.length > 30) { |
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.
Also here, I'm wondering why 30
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.
It's the limit of visibility, added a constant to make the value self-explanatory 👍
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 fixes, providing measurements and explanation. 🕵️ I wish there could be done something with the implementation. Some parts feel heavyweight and hard to read what's going on
} | ||
|
||
function processKeyblockUpdate(keyblock) { | ||
if (keyblocks.value?.[0].hash !== keyblock.prev_key_hash) { |
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.
Honestly, I am not satisfied with the outcome. The function is long and has many comments and it's hard to read for me
Thanks @janmichek I'll try to restructure the code right after I finish Oracle details page |
@janmichek @michele-franchi I've improved reliability and readability. Please 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.
Very good edit ⚡ Hope you see the same value in code readability, even tho it was not easy to achieve given the fact of directing data from different sources. A long step forward I would say.
I would still like to see some nicely named constants of what's going on in some if
expressions, but giving it the green light anyway 😺
@janmichek I do, thanks for pushing for that. I had a brain lock when I tried to refactor it the first time and didn't know how to tackle it |
@csiarab could you check it? |
@lukeromanowicz Is this normal ? |
@csiarab no, that's not normal. 👀 but also this part has not been touched in this PR and I'm not able to reproduce it. Please give it another try |
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.
Really nice!
I noticed a difference between transaction count from the current dev:
Screen.Recording.2023-05-02.at.13.15.02.mov
and if you check the total transactions at the beginning of the video by a sum of all numbers inside microblocks you'll see it's not correct. Could you verify it? Thanks
@michele-franchi I'm afraid it's an issue that can be tackled only on the mdw side. There isn't much we can do about it right now. The current implementation we have on the develop branch is pretty much never accurate, while after changes in this PR it's accurate when a new keyblock gets minted. e.g. I described the issues I found in a dedicated issue on the mdw side: aeternity/ae_mdw#1291 |
@lukeromanowicz how is it accurate? In the screenshot I see |
@michele-franchi There are two scenarios:
The screenshot I've sent above is proof that the current solution is not accurate. I'm discussing with the mdw team the possibility to fix this inaccuracy in the linked mdw 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.
Good job! I guess we can then merge this and followup incorrect transactions count.
Description
Resolves #12
Instead of querying all blockchain stats from REST API every time a new transaction message arrives from websocket, it calculates most of the statistics dynamically based on websocket data and syncs back with REST API only upon minting a new keyblock to correct possible misalignment caused by microforks. This implementation is utilizing message buffer because transactions and macroblock messages tend to arrive before the keyblock message. If there will be a hiccup in data transfer, the message buffer will reset itself after hitting 30 messages and resync everything through the REST API.
Breaking change: using middleware websocket v2 instead of v1. Change
NUXT_PUBLIC_WEBSOCKET_URL
value fromwss://mainnet.aeternity.io/mdw/websocket
towss://mainnet.aeternity.io/mdw/v2/websocket
.Demo
The online demo might not work due to a change in the WebSocket environmental variable to use v2 websocket instead of v1
2023-04-18.10-52-19.mp4
Checklist: