But the real issue is that the price is a bit of red herring: the CX22 plan is not available everywhere (only in the old datacenters in Europe I think) and if you need to scale up your machine you can't use the bigger Intel plans (CX32, CX42 etc) because they have been unavailable for long time, and you have either to move to Amd based plans (CPX31 etc), which cost almost double for the same amount of ram, or to Arm64 based plans.
It seems Hostup has only EPYC vCPUs, no Intel, the 16 core machine seems the same, Hostup has the benefit of offering a 32 vCPU machine while Hetzner tops out at 16.
Does it mean I can build and deploy a SQLite based app on fly.io with this approach without using Postgres? If yes, how does the pricing for the permanent storage ( add) needed for SQLite works? Thanks
flop_phoenix is great. If it lacks anything maybe it'd be great to just enhance it instead of building anything new. The author also has cursor based functionality
Thank you and the team for your hard work, and congratulations on the release!
Suggestions for Demos:
1.Charting Libraries Integration
There’s currently a lack of demos showcasing LiveView integrated with powerful charting libraries like Apache ECharts, Plot, Chart.js, etc. A demo of a LiveView-powered dashboard using one of these libraries, connected to a database like SQLite (for simplicity) or DuckDB (for speed and demonstrating integrations beyond Ecto-native DBs), would be fantastic.
Emphasizes interactivity: For example, demonstrate how a server-based LiveView can handle actions such as mouse hover on a chart to update tooltips/labels, click-and-zoom interactions, or connected charts with brush functionality.
2.UI Component Libraries
A demo showcasing robust integration with UI component libraries would also be valuable. Features like tables with pagination, sorting, filtering, and autocomplete/typeahead functionality within modals could be a strong focus.
I’d suggest leveraging lightweight libraries like Flowbite or Preline, as they integrate seamlessly with Phoenix and rely on almost pure HTML and Tailwind for styling.
For additional inspiration on speedy charting libraries, this resource might be useful:
Are you planning to add new UI components like Data Table or other in the future or it’s purely Plotting and Data ingestion and the UI through Tailwind or CSS or would it be possible to add UI libraries like shadcn or DaisyUI to make it a full fledged web site? Thanks
It’s only the first public release, rest assured we have plans to develop it beyond that point :-)
Data tables are high on the list, but it’s going to be a lot of work and I can’t say when we’ll have something to share.
In the meantime almost any library available on npm should work out of the box—not just the ones that we added explicit support for (even though of course some might need more work than others).
3. Apache echarts are much more interactive out of the box. The API is indeed clunky, but they’ve got all the chart type and all interactions you might need.
IMHO, Plot in comparison, is very limited in interactivity and even chart types ( there are no heat maps or donuts).
echarts have a huge example library with clear examples and though Plot has it too, the library is not thought out well. You might looks at an example in the Plot Library only to realize later that it’s a D3 example.
On the good side, the API in Plot is much cleaner and easier to work with.
We generally recommend stacked bar charts over pie and donut charts, so we haven’t prioritized those. But you can already implement them using custom marks, and there’s even a hacky way of doing them using Plot’s map projection system.
I don’t understand your comment about the “D3 example.” If you’re looking for Plot examples, you can find them linked from the Plot documentation and the gallery:
Plot is designed to be extended with JavaScript (rather than a non-JavaScript DSL such as Vega-Lite), such as for custom marks and data transforms. So you might occasionally see other libraries being used together with Plot.
It turns out it's D3, not Plot.
I think you just have all possible viz in this section, but for me as a user coming from the Observable Plot page and clicking on "See more..." my expectation is to see only examples of what could be done with Plot, not both D3 and Plot. I need to explicitly click on each link an check if it's Plot based or not. It gets tiresome and the curiosity just wanes away. Thanks.
Hah, I just pared down that “More from Observable creators” section the other day to make it less obtrusive, and inadvertently made it more confusingly blend into the notebook contents. This is good feedback; we’ll refine it!
That “More from Observable creators” is just a standard footer we put across the site for signed-out users to showcase community content across Observable. It’s not part of the notebook. You can ignore everything below the “Appendix”.
I can second a +1 vote for eCharts. I have used them for fast updating charts (10x second) and they work and look great. I've only had 2-3 small niggles with them in 2years of heavy usage.
1. Let's say I got a Sqlite/Duckdb database file on my server. It's got multiple tables and some of them 100M to 150M records. I want to create a plot/table that would have a slider/filter to only bring and show a slice of data at a time. Since it's statically generated data, how is this interactivity achieved? All the possible facets of data filtered by which ever way will be generated? Won't it be huge and how long will it take to generates this static data or is there an actual call back to the server to the duckdb file (I assume it works with .duckdb file too?)
2. If Observable Framework provides the front-end, does it mean I can use any auth library if I want to create a web site with a log in and subscription options?
3. If it's a static web page, does it mean that at any time a user views a chart, they will also be able to go to the Dev Tools and download the file with data that's behind the viz?
4. When (if you can share of course) is the planned release of Plot's interactions: zoom, pan, interactive legend, brush?
5. Deployment - with big parquet, sqlite, csv files, it's impossible to do CI/CO through github or vercel and such. Will your hosting services offer an option to host those files and runtimes to generate them?
2. Sure, it’s all open source, I bet you could make that work. Or `yarn deploy` to Observable and configure sharing there (though it wouldn’t let you charge others).
3. Yup. Which is part of the appeal of model of running data loaders at build time: you can query some private data and viewers would only be able to see the final result set. (The lack of something like this has always been a huge problem for Observable notebooks. You’d make some great query-driven charts and then couldn’t make it public without some awkward manual dance of downloading and re-uploading a file to a fork of the notebook.)
Thank you
I wonder if for #3 there is a way of somehow to keep the data hidden and only let people see the chart without hacking their way to see the underlying data
During our early exploration, someone made a data loader that returned an entire svg of a chart, instead of the data for a chart. I think it was a headless browser running Observable Plot, but I imagine there are lots of ways to generate charts in a data loader.
Came here with similar questions and Cmd-F "DuckDB". See the comment about "data loaders". Seems like a "data loader" would provide most of what you're asking about.
I'm also thinking that a "data loader" combined with duckdb-wasm and arrow would be a pretty nice combination. I imagine that it might not be too difficult to switch two between two implementations of the "data loader" as needed. Switch between reading from a remote system (in your case DuckDB on a server) and DuckDB running locally in the browser (that can interact with its own remote or local data sources).
See the example at https://huggingface.co/spaces/observablehq/fpdn where DuckDB is used both as a data loader (to download and digest 200GB worth of source data into a small 8MB parquet file) and on the client-side to allow the user to do live search queries on the minimized data. Server-side, we're using duckdb-the-binary, and client-side we're using duckdb-wasm.
So the 200Gb loading and digesting part is totally separate from the Observable Framework, right? You just do it with a standard ( non wasm duckdb as part of ETL) and later you just direct Observable Framework to read and plot the 8Gb file? Thanks
https://hostup.se/en
Is much cheaper than hetzner and still in Europe.