DEV Community: Arran

Backend downtime during a demo

Arran — Thu, 28 Aug 2025 18:44:40 +0000

I had a demo ruined by backend downtime.

I was demoing my Little Black Book app — a React and Express project for storing, adding, amending, deleting, sharing etc. cocktail recipes. The frontend was loading fine, but when I tried to fetch the list of drinks from the API, the request just froze. No response. No errors. Just dead air.

The worst part was I knew this happens. Before the demo, I’d even prepped for it. I opened the app, clicked around, made sure the backend on Render was awake. But the demo came late in the conversation, and Render’s free tier 15-minute inactivity limit quietly kicked in while we were talking.

By the time I actually showed the app, the backend had gone to sleep. So the first request during the demo… just didn’t return.

my demo was a long awkward fumbling around, refreshing and some fast talking.

The problem

Render shuts down free services after 15 minutes of inactivity.
It’s a free tier.
But if your frontend and backend are hosted separately (like mine, with Firebase for the frontend), you run into cold starts that feel like total failures during a live demo.

Especially if:

You rely on real-time API responses
You’re in an interview or trying to showcase your work

What I did differently in VISOR

After that demo, I needed to figure out how to never let that happen again.

When I started building VISOR — my photography platform for sharing film simulations and Lightroom presets — I baked in a fix from day one.

The fix: a simple health check + UptimeRobot

I added a /health endpoint to the Express backend:


  app.get("/health", (req, res) => {
    res.status(200).json({
      status: "healthy",
      environment: NODE_ENV,
      timestamp: new Date().toISOString(),
    });
  });

This gives me a simple, safe endpoint that uptime monitors can ping.

Then I set up UptimeRobot to hit it every 5 minutes:

Monitor Type: HTTP(s)
URL: https://visor-backend.onrender.com/health
Interval: every 5 minutes

That’s it — the backend stays alive, even when I haven’t touched it in days/weeks/months.

When things go down: Render incidents

After adding UptimeRobot to VISOR, I started getting real insights into what was happening when the backend became unavailable.

In this case, Render returned multiple 503 Service Unavailable errors from different locations. This usually means one of two things:

The server was put to sleep after 15 minutes of inactivity (standard for free tiers)
The service was cold-starting but hadn’t run quickly enough to respond - timed out basically

Because I’d set up a health check monitor in UptimeRobot, it detected the outage, logged the exact start time, and alerted me via email.

Then, as soon as the next ping got a valid response from /health, it marked the issue as resolved.

This kind of insight is gold when you're debugging uptime issues, especially with free platforms. Without it, I'd just see random timeouts in the frontend with no clear reason.

So how does UptimeRobot actually help?

By default, Render won’t keep your app running 24/7 unless it’s on a paid plan. That means your backend can fall asleep between uses — especially overnight or during development pauses.

What UptimeRobot does is send regular HTTP requests to your app’s /health endpoint. That traffic is enough to keep the backend alive — or at the very least, wake it up before you or your users need it.

So instead of cold starts during live demos or delays in the browser, everything’s ready to respond.

It's a free fix for a free hosting, for cheapskates like me.

Simple lessons learned

Add a /health route to your backend — it's actually so simple and will save you a lifetime of embarrassment
Use UptimeRobot to prevent Render cold starts before demos or testing.
Free hosting is great, but you’ve got to understand it's free and limited.

Building VISOR with GraphQL

Arran — Thu, 17 Jul 2025 11:55:30 +0000

Visor - Film Sims

In my last post, I talked about seeding the backend. This time, I want to talk about how that data actually shows up on the page and why I used GraphQL.

What is my understanding of GraphQL?

GraphQL is a way to query and mutate data on a server — kind of like REST, but more flexible. Instead of hitting separate endpoints like /film-sim, /comments, /creator, etc., you can write one query that says exactly what you want, and it'll return only that.

A query is used to fetch data.
A mutation is used to change or add data.
A resolver is the function on the server that runs when you call one of those operations.

One of the simplest (but still hefty) GraphQL queries in VISOR powers the film Simulation pages.
Each page pulls together heaps of data:

The film sim name, type, and description
All In-camera settings (highlight, shadow, white balance, grain, etc.)
White balance shift grid
Compatible cameras
Creator info (name, avatar, Instagram link)
Tags and notes
Sample image gallery
Linked recommended Lightroom presets
A comment section

All that in one view. Here’s what the GraphQL query looks like:

query GetFilmSimBySlug($slug: String!) {
  getFilmSim(slug: $slug) {
    id
    name
    description
    type
    notes
    tags
    settings {
      filmSimulation
      dynamicRange
      whiteBalance
      wbShift {
        r
        b
      }
      color
      sharpness
      highlight
      shadow
      noiseReduction
      grainEffect
      clarity
      colorChromeEffect
      colorChromeFxBlue
    }
    sampleImages {
      url
      caption
    }
    recommendedPresets {
      title
      slug
      afterImage {
        url
      }
      creator {
        username
      }
    }
    creator {
      username
      avatar
      instagram
    }
    comments {
      content
      author {
        username
      }
    }
  }
}

This is where GraphQL does its work. In REST, this would’ve meant lots of repetitive calls to stitch everything together, one for the film sim, another for the comments, another for the user, and on and on.. Here, it’s one trip, one structure, deeply nested, and built for exactly what the frontend needs.

Resolvers

Here’s a simplified version of the resolver behind getFilmSim — the function that runs on the server when the query is called:

const resolvers = {
  Query: {
    getFilmSim: async (_parent, { slug }, context) => {
      return await context.models.FilmSim.findOne({ slug })
        .populate('tags')
        .populate('creator')
        .populate('recommendedPresets')
        .populate({
          path: 'comments',
          populate: { path: 'author' },
        });
    },
  },
};

The key here is .populate(); that’s how MongoDB fetches the nested data: tags, comments with authors, recommended presets with creators, etc.

Uploading and populating film sims

Once I had the ability to display the film sims, the next step was letting users create their own.

The upload page includes options to upload presets and film sims, I will come back to the presets later as that uses and XMP Parser which I'd like to go into more detail on.

The film sim upload:

Collects all camera-style settings (highlight, clarity, etc.)
Lets the user upload multiple sample images and automatically uploads those images to Cloudinary
Submits all data including nested structures. All in one mutation

Here’s the GraphQL mutation:

mutation UploadFilmSim(
  $name: String!
  $description: String
  $settings: FilmSimSettingsInput!
  $notes: String
  $tags: [String!]!
  $sampleImages: [SampleImageInput!]
) {
  uploadFilmSim(
    name: $name
    description: $description
    settings: $settings
    notes: $notes
    tags: $tags
    sampleImages: $sampleImages
  ) {
    id
    name
    slug
  }
}

Resolvers

Here’s the server-side resolver for that mutation:

Mutation: {
  uploadFilmSim: async (_parent, args, context) => {
    const { name, description, settings, notes, tags, sampleImages } = args;

    const filmSim = new context.models.FilmSim({
      name,
      slug: slugify(name),
      description,
      settings,
      notes,
      tags,
      sampleImages,
      creator: context.userId,
    });

    await filmSim.save();
    return filmSim;
  },
},

The input types ensure the structure is correct before the resolver runs. Then it gets saved to MongoDB and returned to the client.

The trickiest part was making sure all optional fields were either included or left out cleanly. GraphQL will complain if you send null when it expects a string, or if a non-null field is missing entirely.

Frontend: Upload

On the frontend, I collect the form data and upload images to Cloudinary first:

const uploadToCloudinary = async (file: File): Promise<SampleImageInput> => {
  const formData = new FormData();
  formData.append("file", file);
  formData.append("upload_preset", "FilmSimSamples");
  formData.append("folder", "filmsims");

  const response = await fetch(`https://api.cloudinary.com/v1_1/${cloudName}/image/upload`, {
    method: "POST",
    body: formData,
  });

  const data = await response.json();
  return {
    publicId: data.public_id,
    url: data.secure_url,
  };
};

cloudName is saved in the .env file to be kept secure and fetched as below:

const cloudinaryConfig = {
  cloudName: import.meta.env.VITE_CLOUDINARY_CLOUD_NAME,
  apiKey: import.meta.env.VITE_CLOUDINARY_API_KEY,
  apiSecret: import.meta.env.VITE_CLOUDINARY_API_SECRET,
};

Then I pass the uploaded URLs and all the form inputs into the uploadFilmSim mutation:

