DEV Community: Gunstein Vatnar

Pinball3DXMas

Gunstein Vatnar — Sun, 04 Dec 2022 09:04:27 +0000

Made my first version of Pinball3d (with a Christmas theme).
I had great fun making it and I learned a lot about Rust, Bevy, Rapier and Blender.
The webassembly takes some time to initiate things, but seems to work great when started.
It's not yet working on my phone (it won't even show up in the browser). Not sure why, but I'm working on it.
Using the possibility to say thanks to everyone providing the great tools I'm dependent on.

Screenshot:

Youtube:
https://youtu.be/kZw911cLr64

Github:
https://github.com/gunstein/Pinball3D

Webassembly:
https://pinball3d.vatnar.no/

Remark

The code is a bit messy, but I will eventually do some housekeeping and maybe write a short piece about the development process.

How I deployed Pinball2D to the Web using WebAssembly

Gunstein Vatnar — Fri, 04 Feb 2022 20:43:54 +0000

Introduction

In my previous article I wrote a short introduction to how I built Pinball2D using Bevy and Rapier.
When I upgraded Pinball2D to Bevy version 0.6 I realized it should be easy to deploy the game to web using WebAssembly.
I was not disappointed.

Summarized, I did the following:

First I built and tested the WebAssembly locally.
Then I built a Docker container with Nginx webserver and the WebAssembly.
In the end I deployed the Docker container to an Ubuntu Linode server with docker-compose.
I also made some efforts to reduce the size of the WebAssembly. I managed to reduce the size by 50% with the Binaryen toolkit.

The finished result

https://pinball2d.vatnar.no/

Source code

Sourcecode for Pinball2D on Github

More details

Installing some prerequisites

rustup target add wasm32-unknown-unknown

cargo install wasm-bindgen-cli

Build WebAssembly

cargo build --release --target wasm32-unknown-unknown

wasm-bindgen --out-name wasm_pinball2d --out-dir wasm/target --target web target/wasm32-unknown-unknown/release/pinball2d.wasm

Add an index.html file

I put an index.html in the wasm-directory created above.
Index.html presents the WebAssembly and gives some additional information.
I had to add some javascript code to force focus to the canvas. Keypress events are only sent to the canvas when the canvas is in focus. Basically, the launcher and flippers doesn't work if the WebAssembly canvas is not in foucs. There might be more elegant solutions to this problem.

<html>
  <head>
    <meta charset="UTF-8" />
    <style>
      body {
        background-color: black;
      }
      *:focus {
        outline: none;
      }
    </style>
  </head>
  <body>
    <h1 style="color:#009999;">Pinball2D</h1>
    <p style="font-size:14px; color:#009999; font-weight:bold; font-style:italic;">
        Launch ball: Space<br>
        Flippers: Left/Right arrow<br><br>
        <a href="https://github.com/gunstein/Pinball2D" target="_blank">https://github.com/gunstein/Pinball2D</a>
    </p>
  </body>
  <script type="module">
    import init from './target/wasm_pinball2d.js';
    async function run(){
        await init()

    }
    run();
  </script>

  <script>
    //Force focus to game-canvas.  
    const targetNode = document.documentElement || document.body;
    const config = {childList: true, subtree: true};

    const callback = function(mutationsList, observer) {
        for(let mutation of mutationsList) {
            if (mutation.type === 'childList') {
                // Elements have changed
                let canvas = document.querySelector("canvas");
                if (canvas !== null)
                {
                    canvas.focus();
                    canvas.onblur = function() {
                    var me = this;
                    setTimeout(function() {
                    me.focus();
                    }, 50);
                }
                }
            }
        }
    };

    const observer = new MutationObserver(callback);
    observer.observe(targetNode, config);
  </script>
</html>

Test WebAssembly locally

Install basic-http-server

cargo install basic-http-server

Run basic-http-server with WebAssembly

basic-http-server wasm

Build a docker container

Dockerfile

The dockerfile is used to build a Docker container that is using Nginx as webserver. The wasm directory is copied into the image with the COPY command.

