Clace – Secure hypermedia web applications using Starlark and go

Hacker News

Share card

Clace – Secure hypermedia web applications using Starlark and go

Hey, My name is Ajay. I have been working on a new open source project https://github.com/claceio/clace for the past few months. Clace is an Apache-2 licensed platform for building secure internal web applications. The end goal is to allow fully custom applications as well as workflow type applications. Custom apps are supported currently, workflows will come later. Clace allows you to build Hypermedia first web applications, where the server API returns HTML instead of JSON. With the HTMX[1] library on the client side, it makes developing and maintaining interactive websites much easier as compared to the regular Javascript SPA model. Background: My experience has been in distributed systems and data integration. I have seen the challenges companies face building and maintaining internal tools. Since internal tools generally do not have a large team building it, you want them to be as easy to build and maintain as possible. Since the tools generally have access to sensitive systems on the backend, you want them to be secure. Most security audits are done as part of the initial deployment, subsequent updates are not thoroughly reviewed, which is a security risk. Clace is built with these goals: - Enable development of secure internal web applications. The security policy should be set upfront and subsequently enforced by the platform. - Simplify ongoing maintenance of such apps by removing build and dependency related issues. Doing app code updates should be hassle-free, be it after six months or even six years. - Have flexible deployment options, allowing for use by individuals and teams with appropriate authentication and authorization policies at the the platform level. Technology: Clace is a single binary application, built in go, using sqlite for app metadata. Clace apps are written in Starlark [2], which gives a simple python based syntax. The API routes are defined to be Hypermedia first, each API specifies what HTML to return for a full page reload and what to return for a partial request from HTMX. Go HTML templates are used for the response. The starlark code runs in a sandbox, it can make external calls through plugins. The plugin boundary is used to enforce security policies[3]. This allows for policies like permit GET requests but not POST/DELETE, which are difficult to do with a container or jail based approach. Clace bundles esbuild to allow importing javascript libraries as ESModules. TailwindCSS/DaisyUI watcher integration is supported, although many simple apps can use classless CSS libraries. The goal is to have a no build approach, the dev artifacts are checked into git and directly used for serving prod. Importing new ESM libraries or new TailwindCSS classes requires a one time setup operation, which runs automatically in dev mode. Other than that, most code changes do not need a build step. Content hash based file names with a virtual file system is used, similar to hashfs[4]. This allow for aggressive static content caching, even without a build step doing file renames. For deployment, certmagic[5] is used for automatic TLS certs. App routing is supported based on path and/or domain, allowing for deployment flexibility. The plan is to allow plugins to be loaded dynamically using go-plugin[6], currently two plugins are built into the server, exec for running CLI command and http for REST API calls. Building UI for CLI tools and backend for frontend type use-cases are supported currently. https://github.com/claceio/clace/tree/main/examples/ has some simple sample apps (the _gen files are auto generated), the demo apps are running at https://demo.clace.io/ Ajay [1]: https://htmx.org/ [2]: https://github.com/google/starlark-go [3]: https://clace.io/docs/applications/appsecurity/#security-mod... [4]: https://github.com/benbjohnson/hashfs [5]: https://github.com/caddyserver/certmagic [6]: https://github.com/hashicorp/go-plugin