const variables = {
  name: title,
  description,
  settings: formattedSettings,
  notes,
  tags: tags.map((tag) => tag.toLowerCase()),
  sampleImages: uploadedImageUrls,
};

await uploadFilmSim({ variables });

Once submitted, Apollo Client handles cache updates and redirects the user to their brand new film sim detail page — built from the same query I showed above.

Seeding gave me confidence the data shape worked, Queries displayed deeply connected data cleanly, Uploads let users populate their own nested structures.

Seeding the backend: schemas, models and Film Sims

Arran — Sun, 13 Jul 2025 11:56:24 +0000

Link to VISOR

Before the app could do anything, it needed something to work with. So I needed to build the backend first. I started out setting up the schema, defining the model, with the goal of seeding the database with some actual data. It's one of those tiresome jobs that just needs to be done before anything else, and at this point I was itching to get something visual down, so I wasn't enjoying this at all.

Defining the schema

I'm most used to and am using MongoDB with Mongoose for VISOR, so the first step was defining a schema that reflects the kind of data I want to work with. I decided to start with the Film Simulations because that seemed simpler than a whole Lightroom XMP, it has heaps less data

Here’s the initial schema I wrote:

import mongoose from 'mongoose';

const filmSimSchema = new mongoose.Schema({
  name: { type: String, required: true },
  type: { type: String, enum: ['Fujifilm', 'Custom'], required: true },
  settings: {
    grain: String,
    dynamicRange: String,
    highlight: Number,
    shadow: Number,
    colour: Number,
    sharpness: Number,
    noiseReduction: Number,
    clarity: Number,
  },
  description: "String,"
  tags: [String],
}, { timestamps: true });

export default mongoose.model('FilmSim', filmSimSchema);

I originally based this on the settings from my Fujifilm X-E2, which came out in 2012. forgetting that obviously, Fujifilm has added loads of new film sims and setting options since then. So later down the line, I had to go back and update the schema to match newer models. I'm not sure why I thought building my entire structure off a 13-year-old camera was a good idea.

Seeding the database

I wrote a simple seed script to populate the database. I passed this to ChatGPT and asked it to fill in some real life film sims in that format:


import mongoose from 'mongoose';
import FilmSim from '../models/FilmSim';

const seedFilmSims = async () => {
  await mongoose.connect(process.env.MONGODB_URI);

  const sims = [
    {
      name: 'Classic Chrome',
      type: 'Fujifilm',
      settings: {
        grain: 'Weak + Small',
        dynamicRange: 'DR100',
        highlight: -1,
        shadow: -1,
        colour: 0,
        sharpness: 0,
        noiseReduction: -2,
        clarity: 0,
      },
      description: 'Muted colours, soft contrast — great for street photography.',
      tags: ['street', 'muted', 'film-like'],
    },
    {
      name: 'Tri-X 400',
      type: 'Custom',
      settings: {
        grain: 'Strong + Large',
        dynamicRange: 'DR200',
        highlight: -2,
        shadow: +3,
        colour: -2,
        sharpness: 0,
        noiseReduction: -4,
        clarity: -1,
      },
      description: 'High contrast black and white look with punchy shadows.',
      tags: ['b&w', 'contrast', 'classic'],
    },
  ];

  await FilmSim.insertMany(sims);

  console.log('Film sims seeded.');
  mongoose.disconnect();
};

seedFilmSims();

To run it:

npm run seed:filmSims

It's pretty simple but means the backend is usable — no blank states, no filler text, no flaky mock layers. Which gives me space to build and start designing the frontend, which was what I was actually excited about.

You've probably notice I had forgot to add sample images, which for a visual application is a massive oversight. I added these manually in MongoDB Compass and updated the schemas.

Visualising it all with MongoDB Compass

I love using MongoDB Compass to visualise the backend. It gives me a clear view of what’s in each collection, how documents are structured, and lets me edit things sneakily if needed — great for fixing weird test cases or just experimenting with values on the fly.
But mainly, when I first started working with a backend, I couldn’t get my head around how you couldn't see the data in a document format, I was creating data, but I couldn't see it anywhere until I called it to the frontend, that was so foreign to me.

I always keep Compass open alongside the app just to sanity-check what’s going on.

