Bantamweight
This is an http4k and Svelte starter template, which is still under development. "Bantamweight" because it is a lighter stack but still packs a punch.
To get started, you should have JDK 11, nodejs (at least v14) and pnpm. If you don't want to use in-memory sqlite, install sqlite if needed and create a bantamweight.db.
Features
This app is still under development but it already includes a good part of the front and backend code for JWT auth, including token refresh with an httpOnly cooke, log-in and -out, password change, admin user management. On the auth side, the user signup and password reset flow is missing. Further features will be added to demonstrate other ways to do things with http4k and Svelte.
Backend
The app will use application-dev.yaml by default if a file path to application.yaml is not added to the ConfigDelegate.Kt file. You must also set, at a minimum, the BANTAMWEIGHT_DB_FILEPATH. There are a number of ways to override the yaml values. Use env variables such as APP__ENV or for another methods see hoplite. See Parameters below for list of every possible flag.
...start the backend
./gradlew runShadow
The app will be available at localhost:9000
New dependencies should be added to versions.properties, see refreshVersions
To make the app even lighter-weight, I have used sqlite with sqldelight. While sqldelight is easy to get started with and gives you typed queries. The migrations happen programmatically. It does not support all of sqlites's latest features. A more heavyweight ORM solution would be e.g. jooq plus flyway for migrations, which also supports other dbs like postgres well.
Command-line flags
| Flag | Meaning | Default Value |
|---|---|---|
APP__ENV |
Set "DEV" or "PROD" for backend config |
"DEV" |
APP__PORT |
Server port in development | 9000 |
DATABASE__FILE_PATH |
Path to the sqlite db file | "/data/bantamweight.db" |
DATABASE__USER__LAST_NAME |
Seed user last name | Super |
DATABASE__USER__FIRST_NAME |
Seed user first name | User |
DATABASE__USER__EMAIL |
Seed user email | [email protected] |
DATABASE__USER__PASSWORD |
Seed user password | password |
DATABASE__USER__ROLES |
Seed user roles | [admin] |
AUTH__SECRET |
Long random string for encrypting JWT tokens | changeme-[randomletters] |
AUTH__ROLES |
User roles | [admin, user] |
Docker build args
You can adjust behavior of the Docker container by passing these parameters with docker run -e:
| Environment Variable | Meaning |
|---|---|
GOOGLE_APPLICATION_CREDENTIALS |
Path to the Google storage credentials needed for storing replicas |
REPLICA_URL |
The address for Litestream to find the correct storage, e.g. gcs://bantamweight |
Frontend
...to run in development
cd frontend && pnpm install && pnpm run dev
This will proxy requests from the frontend through a development server. If you build the app with pnpm run build, you can see the app served from localhost:9000
This Svelte + Vite app is very light-weight in terms of bundle size. The dependencies have been kept to a minimum. The build also creates an public/assets-manifest.js file with a list of the static assets which can be used to precache resources in a service worker. I plan to add a service-worker starter in the future. SvelteKit is not used here because the story for SPA's at this point is fairly poor--it is more focused on server-rendered apps. This may change in the future.
If you feel the need for a Svelte component library, Carbon components Svelte is fairly large and has typescript definitions.
Deployment
Using the Dockerfile in the project root, the app can be run in a container and persist the sqlite database via Litestream at low-cost and without the need for a volume. Use any cloud providers that run docker images that you like, fly.io or Heroku are good choices (this app is deployed currently to Heroku). Litestream will replicate the database to a storage bucket like Google Cloud Storage. When the server is rebuilt, the database will be restored in the container. While this is easy and cheap, it is probably not what you want for highly-available apps where data-integrity and security is the first concern. In this case, you may want to consider a database outside of the container.
