The past month has been a blur. I’ve been working on a project to host and share p5.js sketches and to facilitate live community creative coding events. I’ve written 6000 lines of code and the first demo is live.

This first release focuses on “Jams” a time-bounded event where users can leave, join and post sketches. When a new Jam is created, a “Kahoot-like” join code is generated and displayed to the jam creator. Now your friends can punch this short code into the join menu and start making posts. A preliminary featured post is shown in the background of the landing page.

Posts take the form of a p5 sketch that is currently limited to a 360x360px window and a 255 character description. The post editor provides a simple development environment with a live preview of the p5 sketch being updated. It even has Vim bindings!

Code Jam Page A Jam with one post

Editor The post editor

Users are currently created and managed with Github OAuth, though I’m not very happy with the login UX.

How it works

As the feature description may hint, this is a CRUD app with a REST api and an SQL database. Sketches are stored as strings then templated into pages which are requested by iframes on the frontend.

I unfortunately made the choice to use Prisma which I have regretted for its opinionated take on database interfacing. I’ve also heard that it does N+1 queries with the include clause which doesn’t yet matter at my scale but still annoys me. The two upsides to prisma are its ability to generate types on your data model and easy switching between database backends. I’m using SQLite for everything right now and have full confidence that I could quickly switch to Postgres without breaking my test or dev databases.

Authentication is done using an OAuth github app and Lucia. Bearer tokens are attached via a series of redirects and a user confirmation. Then I can parse the cookies and attach a userId and authentication status to the request context using some simple middleware.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

return (
  new Elysia()
    .decorate("JamService", new JamService())
    // this parses cookies!
    // and adds { isAuth: boolean, userId: string} to the context
    .derive(auth)
    // these routes require authentication
    .guard({
      beforeHandle: async ({ isAuth, error }) => {
        if (!isAuth) return error(401);
      },
    })
    // use { userId }
    .delete("/jams/:id", async ({ userId, params: { id }, JamService }) => {
      return await JamService.delete({ id, userId });
    })
);

If there’s any single defining technology of this project, it’s ElysiaJs. This bespoke http server defines routes as functions and exports the type of the entire server. Then the related Eden client can use the server type to provide a type-safe client. This leads to some really great developer experience where I can get immediate type inference, suggestions and errors when I’m making clientside queries. Similarly it makes integration testing nearly painless.

1
2
3
4
5
6
7
8
9

// Client-side (Eden)
import { edenTreaty } from "@elysiajs/eden";
import type { App } from "./server";

const client = edenTreaty<App>("http://localhost:3000");

// This will have full type support
const response = await client.user[":id"].get({ params: { id: "123" } });
console.log(response.data.name); // TypeScript knows this is a string

Finally, I’m using React on the frontend. React is as unopinionated as ever and enforces 0 patterns for querying, or state management. I’ve brought in xstatestore to enforce a state transition pattern. Xstatestore uses a pattern where events are functions that return a new state and may accept (typed) data relevant to the state transition.

What’s next

I’ve got a lot of ideas I’d like to implement with this project:

  • Multi sized posts
  • An explore page / posting outside of a Jam
  • Following users
  • Joining a jam by following the link to it
  • Fix arbitrary JS execution with a sketch preview and report system

The list could go on, but before I do any of that I need to do some cleanup after a scramble to deploy the demo. Next I’ll be improving the UI which is unintuitive, filled with sharp edges, and has no animations.

Acknowledgements

Huge thanks to Kevin Saldaña, whose vast experience with web dev was invaluable in navigating this project.

Also big thanks to Jeremy Kaplan, who helped me deploy and work through an extremely annoying bug with Bunjs dependencies.

Both of these devs have way more experience than me and working with them has helped me identify weaknesses, refine thought processes, and improve workflow.