Why I seeded instead of mocking

I’ve used mock data in the past, and yeah it does a job — especially early on or for testing isolated components. But in this case, I wanted to test the real data flow right away. Seeding meant I was hitting GraphQL endpoints and querying real MongoDB data from the start. When working on a evolving project like this, its really nice to know that when I update something in the actual DB rather than the mock data, its going to stick.
I'm finding issues all the time with this app, its changing every time I open the codebase, Lightroom or pick up my camera, maybe I should have spent more time on the planning. 🤷‍♂️

GraphQL

I like working with GraphQL — it's got a nice structure, and lets me define exactly what the frontend needs. But it can also be a bit of a difficult.
One typo in a query, one wrong resolver, one missing field and everything breaks. The app won’t render, the dev tools shouts at you, and it’s not always obvious which part of the pipeline is broken.

Seeding the backend from the get-go meant I was looking at errors a lot. In another project, I built a full REST API that just sent data back and forth. Really, it was kind of easier to understand than GraphQL. When something broke, it was usually obvious — no schema mismatch or cryptic resolver issues, just a straightforward request and response.

I could keep writing about GraphQL and the reasons it’s my choice for VISOR but I think I’ll write another post about this shortly.

Final thought

Seeding wasn’t just about filling in some test data — it was all about building the foundations for the app. I got get real queries, real data, and real confidence that the structure I had built actually worked. It sped up development, and gave the frontend something solid to interact with.

Junior Developer Journey & VISOR

Arran — Tue, 08 Jul 2025 13:59:20 +0000

For the past 18 months,
I’ve been self teaching web development.

It hasn’t always been easy. I’ve studied across dozens of platforms, built project after project, and sent out more applications than I can count. Most of those efforts didn’t lead anywhere. And most of the projects? They were good practice — but none of them really felt like me.

Everyone keeps telling me sympathetically "it’s a rough time to break into tech". yeah.
Some days I kick myself for not starting this journey sooner some friends and family we're trying to lead me to a career in tech years ago. Now I’m here, trying to stand out in an industry that feels tighter than ever. AI is shifting workflows, companies are shrinking teams, and while there are many roles out there, there seem to be many more developers chasing them. Most of the applications I send out fall on deaf ears often even without a rejection. I'm at the point where I am second guessing myself, is this a good idea, is it a waste of time?

Time you enjoy wasting is not wasted time.

Passion and drive is so difficult to put across on a CV in a sea of CVs. 🤷‍♂️

I’ve always loved photography and I’d spend hours online trying to find camera settings, Lightroom presets, or just inspiration — usually jumping between forums, Pinterest boards, YouTube videos and Subreddits. It's so hard to find a decent source and somehow that made it more addictive.

During my daughter’s ballet class, it hit me:
What if I could combine my two obsessions?
So I spent the whole class brainstorming with ChatGPT.

So I started planning a platform that brings those things together — a place I wished existed, the place I was looking for when I would scroll late at night, designed for people like me who care about film sims, editing styles, and the craft behind the image.

I'm currently calling it VISOR (but I've fairly certain that name is taken for some immersion goggles, damn).

VISOR is a creative hub for photographers — a space to explore and share Fujifilm film simulations, Lightroom presets, camera setups, chat in forums, share ideas and is laid out in an pleasingly addictive “scroll-until-the-end-of-the-world” format, and I’m shaping the design to feel more like a visual journal than just another preset archive.

It’s clean, dark, and editorial, made for people who care about the details and want to scroll pretty pictures. Whether they're interested in the basics or deep diving into the dark tucked away settings of an XMP.

This already feels like the most personal and purposeful thing I’ve created so far. It’s helped me grow not just as a developer, but as a designer and a problem solver.

I’m building it with what I’ve learned so far:
React, TypeScript, GraphQL, MongoDB and picking up new skills as I go. I’ve started structuring the backend with a modular GraphQL API, working with file uploads, and designing a custom image gallery layout that supports before/after previews, film sim tags, and camera profiles.

There’s still a lot to build and a lot more ideas flying around my brain.

If you’re into street photography, film-like edits, or just want a place to explore visual styles with more heart and less noise. Alternatively, if you're into full stack development, or into watching a junior struggle through life, I’d love to share this with you as it grows.