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

A new block explorer #67

Open
AlessandroSpallina opened this issue Aug 25, 2019 · 6 comments
Open

A new block explorer #67

AlessandroSpallina opened this issue Aug 25, 2019 · 6 comments

Comments

@AlessandroSpallina
Copy link

@AlessandroSpallina AlessandroSpallina commented Aug 25, 2019

The development of this block explorer is quite firm, we have a stable old-fashioned explorer.
The current project is in php and uses the cakephp framework, particularly indicated for small projects see a comparison

Actual de facto standard for medium-large web apps for the backend is laravel, which also provides integration with main frontend frameworks, including vuejs. Is also good to have websocket instead of ajax for runtime update without page refresh.

I believe that the block explorer is a fundamental service for a cryptocurrency, I think we should have a new explorer: mobile first, super detailed (able to provide statistics even to the most hungry nerd), which exposes api to allow third-party software development, able to offer new services.

Below a list of juicy things to have in a new explorer:

  • More stats about blockchain and its network, lbry upper layer network:
    • chain size / block size / txs in blocks
    • chain difficulty / hashrate
    • top supported content / tip-support stats
    • claims stats
    • blockchain network visualization on map
    • lbry-sdk network visualization on map
    • mining stat / pool hashrate / mining profit
    • lcb price / comparison with other stats
    • {suggest more}
  • More services:
    • Email/telegram alert when blockchain see an input (output) tx to (from) an address in a "watch list" customized by the user [auth zone]
    • broadcast signed tx, useful for users who use a cold wallet (offline) to store lbc
    • address alias, in order to allow identification of pool addresses, explorer addresses etc.. [can be both general alias and user customized alias: auth zone]
    • {suggest more}

I created a repo in which I am developing a new explorer based on laravel, I'm still porting the functionality of the current explorer, but the classic "blockchain" part is ready.
I would like some feedback on what I have already developed, if you like it, if something could be better, if I have to continue or abandon the development, if there is a possibility that the project will be included under github lbryio organization.
Repo link: LBRYEXPLORER
Actually hosted here: lbryexplorer.tech

@tzarebczan
Copy link
Member

@tzarebczan tzarebczan commented Sep 3, 2019

Hey @AlessandroSpallina , thank you for the writeup and the work. I haven't been able to find the time to review this yet, but I see that lbry.community is trying to give you a hand getting some attention on it also. Will try to get you a review this week.

Loading

@AlessandroSpallina
Copy link
Author

@AlessandroSpallina AlessandroSpallina commented Sep 4, 2019

yes, I had a couple of feedbacks from lbry.community and lbry.social
I temporarily slowed down the development due to upcoming tests and work

Loading

@marcdeb1
Copy link
Contributor

@marcdeb1 marcdeb1 commented Jan 10, 2021

Hi Alessandro,
Thank you for your work on the new explorer ! Love the design and code structure is much better.
I've been taking up the repo to continue and finish it : https://github.com/marcdeb1/LBRYEXPLORER
I'm doing design changes, adding the claims pages, price info and stats pages.
I'm also checking the old repo issues to solve them during development.
As soon as I have a test website I will post it here. We will also add a CI/CD process to handle deployment.
Feel free to join or add comments !

Loading

@AlessandroSpallina
Copy link
Author

@AlessandroSpallina AlessandroSpallina commented Jan 12, 2021

Hello @marcdeb1 marcdeb1, great job.
My interest in lbry is still present, but as you have seen I left the development of the blockexplorer for several reasons.
One of these after studying a bit how scalable service design works is the fact that the current monolithic design of the new explorer may be tight in the long run, it would be better in my opinion to implement a server rest and serve the frontend on an nginx instance . What do you think about it? Initially I was thinking of writing the server in python with django, but since you are continuing the php version with laravel you could convert this to a rest microservice using lumen (a light version of laravel geared towards this sort of thing) and develop the frontend separately.

Loading

@marcdeb1
Copy link
Contributor

@marcdeb1 marcdeb1 commented Jan 17, 2021

@AlessandroSpallina for such a project there would not be much difference separating frontend and backend. If everything is well optimized, cache well setup etc., Laravel will be able to handle hundreds of requests per second, which is enough for our usage. I optimized RAM usage, which is quite low (less than 50MB per worker), so if needed we can add many workers and it can fit in a small server. It will definitely scale.
Here a preview of the explorer : https://lbry-explorer.herokuapp.com
Please tell me what you think about it. There are some things left to do, especially on the stats pages, but the rest seems good to me.

Loading

@AlessandroSpallina
Copy link
Author

@AlessandroSpallina AlessandroSpallina commented Jan 17, 2021

@marcdeb1 looks very nice, bravo! Also could be cool a system of auto updating of the data, for example for the mempol/block page.

And also, an univoque image for each address, in order to check at first look if this is really your address or not (there are different ways to do it).

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants