duckdf VS HTTP.jl

Quite a while ago, when duckdb was just a duckling, I wrote an R package that supported direct manipulation of R dataframes using SQL.[1] duckdb was the engine for this.

The approach was never as fast as data.table but did approach the speed of dplyr for more complex queries.

Life had other things in store for me and I haven’t touched this library for a while now.

At the time there was no Julia connector for duckdb, but now that there is, I’d like to try this approach in that language.

[1] https://github.com/phillc73/duckdf

Yeah, I agree sqldf is quite slow. Fair point.

As you've seen, duckdb registers an "R data frame as a virtual table." I'm not sure what they mean by "yet" either.

Of course it is possible to write an R dataframe to an on-disk duckdb table, if that's what you want to do.

There are some simple benchmarks on the bottom of the duckdf README[1]. Essentially I found for basic SQL SELECT queries, dplyr is quicker, but for much more complex queries, the duckdf/duckdb combination performs better.

If you really want speed of course, just use data.table.

[1] https://github.com/phillc73/duckdf

That's a really good point that I'd not really thought about. I'd never really considered the difference between calling just functions versus macros.

Thinking about Query.jl and DataFramesMeta.jl, and I am for sure not an expert in either, I can't specifically speak to your `head` example, but other base functions can be combined with macros. For example, see the LINQ examples from DataFramesMeta.jl[1] where `mean` is being used. Or again the LINQ style examples in Query.jl[2], where `descending` is used in the first example, or `length` later in the Grouping examples.

Is that the kind of thing you meant?

For whatever reason, with the way my brain is wired, the LINQ style of query just works for me. I have never directly used LINQ, but do have some SQL experience. In fact, I wrote some dinky little wrapper functions[3] around duckdb[4] so I could directly query R dataframes and datatables with SQL using that backend, rather than sqldf[5].

[1] https://juliadata.github.io/DataFramesMeta.jl/stable/#@linq-...

[2] https://www.queryverse.org/Query.jl/stable/linqquerycommands...

[3] https://github.com/phillc73/duckdf

[4] https://duckdb.org/

[5] https://cran.r-project.org/web/packages/sqldf/index.html

The req.url field contains the URL of the received request, the req.method field contains request method, like GET or POST, the req.body field contains the POST body of the request in binary format. HTTP request object contains much other information. All this you can find in HTTP.jl documentation. Our web application will only check the request method. If the received request is a POST request, it will parse req.body to JSON object and send the data from this object to the isSurvived function to make a prediction and return it to the client browser. For all other request types, it will just return the content of the index.html file, to display the web interface. This is how the whole source of titanic.jl web service looks:

If you want to just get the html of a website whose url you already have you can make requests from the http.jl package. https://juliaweb.github.io/HTTP.jl/stable/

HTTP.jl and Gumbo.jl for web-scraping

I haven't seen that tutorial, but I agree that HTTP.jl, Gumbo.jl, and Cascadia.jl are the way. I used them to export public wishlists from bookdepository, which has no API nor a built in exporting tool.

I find some of the library documentation hard to understand. Compare http.jl with python's requests, for example. Something as core as HTTP requests should have clear docs with tonnes of examples. Part of this is also a personal dislike of documenter.jl styling. Idk why the contrast is so low – would prefer a standard readthedocs theme.