12 ms·
Launch HN: Evidence (YC S21) – Web framework for data analysts
Hi HN! We’re Adam and Sean from Evidence (https://evidence.dev https://evidence.dev). We’re building a static site generator for data analysts. It's like Jekyll or Hugo for SQL analysts.
In Evidence, pages are markdown documents. When you write SQL inside that markdown, the SQL runs against your database (we support BigQuery, Snowflake, and Postgres - with more to come). You can reference the results of those queries using a simple templating syntax, which you can use to inline query results into text or to generate report sections from a query. Evidence also includes a component library that lets you do things like add charts and graphs (driven by your queries) by writing declarative tags like: <LineChart />
How is it different? Most BI tools use a no-code drag-and-drop interface. Analysts click around to build their queries, set up their charts etc. and then they drag them into place onto a dashboard. To stick with the analogy, if Evidence is Hugo, most BI tools are Squarespace. BI tools are built that way because they assume that data analysts are non-technical. In our experience, that assumption is no longer correct. Data analysts increasingly want tools that let them adopt software engineering practices like version control, testing, and abstraction.
When everything is under version control, you are less likely to ship an incorrect report. When you can write a for loop, you can show sections for each region, product-line etc., instead of asking your users to engage with a filter interface. When you can abstract a piece of analysis into a reusable component, you don’t have to maintain the same content in multiple places. Basically, we’re providing the fundamentals of programming in a way that analysts can easily make use of.
Reporting tools have been around since COBOL, and have gone through many iterations as tech and markets have evolved. Our view is that it’s time for the next major iteration. We worked together for five years building the data science group at a private equity firm in Canada. We set up ‘the modern data stack’ (Fivetran, dbt, BigQuery etc.) at many of the firm’s portfolio companies and we were in the room during a lot of key corporate decisions.
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, drill down modals, grids of charts without context. Like most users, business people hate that shit. And because the production process isn’t in code, the outputs are hard to version control and test—so dashboards break, results are internally inconsistent, and so on, in just the way that software would suck if you didn’t version control and test it.
As early adopters of the modern data stack, we saw the value in treating analytics more like software development, but we were consistently disappointed with the workflow and the quality of the outputs our team could deliver using BI tools and notebook products. Graphics teams that we admire at newspapers like the New York Times don’t use BI tools or Jupyter notebooks to present their work. They code their data products by hand, and the results are dramatically better than what you see in a typical BI deployment. That’s too much of an engineering lift for most data teams, but with a framework designed for their needs and their range of expertise, we think data teams could build products that come much closer to those high standards.
Evidence is built on Svelte and Svelte Kit. This is the JS framework that the NYT has used to build some of their more recent data products, like their Covid risk maps. Sean and I fell in love with Svelte, and we owe a huge debt to that project. In this early stage,Evidence is really just a set of convenience features wrapped around SvelteKit to make it accessible to data analysts (the markdown preprocessor, db connections, chart library). The core framework will always be open source, and eventually we plan to launch a paid cloud version of our product, including hosting, granular access control, and other features that enterprises might pay for.
We would love to hear your thoughts, questions, concerns, or ideas about what we’re building - or about your experiences with business intelligence in general. We appreciate all feedback and suggestions!
- wizwit999 5y agoI like it. I've seen the same issue and agree people over index on no code. I didn't see it on your page, do you get into visualization as well?
- amcaskill 5y agoThanks so much! Yes, definitely. We include a visualization library with the Evidence. You can write <LineChart .../> to add a line chart to your document, <Hist .../> for a histogram etc. You can see the documentation for the chart types we have built under 'components' in our docs. Here's the histogram: https://docs.evidence.dev/components/hist https://docs.evidence.dev/components/hist Designing this is one of the trickiest parts of the project, and is going to be one of the biggest areas of effort going forward. We're trying to build something that is very declarative, so that people don't have to spend a lot of time configuring their charts, and something that is composable, so that you can create more complex viz that include things like annotations.
- domoritz 5y agoHave you looked into using Vega-Lite? It’s declarative and configurable.
- dg4 5y agoLooks great! How are you thinking about the review workflow. I've noticed that BI artifacts / dashboards rarely get a detailed logical review. This living in Github seems like a step in the right direction, but it'd be great to have SQL execution in the review context. i.e. I think you're accidentally filtering out these rows here they are SELECT ...
- amcaskill 5y agoThanks! That's a super promising line of thinking. We really like how Vercel works with pull requests -- generating a preview, blocking the pr if there is a failure in the build process etc. and that's definitely where we'd like to go with the cloud service. We hadn't thought of providing executed SQL back into the review context but of course that would be do-able and very useful. There is a whole host of tooling that you can build around the artifacts when you move them into code. One example an early user suggested was scanning your entire project to find repeated blocks of SQL, and surfacing them to be re-factored into your data warehouse (into your dbt project for example). You could imagine a github action that periodically opens a PR with those suggested re-factors.