StorX VS roapi

Apparently it is still common practice to have such "if bla is set, when do blub" everywhere in ones code? No functions with decorators or a similar or alternative concept? I would think there should be some kind of easy to use mechanism in place, that tends to avoid forgetting these ifs.

There are ... 60 lines of global logic, that is not encapsulated in any function or so?

Some of the functions are quite long. But I think mostly because they render out HTML.

At line 107 with the procedure printHeader starting, what I call PHP nightmare starts:

Switching back and forth between PHP, HTML and HTML with integrated JS (!!!) and CSS. All of course without syntax highlighting, but that is a minor issue. The major issue is treating HTML and JS and CSS as mere strings, instead of structured data, and the very bad readability of having procedures suddenly "end" and spit out some wild HTML, then suddenly continuing again, because some server side logic/decision is required at some place in that stream of unstructured data, whether some part is to be included or not, then the stream continues and then at some point one needs to actually check, that one did not forget to truly end the procedure. This has some of the worst readability. Maybe C code with bit magic is worse.

One can find this kind of approach in many, if not most, Wordpress plugins. What's more is, that this is also terrible for writing tests. The procedures do not return a value to check against. All is a side effect. Perhaps there is some PHP library that manipulates the PHP system, so that one can at least do string comparisons on the side effects. Like mocking, basically. But still terrible for testing.

For a comparison of how it should be done instead, check any templating engine, that at least separates template files from PHP code. Better, checkout SXML libraries, that treat HTML as structured data, a tree that can be traversed and pattern matched against, without pulling out arcane string manipulations or regular expressions. And then consider how one could write tests based on such structured data.

If this "HTML is a string, even on the server side before sending it" kind of approach is how a language treats HTML, then the language is not suitable to be directly used for HTML templating, without any additional library. This alone has caused uncountable security issues in so many projects.

I realize, that this is probably kind of a "one off script" and may not reflect other kinds of PHP code.

I did all of those things myself, years ago. And when I already had moved away from such an approach, I had to maintain a project, that was written this way. It had no tests of course. No fun. It has not that much to do with you personally being a good dev or not. I think it has to do with the ecosystem encouraging you to do these things. Outputting HTML like that should be declared illegal and should be impossible.

https://github.com/aaviator42/StorX/blob/main/StorX.php in comparison looks much better. It seems it does not output things directly. Everything seems wrapped nicely into methods. One obvious footgun seems to be another global state thing, that I really hope is not a thing in PHP itself:

    const THROW_EXCEPTIONS = TRUE;

I'm a huge fan of SQLite! My org's apps use it heavily, often via this simple key-value interface built on sqlite: https://github.com/aaviator42/StorX

Handles tens of thousands of requests a day very smoothly! :)

My org's apps heavily use this simple key-value interface built on sqlite: https://github.com/aaviator42/StorX

There's also a bunch of other purpose-built tiny utilities on that GitHub account.

I wrote a small PHP library that gives you a key-value storage interface to SQlite files: https://github.com/aaviator42/StorX

I've been dogfooding for a while by using it in my side projects.

And there's a basic API too, to use it over a network: https://github.com/aaviator42/StorX-API

This is probably ready to be used in production by others, but I wrote a library that gives you a key-value storage interface to SQlite files: https://github.com/aaviator42/StorX

And there's an API too, to use it over a network: https://github.com/aaviator42/StorX-API

If your use case is read-only I suggest taking a look at roapi[1]. It supports multiple read frontends (GraphQL, SQL, REST) and many backends like SQLite, JSON, google sheets, MySQL, etc.

[1] https://github.com/roapi/roapi

For smaller datasets then anywhere up to a few mb which isn't so bad reasonable with an API but in theory for historic data it could be up to several gb. I've not seen datasette go that high (IIRC it's a 1000 row return limit by default).

That's what got me intrigued with Atlassians offering, as data lakes tend to be something internal to a company, not something I've ever seen offered as an interaction point to users.

I've also tested out roapi [1] which is nice if the data is in some structured format already (Parquet/JSON)

[1] https://github.com/roapi/roapi

https://github.com/roapi/roapi/issues/103?

Very cool and well executed project. Love the sprinkle of Rust in all the other companion projects as well :)

The ROAPI(https://github.com/roapi/roapi) project I built also happened to support a similar feature set, i.e. to expose sqlite through a variety of remote query interfaces including pg wire protocols, rest apis and graphqls.

> why not just accept SQL and cut out all the unnecessary mapping?

You might be interested in what we're building: Seafowl, a database designed for running analytical SQL queries straight from the user's browser, with HTTP CDN-friendly caching [0]. It's a second iteration of the Splitgraph DDN [1] which we built on top of PostgreSQL (Seafowl is much faster for this use case, since it's based on Apache DataFusion + Parquet).

The tradeoff for allowing the client to run any SQL vs a limited API is that PostgREST-style queries have a fairly predictable and low overhead, but aren't as powerful as fully-fledged SQL with aggregations, joins, window functions and CTEs, which have their uses in interactive dashboards to reduce the amount of data that has to be processed on the client.

There's also ROAPI [2] which is a read-only SQL API that you can deploy in front of a database / other data source (though in case of using databases as a data source, it's only for tables that fit in memory).

[0] https://seafowl.io/

[1] https://www.splitgraph.com/connect

[2] https://github.com/roapi/roapi

It could be the NDJSON parser (DF source: [0]) or could be a variety of other factors. Looking at the ROAPI release archive [1], it doesn't ship with the definitive `columnq` binary from your comment, so it could also have something to do with compilation-time flags.

FWIW, we use the Parquet format with DataFusion and get very good speeds similar to DuckDB [2], e.g. 1.5s to run a more complex aggregation query `SELECT date_trunc('month', tpep_pickup_datetime) AS month, COUNT(*) AS total_trips, SUM(total_amount) FROM tripdata GROUP BY 1 ORDER BY 1 ASC)` on a 55M row subset of NY Taxi trip data.

[0]: https://github.com/apache/arrow-datafusion/blob/master/dataf...

[1]: https://github.com/roapi/roapi/releases/tag/roapi-v0.8.0

[2]: https://observablehq.com/@seafowl/benchmarks