Launch HN: Evidence (YC S21) – Web framework for data analysts • Hacker News Board

Re: Launch HN: Evidence (YC S21) – Web framework for data analysts

#91

Post by Aeolun » Sun, Aug 29, 2021, 6:39 AM UTC

amcaskill wrote: post #19

101008 wrote: post #8

How do you handle live data vs fixed data? If I am making a report, I want the charts to remain static - if not, over time, they may not match with what is said on the report. Is there an option to, after saving the report or run the query, to make the values static forever?

This is an excellent question, and it's one of the areas where we think we can do some pretty novel things with our approach. There are a two main cases of this idea that we have spent time thinking about. 1. Truly static report. Here, you would need to condition your SQL queries so that they continue to return the same results over time. E.g. your `where` clause restricts the results to 'on or before' the day of wri…

I’m confused. I understood this to generate static pages. If you never update them, the report wouldn’t change right?

E.g. it executes the queries during build time, not on every load.

Re: Launch HN: Evidence (YC S21) – Web framework for data analysts

#92

Post by amcaskill » Sun, Aug 29, 2021, 8:24 PM UTC

Aeolun wrote: post #91

amcaskill wrote: post #19

Earlier quoted context omitted.

This is an excellent question, and it's one of the areas where we think we can do some pretty novel things with our approach. There are a two main cases of this idea that we have spent time thinking about. 1. Truly static report. Here, you would need to condition your SQL queries so that they continue to return the same results over time. E.g. your `where` clause restricts the results to 'on or before' the day of wri…

I’m confused. I understood this to generate static pages. If you never update them, the report wouldn’t change right? E.g. it executes the queries during build time, not on every load.

You are correct that Evidence executes queries at build time, not at load time.

In a production environment for business reporting we would expect users to be building their project a few times a day, if not more often.

For example, we compile all of our KPIs for evidence into an evidence project, and we trigger a build of that project twice a day so that it has up-to-date metrics for us.

Your question is making me think about what an incremental build strategy could/should look like, but that’s a bit down the road for us.

Re: Launch HN: Evidence (YC S21) – Web framework for data analysts

#93

Post by Aeolun » Mon, Aug 30, 2021, 11:25 AM UTC

amcaskill wrote: post #92

Aeolun wrote: post #91

Earlier quoted context omitted.

I’m confused. I understood this to generate static pages. If you never update them, the report wouldn’t change right? E.g. it executes the queries during build time, not on every load.

You are correct that Evidence executes queries at build time, not at load time. In a production environment for business reporting we would expect users to be building their project a few times a day, if not more often. For example, we compile all of our KPIs for evidence into an evidence project, and we trigger a build of that project twice a day so that it has up-to-date metrics for us. Your question is making me t…

Probably not worth it to do incremental I think. At least, unless your reporting queries take ages (now that I say that, I can practically guarantee that someone is going to think it’s normal to have a report run for several days)

Either way, my point was that if the final output is a few static HTML files, it’s probably not too much of a problem to save literally every iteration of a report.

Re: Launch HN: Evidence (YC S21) – Web framework for data analysts

#94

Post by amcaskill » Tue, Aug 31, 2021, 9:14 PM UTC

Aeolun wrote: post #89

saadatq wrote: post #59

> In our experience, the BI layer is the weakest part of the modern data stack. The BI layer has a poor developer experience, and decision makers don’t really like the outputs they get. It turns out, these two issues are closely related. The drag and drop experience is so slow and low-leverage that the only way to get all the content on the page is to push a lot of cognitive load onto the end user: global filters, dr…

We can just teach all the people that want this data SQL?

This is a fair point!

YMMV, but in our experience the vast majority of the hours logged in the 'self-serve' pivot table interface of a BI system come from folks who actually do know SQL and have the word analyst in their title.

When you look at session data on non-technical people doing things with those pivot table interfaces, they are almost never doing the 'complex exploratory analysis' that BI vendors advertise. They are either doing sequential lookups of individual records, or they are putting together a simple data pull so that they can do something in a spreadsheet.

We think we can address the bulk of these use cases by providing two components: a lightweight pivot table, and a 'download to excel' button. These would be components like any other chart or graph. Outputs.

We think a pivot table is a nice output for some situations, we just don't think your data team should have to use a pivot table interface to produce the whole reporting system.