The ninety-ninety rule, again...

I've written about the ninety-ninety rule before and unfortunately it happened again. Just when my brain goes

reality goes

Just recently Hive account@drmake made a commit to visualize the steemmakers curation trail on our website. The intent is to give our backers some more visibility and in a later stage we plan on showing the top followers in a more visible way as designed by Hive account@fabiyamada here. As it was his first vue.js / typescript experience there are some things that needed some rework. But after that it should only be a matter of deploying.

Improved code separation and better estimation

Vue.js is designed around the MVVM pattern (Model - View - ViewModel). It's a pattern that can be challenging at first but when applied correctly can save a lot of time and make cooperation a lot easier. Professionally I'm quite fond of using this technique for designing 'big' WPF applications (together with PRISM). IMHO there was not enough separation in the design by Hive account@drmake so I fixed that. Another 'issue' was the use of the any type in typescript. noImplicitAny is preferably set to true typescript can catch unintentional errors at design time and makes the code more readable.

While fixing these issues I noticed that the calculations by Hive account@drmake assume a voting power of 100% which, in reality, is seldom the case. I had to do some research and extra testing to account for that. There is no direct functionality in steemjs to do this and it requires some basic calculation as outlined here by Hive account@stoodkev. I did some further digging to be able to explain the magic numbers and commented those in our code base.

Proxying the request

After these changes only deployment was left, the first 90% was done. But that was where things went completely sideways and another 90% arrived. Once deployed the code did not work, the list didn't show. It took some digging to find out this was the error: "No 'Access-Control-Allow-Origin' header is present on the requested resource". It literally took me many hours to understand the root of this issue and by the time I got that I realized there was not much I could do about it. As it turned out this was an issue because of a cross site request. The trail data is fetched from steemauto and this site did not accept this request once deployed to our side. Almost all information on the internet explains how to modify the backend to fix this error message but in our case it is not our backend so we really can't change it or expect steemauto to change it and request them to trust us. A lot of digging later I found out that proxying the request might fix the issue and that is the current patch in the work. We now rely on a heroku proxy and this seems to work reliable.

Have a look at our Trail page to see the result.