feat: make api's for graphs we use instead of templating json #277
Conversation
|
I think that the result of the discussion was that we wanted either/both APIs for getting just important values (eg number of nodes seen in the last 24 hours), or fully embeddable HTML elements. I think that returning an entire JSON object to the ethportal website leaves way more front-end work/maintainence on the ethportal website than we'll want. |
I don't think this is how it works. This PR doesn't create any additional maintenance work, it actually creates less. Currently the website is built as if it was 2012. This PR better aligns the project with modern web practices.
We are currently doing this already. So I am not sure what is being referred to here. before this PR we are embedding json into a webpage which is extreme malpractice. Doing this causes our html pages unable to be cached by CDN's. The difference here is instead of embedding json (which is very bad), we are fetching json which is proper practice. I could go further into how this helps productivity, but I believe the issues I brought to light above would have to be addressed before that kind of discussion would be productive.
This is a completely separate issue and is not directly related to this PR.. |
|
There's been a misunderstanding regarding the conversation that was had at the summit. We were not talking about having glados call JSON endpoints like you're doing here (I agree that loading HTML/JS that itself fetches JSON is better, which is why the stats history and census explorer use that approach, but calling HTML templating "malpractice" is a bit much, and certainly not an issue that would've been worth discussing at summit). We were talking about giving ethportal.net (a separate website from glados) access to some of the components or data within glados for marketing purposes. And having ethportal.net load a big JSON object containing all of the census data and then do its own processing to obtain simple metrics like "how many live nodes on the portal network?" is outside the scope of ethportal.net. It'd be preferable to instead have a simple endpoint that returns a single number that ethportal.net can hit and not have to do any processing on. ethportal.net's processing shouldn't have to change if the data format going into glados's front end changes, they should be decoupled. That said, if you add a PR description this can move forward. But these endpoints are not relevant to any discussion that took place at summit. |
|
@mrferris sounds good I updated the descriptions |
Update index.html to fetch data from api's instead of embedding json. Embedding data makes caching the page not possible so it has to be fully loaded every time.