What does HackerNews think of roapi?

Create full-fledged APIs for slowly moving datasets without writing a single line of code.

Language: Rust

#14 in GraphQL
#2 in GraphQL
#12 in REST API
#93 in Rust
#34 in SQL
Tuql: Automatically create a GraphQL server from a SQLite database | Apr 2023
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

Ask HN: Best way to provide access to large data sets | Apr 2023
Expand Context ↕
For smaller datasets then anywhere up to a few mb which isn't so bad 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
SQLite-based databases on the Postgres protocol | Jan 2023
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.

PostgREST – Serve a RESTful API from any Postgres database | Dec 2022
Expand Context ↕
> 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
Command-line data analytics | Nov 2022
Expand Context ↕
And if you're looking for a similar experience (very fast analytical SQL queries) but over HTTP, for example, to power a public dashboard or a visualization, you can try ROAPI [0] or Seafowl [1], also built on top of DataFusion (disclaimer: working on Seafowl):

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

[1]: https://github.com/splitgraph/seafowl
Q – Run SQL Directly on CSV or TSV Files | Jun 2021
Shameless plug, I also built a tool in Rust to provide SQL/GraphQL query access to CSV and many other tabular file formats: https://github.com/roapi/roapi.