Skip to main content

Introduction

HivePrint is composed of different applications.

  1. Website - hiveprint.ca
  2. HivePrint Web Client - tenantid.hiveprint.ca
  3. HivePrint Server - hiveprint.app
  4. HivePrint Docs - docs.hiveprint.ca
  5. HivePrint App Docs - docs.hiveprint.app
  6. HivePrint Pi - installed on each pi.

Overview​

The main HivePrint application is composed of three main apps: HivePrint Pi, HivePrint Server, and HivePrint Web Client.

HivePrint Pi​

This code runs on each individual SBC (Single Board Computer). These are typically Raspberry Pi's, but we recently have RockPi support as well as Pi Zero's. The application works with Klipper firmware only at this point in time. Future support for Octoprint or Marlin may be in the work.

The pi code is relatively simple and is mostly responsible for sending information about the printer to the server (HivePrint Server). The communication protocol is Socket.io. The main strategy for the pi code is to ensure that it remains as dumb as possible. We want the server to do all the logic. This will help ensure that the code running on the pi is not too intense. It also limits the amount of IP that is on 3rd party systems.

Read more about HivePrint Pi.

public facing documentation.

HivePrint Web Client​

The HivePrint Web Client is responsible for reading information from HivePrint Server, and sending API calls to HivePrint Server. The .env file controls a lot of where things are sent from the client.

If the environment is not production (local, preview, etc), there is no authentication.

Note

This is an internal environment variable, not pertaining to what Vercel calls their environments. IE, our tenants are deployed on "preview" environments in Vercel, but they have the environment variable of ENVIRONMENT set to production. This forces authentication.

The architecture is using NextJS 13.x on the App router. We use NextAuth for authentication. We interface with AWS for S3 access, and write to a hiveprint-users table for NextAuth. We support different authentication providers.

The entrypoint for HivePrint Client is the middleware.ts file. This executes on every single request. The strategy is to ensure that if its a Production environment we are checking the subdomain against the user's (NextAuth User table) organization id. If they match, allow, if they don't deny access.

The next entrypoint is app/, and follows conventional NextJS. We use server components wherever possible, and then render client components as children passing in any values. We use the NextJS api to proxy against the HivePrint Server so we can add authentication without having to expose our credentials. We may also massage requests in the internal api.

All API routes are in /pages. This uses NextJS's built in API server. This is for security as well as data massaging. These api calls call the HivePrint Server api.

Each second, the HivePrint Web Client polls the HivePrint Server asking for the latest PrinterUpdateObject. This is what comes down and gets passed to all the printer cards. The information updates, causing a re-render, thus updating the information.

At time of writing, this flow is being improved upon.

Hiveprint Server​

The server is the liason between the HivePrint Pi's and the HivePrint Web Client. It takes data from the pi, massages it into a server variable that is stored in memory. On an interval, this printer object is written to the database. The printer object is a blob of all the printers, stringified into one database column called data.

Up until recently, all printer information was stored in the data column. A recent initiative is to split that out into metadata and the original printer data.