Hello HN! Nice to see this up here. Chris here, cofounder of Plotly.
Falcon is open source and works without an internet connection or a Plotly Chart Studio account. Falcon wires together our graphing library plotly.js (https://github.com/plotly/plotly.js/), the plotly.js chart editor (https://github.com/plotly/react-chart-editor), Electron, and some open source NPM packages for connecting to databases.
Just FYI - As a company (Plotly), we're spending most of our development effort these days on Dash Open Source (https://github.com/plotly/dash) and Dash Enterprise (https://plotly.com/dash). Truth be told, we found that most companies we worked with preferred to own the analytical backend. We also heard many stories of organizations running into roadblocks with off-the-shelf SQL or BI tools (Falcon included!). Our approach with Dash is to provide the visualization and application primitives so that you could build your own tailor-made dashboards, analytical apps, or yes, even SQL editors.
Any reason the Github page advertises Windows and Mac but not Linux? I saw that its built in Javascript and checked the releases page,you guys built a Linux version too. Is it just something that, while possible, you don't want to support officially with more than a build?
Hi, just wanted to thank you for pivottable.js which I'm using since 6 years ago. I discovered today you're at plotly, I started using dash this year :)
I actually like plotly.js, it seems to be one of the only good alternatives to R‘s Shiny library. Still, I prefer to keep JavaScript libraries inside a web browser.
Also see: Apache Superset [0] -- this one looks really like a fully fledged data exploration and visualisation suite, being a possible free and open source alternative to Microsoft Power BI [1]. Using the official / own image can be also deployed as a service running in a local infrastructure.
Would be curious for a comparison between all the mentioned data vis suites in this thread actually.
1) Redash and Falcon focus on people that want to do visualizations on top of SQL
2) Superset, Tableau and PowerBI focus on people that want to do visualizations with a UI
3) Metabase and SeekTable focus on people that want to do quick analysis (they are the closest to an Excel replacement)
I have been using group 2) for 3 something years, I am not too excited by them, Superset is cool, Tableau and PowerBI value has been blown out of proportion by marketing. Group 3) is very promising but for some reason more niche although because of their pricing structure they scale as well as Excel (i.e. you can have thousands of users building stuff in Metabase no problem). Group 1) not sure what to say there, I guess it would be my favorite but SQL becomes messy after the first join.
The reality check is that none of those tools stands on its own. Without a database, data prep and security setup they are more or less fancy toys. Unfortunately very few companies understand how to set all of this up in a way that users can actually work with it. So I keep seeing a lot of half done, super expensive, setups in Tableau and PowerBI that have not delivered what they were promising.
Also, I agree with chriddyp that most companies would rather own their analytics for stuff that is customer facing. For internal facing dashboards the dashboarding BI tools are OK (although I lean more on group 3) than group 2)).
> The reality check is that none of those tools stands on its own.
so true! Only exception is maybe CSV data.
Re SeekTable: it also supports usage scenario when data sources ('cubes') are configured by power user (with some IT background), and shares cubes/reports to others that use simple web UI to create their own reports - and this requires paid subscription for publisher only ($25/mo).
And there is another Apache project : Apache Hue, as a django web app
I d put between group 1) and 2). Not in 3), because there is not "quick charts", and datasources are not managed at application level but in configuration files and require more "administration" tasks.
Curious where you would consider chart.io to fall in this ecosystem?
I have been using it for its seamless AWS Athena integration to get a handle on load balancer logs when needed. However it is pretty pricey. Would love to move to an open source solution. However my use case feels a little different than what was mentioned above?
In theory you are saving some money for not using a database, redshift is also pricey. Have you considered that? The free solution is python + altair in a jupyter notebook, but you would have to decide if it is worth your time to setup.
Last time we tried to use it there were real problems with date filtering in SQL based DBs and it’s a must for big datasets that span over time (this looks like the most common use case to me). Basically metabase would generate WHERE condition that would like `date(date_column) BETWEEN ... AND ...` (or if you were filtering by minutes or years this would be something else). This prevents DB from being able to use an index on date_column and don’t even get me started on why adding indexes for all sorts of `date(...)`, `year(...)` etc expressions is not an optimal solution. I ended up fixing this in metabase and opened a PR https://github.com/metabase/metabase/pull/9860
Which was initially welcomed but then was ignored for a few months (we were using our forked version in my company in the meantime), after which was closed because they’ve fixed it differently and sure enough they did and it was a neater fix architecture-wise. Just that it didn’t actually fix the majority of use cases so there’s now new isssue opened with the same problem described
https://github.com/metabase/metabase/issues/11502
And surely it’s ignored. Since then we migrated to a relatively simpler Redash, we’ve found that none of the people at our company who were supposed to benefit from GUI query builder never actually used it and only engineers were building dashboards, and for us it’s obviously easier to write SQL. One benefit of Redash I’ve noticed was that it allows you to schedule dashboard queries to run for example every 10 minutes which means that amount of users of the dashboard doesn’t add any load to the DB because they get cached results and those results are relatively fresh at the same time.
It's usually easier to write SQL than drag/drop it. For complex joins having a graphical view of the join structure (list? tree? star?) is very helpful if you're new to it, otherwise no. And drag/drop tools don't cover complex stuff like recursive CTEs, and often, simpler stuff too. IME, YMMV. Maybe better graphical tools exist than the ones I have seen.
SeekTable also can use BigQuery as a data source, however it is more about reports sharing and quick ad-hoc queries - to make this possible data source should be configured first.
All the commercial ones support it, but most of them are expensive. Mode has a free plan which allows you to connect to BQ, run queries and then analyze the result sets in Jupyter. It's pretty cool for smaller stuff https://mode.com/compare-plans/
I want to find a way to incorporate this into a dashboard for suits. Seems like it would let them solve a lot of their own requests - in theory. In a lot of companies they'd probably still make requests to create the graphs and sql queries for them.
Give a suit a fish and he's happy for a day. Teach a suit to fish and he'll still be back tomorrow for his fish. Who wants to fish when you can get a code monkey to do it for you.
Success here is possible. I didn't believe it until I saw it :)
I was in a regional strategy-esque team for Uber Eats. Eats have a nicely curated data warehouse of core operational data. They also have excellent, free, self-paced SQL training built around that same data (a tailored version of https://academy.vertabelo.com/). So you learn both how SQL works and how your data is structured at the same time. You'd be surprised how many junior-mid level suits are eager to pick this up.
The result is very useful. Some non-technical folk picked this up on the side in just a few weeks. They understood the limitations and caveats needed to use the data well. They needed very limited assistance here-and-there.
It was purely magical how they picked up both the data and the system.
This is literally what SSRI and PowerBI was invented for. Still requires codemonkies to prepare the data, but at least it cuts down on the rate of requests by allowing them to massage filters by themselves.
I've used this strategy with a read only replica. It also protects the database from long running and inefficient queries. Highly recommend doing this if you have the budget for it.
My initial reaction is the same when I see names like these, but...
This happens everywhere in business/products/mom-and-pops even street names in different cities!
Not sure why we’re so sensitive to software names, maybe hits close to home with naming being one of the tough problems along with caching etc (sure everyone knows how the saying goes).
> Not sure why we’re so sensitive to software names
For tools that install in a machine, you can have things be overridden if you install another tool of the same name. Binaries, libraries, or other assets.
Also with abstract things like frameworks the effect is worse, because people are not necessarily sure what you are talking about when mentioning the name. This is not the case usually with street names.
The funny thing to me is always how Oracle is the odd duck, requiring a specific client install to use.. where as most other databases have established protocols with open client library implementations.
It's almost the opposite of the Microsoft's strategy by then. Microsoft made it easy for anybody to depend on their software, Oracle goes out of their way to make it harder.
This is a cool project - however Mac and Windows only...most likely because they are creating the toolchain for this.
I would pay money to get something like this inside vscode - which is an ecosystem that works great on all platforms and provides the hooks to build something like this.
On that note, I think microsoft is making a mistake by not creating an app store of sorts for vscode. VsCode is as good a desktop developer marketplace as the play store is for mobile apps.
I wish that plotly had built this inside jupyter (where their Dash product competes against Streamlit) or vscode. Building a desktop installer toolchain from scratch, does not make sense.
There are surprisingly few desktop apps for basic sql -> charts, so I was happy to stumble on Falcon. It's similar to their web offering (or Periscope, Looker, etc) and works quite well (regardless of a few UI quirks).
Falcon is open source and works without an internet connection or a Plotly Chart Studio account. Falcon wires together our graphing library plotly.js (https://github.com/plotly/plotly.js/), the plotly.js chart editor (https://github.com/plotly/react-chart-editor), Electron, and some open source NPM packages for connecting to databases.
Just FYI - As a company (Plotly), we're spending most of our development effort these days on Dash Open Source (https://github.com/plotly/dash) and Dash Enterprise (https://plotly.com/dash). Truth be told, we found that most companies we worked with preferred to own the analytical backend. We also heard many stories of organizations running into roadblocks with off-the-shelf SQL or BI tools (Falcon included!). Our approach with Dash is to provide the visualization and application primitives so that you could build your own tailor-made dashboards, analytical apps, or yes, even SQL editors.
If you want to read more about where we're at, here's an essay we wrote last week on Dash: https://medium.com/plotly/dash-is-react-for-python-r-and-jul...