FROM nginx:stable-alpine
COPY wasm /usr/share/nginx/html

Building the container

docker build -t pinball2d .

docker tag pinball2d:latest gunstein/pinball2d:latest

Test the container locally

It's easy to test the container locally before deploying.

docker run -p 8080:80 pinball2d

Push to DockerHub

docker push gunstein/pinball2d:latest

Deploy to server

I use docker-compose to deploy my Pinball2D container. Traefik, reverse proxy, makes certificate handling and other boring stuff much easier. I described more thorough about a similar deployment in this article.
Here's my docker-compose.yml file:

version: "3.8"

services:
  traefik:
    image: "traefik:v2.6"
    container_name: "traefik"
    command:
      # - "--log.level=DEBUG"
      # - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.myresolver.acme.tlschallenge=true"
      - "--certificatesresolvers.myresolver.acme.email=my_email@email.com"
      - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
      # redirect port 80 -> 443
      - "--entrypoints.web.address=:80"
      - "--entrypoints.web.http.redirections.entryPoint.to=websecure"
      - "--entrypoints.web.http.redirections.entryPoint.scheme=https"
      - "--entrypoints.web.http.redirections.entrypoint.permanent=true"
    ports:
      - "443:443"
      - "80:80"
      # - "8080:8080"
    volumes:
      - "./letsencrypt:/letsencrypt"
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  pinball2d:
    image: gunstein/pinball2d:latest
    container_name: "pinball2d"
    restart: always
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.pinball2d.rule=Host(`pinball2d.vatnar.no`)"
      - "traefik.http.routers.pinball2d.entrypoints=websecure"
      - "traefik.http.routers.pinball2d.tls.certresolver=myresolver"
      # use compression
      - "traefik.http.routers.pinball2d.middlewares=test-compress"
      - "traefik.http.middlewares.test-compress.compress=true"

Reduce size of WebAssembly

After some testing of the WebAssembly I started to wonder if the size could be reduced. The default release build is approximately 15MB.
First I tried adding some options to Cargo.toml.
For example:

[profile.release]
opt-level = 'z'

It didn't save that much for this WebAssembly. Around 1MB.

Then I installed the Binaryen toolkit and ran it with options to reduce size aggressively.

sudo apt install binaryen
wasm-opt -Oz -o wasm_pinball2d_bg_small.wasm wasm_pinball2d_bg.wasm

That was successful, in my opinion.
The size of the WebAssembly was reduced with close to 50%.
(I'm not seeing the same size reduction after upgrading to Bevy version 0.7. It's more like 30% now, it seems, but I have not used much effort investigating this.)
Read more about WebAssembly shrinking here

A simple 2D pinball game made with Rust, Bevy and Rapier

Gunstein Vatnar — Mon, 11 Oct 2021 20:40:00 +0000

Introduction

I hope this simple pinball game can be an introduction for beginners to both the Bevy game engine and the Rapier physics engine.
Here I share a few details about how I implemented Pinball2D.

NB! Some knowledge of the Rust programming language is necessary.

Short video of Pinball2D in action:

Source code

Sourcecode for Pinball2D on Github

Running the game on the web using WebAssembly

https://pinball2d.vatnar.no/
How to build this WebAssembly will be described in part 2.

Running the game

Rust and Cargo is a prerequisite.

git clone https://github.com/gunstein/Pinball2D.git
cargo run --release

Launch ball with space and move flippers with left and right arrow.

Main links for information about Bevy and Rapier

Disclaimer

This is neither a Bevy nor a Rapier tutorial, but a description of a simple demo game that I missed when I started out with Bevy and Rapier.
There's lots of room for improvements, but I still think it works as an introduction.

Organization

I recommend to use plugins and keep each plugin in a separate file. In my opinion this is tidy and intuitive.

Pinball2D has a startup system in every plugin.

impl Plugin for WallsPlugin {
    fn build(&self, app: &mut AppBuilder) {
        app
            .add_startup_system(spawn_walls);
    }
}

Setting up the board

