<story><title>Show HN: Octo – Generate a serverless API from an SQL query</title><url>https://octoproject.github.io/octo-cli/</url></story><parent_chain></parent_chain><comment><author>eatonphil</author><text>I&amp;#x27;ve got a similar project that reads your db schema and generates a Go REST API and a TypeScript&amp;#x2F;React web interface. (The code-generation is language agnostic so at some point I&amp;#x27;d like to add at least a Java REST API as well.) It supports PostgreSQL, MySQL, and SQLite.&lt;p&gt;Unlike PostgREST&amp;#x2F;Hasura and some other dynamic tools you can &amp;quot;eject&amp;quot; at this point if you&amp;#x27;d like and continue on development without the generator in a language you already know. But I&amp;#x27;m working on exposing Lua-based hooks you could carry across whatever backend language you choose to generate and avoid the need to eject.&lt;p&gt;It has builtin support for paginated bulk GET requests with filtering, sorting, limiting. Built-in support for bcrypt-password authentication and optional SQL filters specified in configuration for authorization of particular endpoints based on session and request metadata.&lt;p&gt;Still very much a work in progress but the goal is to push the envelope on application boilerplate.&lt;p&gt;Screenshots are of the example&amp;#x2F;notes project in the repo.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.dbcore.org&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.dbcore.org&amp;#x2F;&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;eatonphil&amp;#x2F;dbcore&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;eatonphil&amp;#x2F;dbcore&lt;/a&gt;</text></comment>
<story><title>Show HN: Octo – Generate a serverless API from an SQL query</title><url>https://octoproject.github.io/octo-cli/</url></story><parent_chain></parent_chain><comment><author>Trisell</author><text>The idea is interesting. But it looks like you end up with a yaml file that enumerates each of your tables&amp;#x2F;endpoints and the queries that back them. So are we exchanging the “complexities” of code, where we have control and testing, for the “lack of complexity” of yaml that becomes unwieldy and untestable in the name of “simplicity?”</text></comment>