Why I still bet on Parse Server

Every couple of years someone tells me Parse Server is dead. It was dead when the hosted product shut down. It was dead when the new backend-as-a-service of the month launched. It is, by this accounting, the most alive dead thing in my stack, because I keep shipping products on it and the products keep working.

I am not defending it out of nostalgia. I am defending it because it solves a real problem cheaply, and the alternatives mostly solve it expensively while pretending to be free.

What it actually gives you

You point it at a database and you get a REST and object API, users and sessions, file storage, and a permissions model that lives on the data instead of scattered through your route handlers. That last part is the quiet superpower. Access control as a property of the object, not a thing you remember to check in every endpoint, removes an entire category of "oops, that route forgot to verify the owner" bug.

None of this is novel. All of it is the stuff you would otherwise rebuild, badly, on your third product, after telling yourself this time you will keep it clean.

Cloud code is the right amount of backend

Most backend logic is not a microservice. It is a hook: before you save this, validate it; after you save that, send a notification; here is one function the client should not be trusted to run itself. Parse gives you exactly that surface and not much more.

Parse.Cloud.beforeSave("Order", async (request) => {
  const order = request.object;
  if (order.get("total") < 0) {
    throw new Parse.Error(141, "total cannot be negative");
  }
  order.set("status", order.dirty("items") ? "pending" : order.get("status"));
});

That hook runs on the server, close to the data, every time, no matter which client made the call. I have watched teams build a whole service layer to do what twelve lines of cloud code do. The service layer was more impressive. It also took three months and a meeting.

The boring backend ships products

The thing I keep relearning: the backend is rarely the product. The product is the thing on top of it. Time I spend hand-rolling auth, file handling, and a permissions model is time I am not spending on the part a user will ever see or pay for.

Parse lets me skip most of that and get to the actual idea in days. When the idea works, the backend is already production-shaped and I scale what is slow. When the idea does not work, I have not buried a month in plumbing for something nobody wanted.

Knowing where it ends

It is not magic. Heavy analytical queries do not belong in it, and there are workloads where I reach for something purpose-built. But the threshold where it stops being enough is much further out than its reputation suggests, and I have crossed that threshold far less often than I expected to.

Boring infrastructure has a bad name and a great track record. I will keep betting on the thing that quietly works over the thing that demos well, because I am the one who has to keep it running after the demo is over.