I chose 640px/360px for the size of the game area. This makes up the Bevy coordinate system of the game. Origo in the middle (0,0), x-axis[-180, 180] and y-axis[-320, 320]. (See figure below.)
In earlier versions of bevy_rapier2d (before version 0.13) it was important to keep all sizes and coordinates in meters. That is not correct anymore. You should now use pixels for all sizes and tell Rapier how many pixels there is in a meter.

.add_plugin(RapierPhysicsPlugin::<NoUserData>::pixels_per_meter(PIXELS_PER_METER))

Since Pinball2d already was using all sizes in meters (and since I'm lacy) I decided to define a global const PIXELS_PER_METER and use this const to compute all sizes and coordinates in pixels from meters.

pub const PIXELS_PER_METER : f32 = 492.3;

Example of usage:

let ball_pos = Vec2::new(crate::PIXELS_PER_METER * 0.3, crate::PIXELS_PER_METER * -0.2);

Spawning wall elements

I use bevy_prototype_lyon to create shapes
https://github.com/Nilirad/bevy_prototype_lyon

The basic process of creating a wall element:

Create a shape. Bevy-coordinates is needed, so I scale from rapier coordinates.
Make a geometry with the created shape and add a collider to a rigid body when spawning an entity for the wall element. (Colors and other drawing options are added when you create the geometry).

A wall is a static body. Most of the wall colliders should be solid. The exception is the bottom wall collider which is a sensor. A sensor collider will not influence other objects, but emit events when intersections occur. I despawn the ball when the bottom wall is hit and respawn the ball just above the launcher.

Rapier's documentation on colliders must be read:
https://www.rapier.rs/docs/user_guides/bevy_plugin/colliders

Below, the bottom wall is spawned. The collider is a sensor.

    let shape_top_and_bottom_wall = shapes::Rectangle {
        extents: Vec2::new(crate::PIXELS_PER_METER * 0.73, crate::PIXELS_PER_METER * 0.03),
        origin: shapes::RectangleOrigin::Center
    };

    //Spawn bottom wall
    let bottom_wall_pos = Vec2::new(0.0, crate::PIXELS_PER_METER * -0.64);
    commands
        .spawn((
            ShapeBundle {
                path: GeometryBuilder::build_as(&shape_top_and_bottom_wall),
                ..default()
            },
            Fill::color(Color::TEAL),
        ))
        .insert(RigidBody::Fixed)
        .insert(Collider::cuboid(
            shape_top_and_bottom_wall.extents.x / 2.0,
            shape_top_and_bottom_wall.extents.y / 2.0,
        ))
        .insert(Sensor)
        .insert(Transform::from_xyz(
            bottom_wall_pos.x,
            bottom_wall_pos.y,
            0.0,
        ))
        .insert(BottomWall);

Flippers

The flippers are spawned much the same as walls, but are KinematicPositionBased bodies. I keep different movement systems for the right and the left flipper. For every frame it's checked if the flipper key is pressed. Next rotation angle will be set accordingly and clamped to a sensible value.

#[derive(Component)]
struct LeftFlipper{
    point_of_rotation : Vec3,
    curr_angle : f32,
 }

fn left_flipper_movement(
    keyboard_input: Res<Input<KeyCode>>,
    mut left_flippers: Query<(&mut LeftFlipper, &mut Transform), With<LeftFlipper>>,
) {
    for (mut left_flipper, mut left_flipper_transform) in left_flippers.iter_mut() {
        let mut new_angle = left_flipper.curr_angle;
        let change_angle:f32;

        if keyboard_input.pressed(KeyCode::Left)
        {
            change_angle = 0.09;
        }
        else
        {
            change_angle = -0.07;
        }

        new_angle += change_angle;
        let new_clamped_angle = new_angle.clamp(-0.3, 0.3);
        let pivot_rotation = Quat::from_rotation_z(new_clamped_angle - left_flipper.curr_angle);
        left_flipper_transform.rotate_around(left_flipper.point_of_rotation, pivot_rotation);   
        left_flipper.curr_angle = new_clamped_angle;     
    }
}

Pins

Pins are much like wall objects but change color for a second when hit.
I respawn the hit pin to change color. I would have prefered to change it's color without respawning, but couldn't make it work.
The Pin component struct:

#[derive(Component)]
struct Pin{
    timestamp_last_hit : f64,
    position : Vec2,
}

The code below shows how contact events are handled. If the event received is of type "Started" and one of the participants in the event is a pin, then the pin will respawn.

fn handle_pin_events(
    query: Query<(Entity, &Pin), With<Pin>>,
    time: Res<Time>,
    mut contact_events: EventReader<CollisionEvent>,
    mut commands: Commands
) {
    for contact_event in contact_events.iter() {
        for (entity, pin) in query.iter() {
            if let CollisionEvent::Started(h1, h2, _event_flag) = contact_event {
                if h1 == &entity || h2 == &entity {
                    //Respawn to change color
                    let pos = pin.position;
                    let timestamp_last_hit = time.seconds_since_startup();
                    commands.entity(entity).despawn();
                    spawn_single_pin(&mut commands, pos, Some(timestamp_last_hit));
                }
            }
        }
    }
}

Ball

The ball is the only entity with a dynamic rigid body type.
Spawning is still similar to other entities:

fn spawn_ball(mut commands: Commands) {
    let ball_pos = Vec2::new(
        crate::PIXELS_PER_METER * 0.3,
        crate::PIXELS_PER_METER * -0.2,
    );

    let shape_ball = shapes::Circle {
        radius: crate::PIXELS_PER_METER * 0.03,
        center: Vec2::ZERO,
    };

    commands
        .spawn((
            ShapeBundle {
                path: GeometryBuilder::build_as(&shape_ball),
                ..default()
            },
            Fill::color(Color::BLACK),
            Stroke::new(Color::TEAL, 2.0),
        ))
        .insert(RigidBody::Dynamic)
        .insert(Sleeping::disabled())
        .insert(Ccd::enabled())
        .insert(Collider::ball(shape_ball.radius))
        .insert(Transform::from_xyz(ball_pos.x, ball_pos.y, 0.0))
        .insert(ActiveEvents::COLLISION_EVENTS)
        .insert(Restitution::coefficient(0.7))
        .insert(Ball);
}

Two things to mention from the code above:

Setting the ActiveEvents::COLLISION_EVENTS bit to 1 enables the collision events involving the collider.
Restitution is a measure for how bouncy the ball is.

The ball is respawned above the launcher when it hits the bottom wall.

fn handle_ball_intersections_with_bottom_wall(
    rapier_context: Res<RapierContext>,
    query_ball: Query<Entity, With<Ball>>,
    query_bottom_wall: Query<Entity, With<BottomWall>>,
    mut commands: Commands
) {
    let mut should_spawn_ball = false;

    for entity_bottom_wall in query_bottom_wall.iter() {
        for entity_ball in query_ball.iter() {
            /* Find the intersection pair, if it exists, between two colliders. */
            if rapier_context.intersection_pair(entity_bottom_wall, entity_ball) == Some(true) {
                commands.entity(entity_ball).despawn();
                should_spawn_ball = true;
            }
        }
    }

    if should_spawn_ball
    {
        spawn_ball(commands);
    }
}

Launcher

The launcher works very much like a flipper, but there is obviously no rotation involved.

fn launcher_movement(
    keyboard_input: Res<Input<KeyCode>>,
    mut launchers: Query<(&mut Launcher, &mut Transform), With<Launcher>>,
) {
    for (launcher, mut launcher_transform) in launchers.iter_mut() {
        let mut next_ypos = launcher_transform.translation.y;

        if keyboard_input.pressed(KeyCode::Space)
        {
            next_ypos = next_ypos + crate::PIXELS_PER_METER * 0.04;
        }
        else
        {
            next_ypos = next_ypos - crate::PIXELS_PER_METER * 0.04;
        }   
        let clamped_ypos = next_ypos.clamp(launcher.start_point.y, launcher.start_point.y + crate::PIXELS_PER_METER * 0.05);
        launcher_transform.translation.y = clamped_ypos;    
    }
}

How I put my demo into production with Docker compose and Traefik

Gunstein Vatnar — Mon, 08 Feb 2021 06:35:49 +0000

Overview

In my previous article I described my simple demo-application, StellarGallery. A simple frontend for an art gallery where users can buy art using stellar cryptocurrency. The backend keeps track of orders and let customers download a high resolution image when payment is received.

This article is about what my production architecture looks like and how I build my docker containers. Even though the domain is a little bit uncommon, the production architecture should be common. A React SPA and a Golang Server.

Keywords: Docker, Docker Compose, Traefik( https, Letsencrypt, redirect port 80->443, gzip compression), substitution of api url in client image at container startup.

Concept

In earlier projects I would have Dockerhub do the builds automatically after github updates, but this is now a paid option at Dockerhub so here I use a more manual approach.
I build docker images on my laptop and push them to DockerHub. I'm not planning on frequent updates and it's just a demo so I think its okay for now.
My production server is a Linode machine running Ubuntu. I will describe the setup details in the Details section below.

Figure showing the container building process:

Details

Setup of Linode server

OS

Ubuntu 20.04 LTS

Docker

Followed these instructions

Docker Compose

Followed these instructions

Client Dockerfile

The Dockerfile for the React client is pretty common, I think.

Multi-stage build to make the build as small as possible.

#Build Stage Start

#Specify a base image
FROM node:alpine as builder

#Specify a working directory
WORKDIR '/app'

#Copy the dependencies file
COPY package.json .

#Install dependencies
RUN npm install

#Copy remaining files
COPY . .

#Build the project for production
RUN npm run build

#Run Stage Start
FROM nginx

#Copy production build files from builder phase to nginx
COPY --from=builder /app/build /usr/share/nginx/html

EXPOSE 80

This is how I build my Dockerfile and push it to DockerHub:

docker build -t client_stellar_gallery .
docker tag client_stellar_gallery:latest gunstein/client_stellar_art_gallery:latest
docker push gunstein/client_stellar_art_gallery:latest

Server Dockerfile

Pretty plain Dockerfile for Go, I guess, but I want to mention some hassle I had.

Originally I wrote the server to use SQLite as database. It worked well when run on my laptop, but gave me plenty of trouble when run in a Docker container on my Linode server. To build a container with SQLite I had to make a static build. My understanding is that this is because SQLite needs glibc. I used this build command in my Dockerfile:

RUN go build -a -ldflags "-linkmode external -extldflags '-static' -s -w" -o server_stellar_gallery main.go

The build command worked ok, but my server crashed at the strangest places when run in the container. I think the crashes were caused by some glibc conflicts.

In the end I gave up and converted to PostgreSQL. The ORM I'm using is Gorm which is using the pgx, a pure Go driver for PostgreSQL. This worked like a charm. To me, it seems like a good rule to avoid static builds if possible.

I also want to explain the last line in my Dockerfile, CMD ["--account_public_key"]. The string is just a placeholder and is supposed to be overridden in the Docker-compose.yml file.

FROM golang:latest as builder

WORKDIR /app
COPY . .

RUN go get -d -v ./...
RUN go install -v ./...

RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o server_stellar_gallery .

#FROM scratch
FROM centos:latest
COPY --from=builder /app/server_stellar_gallery /

# Copy CA certificates to prevent x509: certificate signed by unknown authority errors
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt

EXPOSE 5000
ENTRYPOINT ["/server_stellar_gallery"]
CMD ["--account_public_key"]

This is how I build my Dockerfile and push it to DockerHub:

docker build -t server_stellar_gallery . 
docker tag server_stellar_gallery:latest gunstein/server_stellar_art_gallery:latest
docker push gunstein/server_stellar_art_gallery:latest

Docker-compose

I would have thought my docker-compose.yml file to be an ordinary one, but I must admit that I had some trouble creating it and especially the stuff involving Traefik was a challenge. It seems to me that configuring Traefik has evolved a bit and this must be considered when looking at examples.
I chose to set up redirection from port 80->443 and connecting middleware for compression to the frontend. This seems to be considered best practice for frontends. At least Lighthouse gives you credit for implementing these things.

I really like Traefik. They seem to have achieved their vision of simplifying networking. From a programmers point of view it's pleasant to be released of all the burden setting up for example https, letsencrypt, port redirection and response-compression.

One last thing to mention:
After docker-compose up -d is run I have to substitute the placeholder API_URL in the client build. (The placeholder exists in the .env file in the client project.)
I use this command:

docker-compose exec -w /usr/share/nginx/html/static/js client_stellar_art_gallery bash -c "sed -i 's,__API_URL__,https://galleryapi.vatnar.no,g' *"

I never found a way to run this command in the docker.compose.yml file so instead I made a script first running docker-compose up -d and then the command above. It's working, but it feels like the last command could be set up in the docker-compose.yml file.

Here's my docker-compose.yml file:

version: "3.8"

services:
  traefik:
    image: "traefik:v2.4"
    container_name: "traefik"
    command:
      # - "--log.level=DEBUG"
      # - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.myresolver.acme.tlschallenge=true"
      - "--certificatesresolvers.myresolver.acme.email=my_email@email.com"
      - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
      # redirect port 80 -> 443
      - "--entrypoints.web.address=:80"
      - "--entrypoints.web.http.redirections.entryPoint.to=websecure"
      - "--entrypoints.web.http.redirections.entryPoint.scheme=https"
      - "--entrypoints.web.http.redirections.entrypoint.permanent=true"
    ports:
      - "443:443"
      - "80:80"
      # - "8080:8080"
    volumes:
      - "./letsencrypt:/letsencrypt"
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  client_stellar_art_gallery:
    image: gunstein/client_stellar_art_gallery:latest
    container_name: "client_stellar_art_gallery"
    restart: always
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.client_stellar_art_gallery.rule=Host(`gallery.vatnar.no`)"
      - "traefik.http.routers.client_stellar_art_gallery.entrypoints=websecure"
      - "traefik.http.routers.client_stellar_art_gallery.tls.certresolver=myresolver"
      # use compression
      - "traefik.http.routers.client_stellar_art_gallery.middlewares=test-compress"
      - "traefik.http.middlewares.test-compress.compress=true"

  postgres:
    image: postgres
    container_name: "postgres"
    restart: always
    environment:
      POSTGRES_PASSWORD: postgres
    volumes:
      - ./dbdata:/var/lib/postgresql/data

  server_stellar_art_gallery:
    image: gunstein/server_stellar_art_gallery:latest
    container_name: "server_stellar_art_gallery"
    depends_on:
      - "postgres"
    restart: always
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.server_stellar_art_gallery.rule=Host(`galleryapi.vatnar.no`)"
      - "traefik.http.routers.server_stellar_art_gallery.entrypoints=websecure"
      - "traefik.http.routers.server_stellar_art_gallery.tls.certresolver=myresolver"
    command: "-account=GBGJFGCDZHQ3LXJOUK7EOZB77OR2GMES3FVQRK4M724THUDLZLP7J6A7"

Send and receive payments with the stellar cryptocurrency

Gunstein Vatnar — Thu, 04 Feb 2021 16:37:20 +0000

Background

I made a simple demo to convince my self that cryptocurrency for e-commerce might not be so hard.
Hopefully I can convince others too.

A bit about the demo

The demo is a gallery web app showing some images. Customers can order an image and will receive payment information. Customers send payments to the gallery via the Stellar network. When the payment is received, by the gallery, an image with high resolution will be available to the customer.

I chose Stellar, stellar.org, as cryptocurrency. Stellar provides fast and cheap transactions and good api's. I use their test network. That basically means trading with monopoly money.

Disclaimer: Please be very skeptic about security in my system. It's really just an example of how to send and receive payments with stellar.

Concept

Server starts up and begin to listen for payments received by the gallery's stellar account. An incoming payment marks an order as paid.

A typical client-server interaction could be:

Client collects thumbnail art from server.
Client makes an order to server and get a memo and downloadkey in response.
Client starts a SSE, Server Sent Event, stream/channel to the server. This stream is used for listening on payments received by the server.
Client makes payment to the gallery account with the received memo.
Client is noticed that server has received payment.
Client queries server for "big image url" and provides both memo and downloadkey. If order is marked as paid, at the server, the client will receive the url.
Client download high resolution image from image server.

The client also has functionality for making a stellar account and fund it with "monopoly money". (The funding part is off course only possible on the stellar test network.)

Below is a drawing of what I tried to describe above.

The basics:

Client

A react app. Started out with https://create-react-app.dev/.
If you know React it shouldn't be hard. I avoided redux, react-router and axios to keep things simple. Instead I use context for state and simple routing. Fetch is used for communication with backends.

The payment page needs some explanation

It's not relevant for an e-commerce site to make an account and automagically fill it with money.
I guess, in most cases customers would pay with a wallet on their phone. So the payment page is a little weird.
If you notice the account balance changes with more than the price of the piece of art, that is caused by the transaction fee.
I've copied most of the "interact with stellar" code from here

This is how easy it is to create and fund an account:

export async function createAccount() {
  const pair = StellarSdk.Keypair.random();
  try {
    const response = await fetch(
      `https://friendbot.stellar.org?addr=${encodeURIComponent(
        pair.publicKey()
      )}`
    );
    const responseJSON = await response.json();
    console.log("SUCCESS! You have a new account :)\n", responseJSON);
    return pair;
  } catch (e) {
    console.error("ERROR!", e);
  }
}

Server

Made with Go.

Main imports and components

Gin Web Framework
Gorm to make database handling easier.
PostgreSQL

Some details

A goroutine handling incoming payments is fired up at startup. It's listening on an SSE stream from the stellar network and receives all payments for the gallery account. I'm using the horizonclient for the payment streaming. If the payment is ok the order will be marked as paid and the memo, which is the orderid, will be broadcasted to all clients. The clients have to decide for them selves if the memo is meant for them. The security is in the downloadkey. Clients will not get the "big file url" without the right combination of downloadkey and memo.

The goroutine listening for payments:

go func(){
  for{
    //Start listening for payments on the shops account
    client := horizonclient.DefaultTestNetClient
    opRequest := horizonclient.OperationRequest{ForAccount: *account_publickey}
    err := client.StreamPayments(context.Background(), opRequest, controllers.CreatePaymentHandler(broadcaster, *account_publickey, client))
    if err != nil {
      fmt.Println(err)
    }
  }
}()

The clients are notified by SSE. Alle clients receive all memos.
Streams to clients are handled by gin:

r.GET("/stream", func(c *gin.Context) {
  ch := make(chan interface{})
  broadcaster.Register(ch)
  defer broadcaster.Unregister(ch)

  c.Writer.Header().Set("Access-Control-Allow-Origin", "*")
  c.Writer.Header().Set("Content-Type", "text/event-stream")
  c.Writer.Header().Set("Cache-Control", "no-cache")
  c.Writer.Header().Set("Connection", "keep-alive")
  c.Writer.Header().Set("Transfer-Encoding", "chunked")
  c.Writer.Flush()
  c.Stream(func(w io.Writer) bool {
    // Stream message to client from message channel
    if msg, ok := <-ch; ok {
      c.SSEvent("message", msg)
      return true
    }
    return false
  })
})

Setting up the demo for "production"

I've used the cheapest Linode-server with ubuntu 20.04, docker and docker-compose.
Traefik, reverse proxy, is handling https and Letsencrypt certificates.
The Dockerfiles are in their respective github repositories. (Links are in the beginning of this article.)
I've already mentioned that the database is PostgreSQL.
Maybe I'll write some more about this setup later.

From here

Maybe I should add an admin page for adding new art? I don't want every visitor to be able to perform this action.
This article describes an interesting authentication concept I consider using.