Behind Southside.A staff-run site,
and the limits of its log.

01 / FIELD NOTESPut the content workflow in the data layer

The admin console covers artists, releases, events, photos, team, messages, logs, and a map. The public site presents the roster, releases, and events, including outbound links to Spotify, Apple Music, YouTube Music, and SoundCloud.

The data layer wraps Supabase calls in small API objects. After a create, update, or delete, it attempts to write an activity entry. Keeping that work in the service layer means the logging attempt belongs with the mutation, rather than being scattered across the interface.

02 / FIELD NOTESRead the order of operations

The artist-creation excerpt is short enough to show the important distinction. First, insert the artist and check for an error. Then try to write the log. Finally, return the artist.

create: async (artist, userEmail?) => {
  const { data, error } = await supabase
    .from('artists').insert(artist).select().single();
  if (error) throw error;
  try {
    await adminLogsApi.create({
      action: 'create', entity_type: 'artist', entity_id: data.id,
      details: `Created artist "${data.name}"`, user_email: userEmail,
    });
  } catch (logError) { console.error("Error logging action:", logError); }
  return data as Artist;
}

The try / catch surrounds the log write, not the artist insert. If the insert reports an error, the function throws. If the artist is created but logging fails, the error is written to the console and the function still returns the artist.

That behavior is easy to miss behind a phrase like “audit logging.” A saved artist does not necessarily mean there is a corresponding audit row.

03 / FIELD NOTESBest-effort is a real limitation

The tradeoff here is concrete: a failed activity-log write does not block a successful content change. That keeps the primary change independent of the second write, but it also leaves room for gaps in the history.

I would describe the feature as best-effort activity logging, not promise that every change can be reconstructed from the log. The corrected source account makes the same distinction.

A requirement for complete history would need a stronger design, such as atomic writes or durable retries with failure monitoring. Those are possible improvements named in the source—not mechanisms this example already implements. An interface cannot turn two separately handled writes into a guarantee by displaying a reassuring badge.

04 / FIELD NOTESKeep image storage separate from delivery

Photos are uploaded to Supabase Storage. The public-facing URL can take a different path: a helper recognizes matching storage URLs and rewrites them to a Cloudflare Worker endpoint for cached delivery.

export function getImageWorkerUrl(url) {
  if (!url) return null;
  const match = url.match(storagePattern); // matches the Supabase storage bucket
  if (match && match[1]) {
    return `https://southside-records.mjd072.workers.dev${match[1]}`;
  }
  return url;
}

The conditions matter. An empty URL returns null. A matching storage URL is rewritten. A URL that does not match is returned unchanged.

The published account describes site images using this helper. The excerpt does not show the Worker’s cache configuration, a resizing pipeline, or a benchmark. It explains the URL routing, not a measured speed improvement.

05 / FIELD NOTESThe work I would do next

There were no automated tests in the original account. I would start with the audit wrapper and URL helper: the insert-failure, log-failure, matching-URL, and nonmatching-URL cases are all visible in the excerpts.

The source also notes that access control relies on Supabase row-level-security policies held in the database, not in the repository. Bringing those policies into version control was an identified improvement. This article does not verify those policies or imply that the UI alone enforces permissions.

Finally, the per-entity API objects repeat a lot of structure. A small shared factory was the proposed way to reduce that repetition. The useful goal is a data layer that remains easy to inspect—not an abstraction added just to shorten a file.

06 / FIELD NOTESWhat the public page does not show

The record-label website is the visible result. Maintaining it involves content types, staff tools, storage paths, and failure handling.

That is why the log example deserves as much attention as a screenshot. It shows what the system does when one operation succeeds and the next one fails. Being precise about that behavior makes the project easier to understand—and easier to improve.