Clace: Secure web application development platform using Starlark

[Ajay Kidave]

Hey,

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.

Clace is a single binary go application, using sqlite for app metadata. Clace apps are written in Starlark [2], which gives a python based syntax. The API routes are defined to be Hypermedia first, using the Chi library[7]. 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 sample apps are running online at https://demo.clace.io/

If you are building Web interfaces with Go HTML templates, I believe Clace will make the development process much easier. Do try it out and let me know any feedback.

Regards
Ajay

[1]: https://htmx.org/
[2]: https://github.com/google/starlark-go
[3]: https://clace.io/docs/applications/appsecurity/#security-model
[4]: https://github.com/benbjohnson/hashfs
[5]: https://github.com/caddyserver/certmagic
[6]: https://github.com/hashicorp/go-plugin

[7]: https://github.com/go-chi/chi

[Jason E. Aten]

I would just be aware that using software that is MPL licensed,

https://github.com/hashicorp/go-plugin/blob/main/LICENSE

means that nobody with commercial aspirations will touch your stuff. In practice, that means relatively little adoption.

[TheDiveO]

sadly, OpenDoufu(*) is the epitaph of HashiCorp breaking bad. So that go-plugin package is a no-go now (pun intended).

(*) I can't get myself using the British Empire misspelling of Standard Chinese (putonghua). And don't call that Ma... either.

[Ajay Kidave]

Clace itself is Apache-2 licensed, using a MPL licensed library in an Apache-2 licensed project is fine from what I understand. I do not plan to make any code changes to the go-plugin code. The go-plugin library is specifically allowed by CNCF projects if that matters https://github.com/cncf/foundation/blob/main/license-exceptions/cncf-exceptions-2023-06-27.json#L3.

The intent in Clace is to allow multiple versions of a plugin to be usable for backward compatibility. That, plus the security and stability benefits of the out of process model make the go-plugin approach work better than the .so/.dll approach.

Ajay

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/FyaMylLPGEw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d56f9aab-19f8-40d4-87a5-59d05e1adb9fn%40googlegroups.com.

[Jason E. Aten]

I'm surprised by that claim. I seriously doubt, from reading the licenses, that you can legally use the Apache2 license, since

it removes the MPL requirements; which the MPL forbids you from doing.  

Moreover I don't think a court would consider relevant what the Cloud Native Foundation thought was "okay".

[Dan Kortschak]

On Mon, 2023-10-30 at 18:43 -0700, Jason E. Aten wrote:
> I'm surprised by that claim. I seriously doubt, from reading the
> licenses, that you can legally use the Apache2 license, since
> it removes the MPL requirements; which the MPL forbids you from
> doing.  
>

The Mozilla FAQ https://www.mozilla.org/en-US/MPL/2.0/FAQ/ appears to
think it's OK.

> Q13: May I combine MPL-licensed code and BSD-licensed code in the
> same executable program? What about Apache?
>
> Yes to both. Mozilla currently does this with BSD-licensed code. For
> example, libvpx, which is used in Firefox to decode WebM video, is
> under a BSD license.

[TheDiveO]

Unfortunatelly, "okay" hasn't been tested in court yet and especially with HashiCorp breaking bad you surely have the deep pockets to see this through?

[Dan Kortschak]

On Mon, 2023-10-30 at 23:29 -0700, TheDiveO wrote:
> Unfortunatelly, "okay" hasn't been tested in court yet and especially
> with HashiCorp breaking bad you surely have the deep pockets to see
> this through?

This is not really my problem, I was just pointing out that the authors
of the license have publicly stated that they think they are
compatible.

[Jason E. Aten]

On Tuesday, October 31, 2023 at 3:12:13 AM UTC Dan Kortschak wrote:

The Mozilla FAQ https://www.mozilla.org/en-US/MPL/2.0/FAQ/ appears to
think it's OK.

> Q13: May I combine MPL-licensed code and BSD-licensed code in the
> same executable program? What about Apache?
>
> Yes to both. Mozilla currently does this with BSD-licensed code. For
> example, libvpx, which is used in Firefox to decode WebM video, is
> under a BSD license.

That is the other way around, not the situation under discussion. i.e. There is a difference

between Apache input1 + MPL input2 -> MPL (for the combined output work), versus

Apache input1 + MPL input2 -> Apache licensed combination.  The wikipedia article

https://en.wikipedia.org/wiki/Mozilla_Public_License is fairly clear that even

if you put the output under Apache, it is not really under Apache, because the MPL

files have to still be under MPL. All you've really done at that point is to mislead the developer who

uses your stuff into thinking that they have fewer compliance requirements than

they actually do.

"Recipients can combine licensed source code with other files under a different, even proprietary license, thereby forming a "larger work" which can be distributed under any terms, but again the MPL-covered source files must be made freely available.^[7]"

where the footnote is:

[7] https://www.mozilla.org/en-US/MPL/2.0/FAQ/ 

Anyway. People divide into two camps on this. If you are working on open source software, 

you don't care. You can afford to be sloppy with the licensing. Nobody is going to come after

you because you work is open source in the end.

Commercial developers just avoid MPL and any uncertainty, and get on with their work. Nobody

bothers to talk about it because it an issue just best avoided by not using MPLed software at all.

[Dan Kortschak]

Fair enough. Thanks for clarifying.