This the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Getting Started

Get ready to install things :D

This project requires basic command line knowledge

This section will lead you through different steps to get up and running in not time.

  • Checking Prerequirements
  • Getting the code
  • Installing dependencies
  • Building Backend and Frontend

This guide assumes you are using linux. The instructions easily transfer to other operating systems if you know your way around the tools used.

1 - Prerequirements

Checking and installing prerequirements

For this software to work you will need a few prerequirements:

  • Git
  • Go
  • Nodejs
  • Yarn

Git

You will need to have git to checkout the code we will use to build the software. As an alternative you could just download the main branch as .zip file and unzip it instead.

I am using the current git version:

❯ git --version
git version 2.30.0

Go

The backend is written in go. So you will need to get that and install it for your operating system. The version of go I am using as the time of writing is:

❯ go version
go version go1.17 linux/amd64

GCC

The backends sqlite library needs to use CGO. That’s why you will need gcc on your system. The version I use is:

❯ gcc -v
--- output ommited ---
gcc version 11.1.0 (GCC)

Read more about CGO here

NodeJS & npm

The frontend is written in SvelteKit. Therefore you will need to get NodeJS to build it. I am also using pnpm as a package manager. The Makefile which we will use in the next step is using pmpm. Therefore I recommend installing and using it.

As the time of writing I am using the following versions:

❯ node --version
v14.17.5

❯ pnpm
Version 6.13.0

All Prerequirements met?

Continue with the basic setup:

2 - Installation

Fetch the code and install DaSCR-Board

Fetch the code

Navigate to a folder where you want the app to reside in and clone it’s repository using git (or unzip the master.zip downloaded from GitHub Repo there):

git clone https://github.com/dascr/dascr-board
cd dascr-board

Content of the root directory

As this is a monorepo where the backend and the frontend reside, it might be a bit confusing at first. But fear not as I will describe how that works now.

.
├── api
├── config
├── database
├── docker-compose.yml
├── Dockerfile
├── frontend <--- Frontend App (SvelteKit)
├── game
├── go.mod
├── go.sum
├── LICENSE
├── logger
├── main.go
├── Makefile
├── player
├── podium
├── README.md
├── score
├── settings
├── throw
├── undo
├── uploads
├── utils
└── ws

Everything except the frontend folder is the backend app. The frontend Svelte app resides in the frontend folder. It is that easy.

Content of frontend folder for reference:

.
├── caddy
├── Dockerfile
├── jsconfig.json
├── node_modules
├── package.json
├── postcss.config.cjs
├── src
├── static
├── svelte.config.js
└── tailwind.config.cjs

DaSCR is using “.env”

What does that mean? There are different variables which are not read from a config file, but which are read from the environment. So you could for example do this:

export API_IP=0.0.0.0

This would set the variable API_IP used by the backend for this very session of your terminal. To ease the pain I am using .env files with my Makefile. Consider this as a kind of a config file itself.

So to use the Makefile you will need to create two files.

Backend

In the root folder of the project create a fille called .env. The content of it is:

API_IP=0.0.0.0
API_PORT=8000
DEBUG=FALSE

Here is the explanation of the content:

  • API_IP: This one will determine to which ip address the backend server is bound to. 0.0.0.0 means to any interface address. It could also read something like 192.168.1.X to bound it to a local network address.
  • API_PORT: This one will determine to which port the backend server is bound to.
  • DEBUG: This one will control how much output the application is giving you. Most of the time the value FALSE is good enough. But if you want to develop this you might want to choose TRUE instead.

Frontend

In the frontend folder also create a file called .env. The content of it is:

VITE_API_URL=http://localhost:8000/api
VITE_API_BASE=http://localhost:8000/
VITE_WS_URL=ws://localhost:8000/ws

This example reflects hosting it on a system in host only mode. You will not be able to use it other than on the system itself this way.

Here is the explanation of the content:

  • API_URL: This one points to the api endpoint of the backend which is protocol://ip address:port/api
  • API_BASE: This one points to the base address and has to match everything above but leaving out /api
  • WS_URL: This one points to the websocket endpoint of the backend. Instead of api it should read ws

Checked out code and created .env * 2?

Continue with building either one of those:

3 - Backend

Build the Backend API

Build using Makefile

To build the backend you can simply use the provided Makefile. Possible make targets to build the backend are:

  • build-linux_64
  • build-linux_386
  • build-mac
  • build-armv5
  • build-armv6
  • build-armv7 (Raspberry Pi 3 + 4)
  • build-armv8_64

So if you want to build on linux you for example issue:

❯ make build-linux_64
[*] go mod dowload
[*] Building for linux x64
[OK] App binary was created!
[OK] Your backend binary is at ./dist/<os>/

Now you have a binary ready to use:

dist
└── linux_amd64
    └── dascr-board

Windows?

In Windows you can also build this project. I tested it using MSYS2. After installing this I followed this instructions to setup my MSYS2 environment.

After setting up accordingly you can build like (from root directory of project within MSYS2 cli):

go mod download
go build -o dist/windows_amd64/dascr-board.exe

What’s next?

You could either run it right now using the Makefile (which will use the previously created .env file) and issue make run-dev-backend or run it like so (from the ./dist/<os>/ folder):

API_IP=0.0.0.0 API_PORT=8000 DEBUG=FALSE ./dascr-board

Want to have a Web UI?

  • Frontend: Go ahead and build the frontend

4 - Frontend

Build the Frontend Web UI

Build using Makefile

Your best bet is to use the Makefile on this, too. Just issue:

❯ make build-frontend
[*] Cleanup SvelteKit App
[OK] Cleanup done
[*] Building SvelteKit App

> dose@1.0.0 tailwind:build
> cross-env TAILWIND_MODE=build cross-env NODE_ENV=production postcss src/styles/tailwind.css -o src/styles/tailwind-output.css

warn - You have enabled the JIT engine which is currently in preview.
warn - Preview features are not covered by semver, may introduce breaking changes, and can change at any time.
Source path: redacted
Setting up new context...
Finding changed files: 3.293ms
Generate rules: 32.227ms
Build stylesheet: 0.688ms
Potential classes:  2550
Active contexts:  1
Content match entries 1126
JIT TOTAL: 113.848ms

> dose@1.0.0 build:only
> svelte-kit build

[... snip ...]

3:56:22 PM [vite-plugin-svelte] The following packages did not export their `package.json` file so we could not check the "svelte" field. If you had difficulties importing svelte components from a package, then please contact the author and ask them to export the package.json file.
- ky
103 modules transformed.

[... snip ...]

[dotenv][DEBUG] did not match key and value when parsing line 4:
vite v2.5.1 building SSR bundle for production...
transforming (70) .svelte-kit/build/runtime/internal/singletons.js

[... snip ...]

3:56:25 PM [vite-plugin-svelte] The following packages did not export their `package.json` file so we could not check the "svelte" field. If you had difficulties importing svelte components from a package, then please contact the author and ask them to export the package.json file.
- ky
105 modules transformed.
.svelte-kit/output/server/app.js   329.07 KiB

Run npm run preview to preview your production build locally.

> Using @sveltejs/adapter-static
done
[OK] SvelteKit App was built
[OK] Serve content of ./frontend/build via a webserver

Content of the build folder for reference

.
├── _app
├── css
├── favicon.ico
├── fonts
├── img
├── index.html
├── js
├── player
├── sounds
└── webfonts

What’s next?

Now everything left to do is to server the content of frontend/build via a webserver like Apache2, Nginx or Caddy2.

You could instead also run it right now using the Makefile (which will use the previously created .env file in frontend folder) and issue make run-dev-frontend.

Ready to throw darts?