Superconstellations

superconstellations.md

It's never been easier to elevate your latest project from your laptop to the Internet, allowing you to show your proof of concept to anyone with a simple url. However, some pieces of the puzzle have remained frustratingly difficult to place without relying on a paid service. For me, that piece was the persistence layer. I've always been a big fan of SQL, and Postgres in particular. Simple enough for the simplest MVP, and reliably consistent enough for business-critical data, it's a piece of tech I learned once and have used in every project since. Unfortunately, free database offerings are far less common than free static file hosts.

With Cosmonic, that's no longer a blocker for me. With their "super constellation" feature, I was able to expand the boundaries of my app's network all the way to my laptop. All it took was a quick download of the cosmo command line utility, followed by cosmo login and cosmo up! Just like that, a host was running on my machine and visible in my lattice. Next, I started an instance of PostgresSQL and the sqldb-postgres capability provider. By running the database and its associated provider locally, I skipped the hassle of adding another service provider to my list of requirements. After setting up the local components, the rest of the configuration steps were identical to running an app entirely within a single cosmonic host: I started the actors containing the app's behavior, linked them to the SQL capability provider, and configured a wormhole to allow HTTP access to the API.

The seamless integration of the hosts on my machine and in cosmonic's network was almost magical to me, but it is a natural consequence of the choice to use NATS as the underlying technology for their lattice. By leveraging this distributing message delivery framework, adding a host to the lattice is straightforward. A "leaf node" is
created on the machine or container meant to act as a host, and this node acts as the conduit through which all other nodes in the lattice are reachable. NATS documentation boasts that this pattern provides security by default - connections through the leaf node in either direction must be authenticated. In an environment with other networking capabilities disabled, entire categories of attacks are rendered toothless.

With the story out of the way, here are the steps I took to get started with super constellations (try to come up with better config variables than I did):

• Download the cosmo CLI tool

bash -c "$(curl -fsSL https://cosmonic.sh/install.sh)"

• Login and initialize a host on your machine (connecting to the lattice is automated!)

cosmo login
cosmo up

• Using the web interface, start the Postgres SQL provider on the newly created host

• Download and run the Postgres image

docker run -d -p 5432:5432 \
  -e POSTGRES_PASSWORD=password \
  -e POSTGRES_USER=username \
  -e POSTGRES_DB=db \
  postgres

• Verify connection string with psql (Also, run any database initialization scripts instead of forgetting and having to come back to this step)

docker run --network=host -it --rm \
  postgres psql postgresql://username:password@localhost:5432/db

• Create a base64-encoded config string for the link definitions between actors and the SQL provider (-w0 is critical when copying from your terminal!)

echo '{ "uri": "postgresql://username:password@localhost:5432/db" }' | base64 -w0

• Create actors on Cosmonic host (I used the petclinic demo) and any other providers/wormholes required for external access to the app

• Link the cosmonic-hosted actors to your locally hosted provider. In the provided key-value inputs, paste your encoded config as the value for the config_b64 key

• Visit your app! Cosmonic actors linked to your host's provider can query and persist data as if they're in the same network!