Big difference is it's implemented in pl/pgsql so as Aquameta evolves, there's no external deps. There's a function called endpoint.request(http_verb, URL, post vars) and then it does the rest in plpgsql. A thin Go daemon just takes the request and throws it at the function.
It does a lot of the same stuff PostgREST does. Automatic REST interface to any database, but it also hosts static resources, and dynamic mapping of URL templates to functions.
Needs a rewrite though. That's probably the next big dev push. Right now we're rewriting the system catalog (meta) and the data VCS.
I ran a BBS in the 90s, nothing big but it had a small local community, some of them just users (lusers) and some of the sysops of other boards. I only had one phone line but call waiting would just kick the user off if I got a call. It was really easy to one up, I was running Renegade but there were quite a few different systems that you just basically turn on and you're up. I spent way too much time customizing each menu with ANSI art for each menu and trying to pimp out the UX. There were multiplayer games and file boards and message boards and you could live-chat with the sysop or other users if the board had multiple phone lines. My buddy called long distance to Kansas to some warez board to download a paint program and ran up a huge phone bill. It was magical and so much fun. Internet still has not achieved that kind of decentralized p2p in the mainstream. Plug a Raspberry Pi into your cable modem and build your own little board, give access to whoever you want. Would be pretty cool to me, but I don't know if I'm just old and nostalgic or if anybody else would actually want to do it. But yeah, wild wild west was the best.
There's a ton down this rabbit hole. One of the great anomalies of our industry is that we've used the database to bring coherence to countless "user domains", but never applied the same principles to our own stack. The benefits of doing so compound exponentially.
Hi HN, I'm Eric Hanson, the guy behind the Aquameta project (http://aquameta.org). With Aquameta, I'm trying to to break down the technical barriers between users and developers by putting the development stack in the database (PostgreSQL). Right now users edit data, and developers edit code, but with Aquameta, everything is data, so it opens up huge new frontier of possibilities. We're challenging the assumptions baked into Unix that date back to the 60's, that the file system is an acceptable way to organize the dev stack. It is not, and once you see the inefficiencies that the old paradigm has plagued us with, you can never unsee it. They are everywhere. By putting everything in the database, we gain a huge multiplier of interoperability and reusability, almost for free.
Aquameta has a functional IDE and is getting very close to a v0.3 release, the first release that users can easily download and install. I have a lot of ideas for how to monetize.
I am foremost a systems engineer, but I very much value biz dev as an essential part of bringing something into the world. We're mission driven, but missions don't get too far without the Benjamins. I'm looking for someone to flesh out the business side of things, someone with connections to the investment world, and skills in market strategy, sales and marketing. I'm currently in San Francisco. Hit me up at [email protected].
Agree about no-code. But UI that generates code is a pretty cool paradigm. For most common patterns, end users don't need to know that there's a bunch of boilerplate code under the hood, but if that isn't sufficient, that remaining 5% can be reached by just jumping into some auto-generated code that's readable and well-commented. Mere mortals can do the 95% themselves and then call in a wizard for the hard parts, or try to figure it out on their own. Plus, any non-generated solutions can be highlighted, so it builds up a record of the places where the UI fell short.