A working backend for startups, hackathons, sales pitches in an afternoon.

Who this is for

Your first version should cost days, not months

This is built for the early stage: a startup racing to a first release, an MVP that has to exist by Friday, a hackathon where the clock is the whole problem, a sales pitch that needs a live demo rather than slides. At that point the thing that decides whether it happens is how quickly you can put it in front of someone — not your architecture, and not which ORM you picked. The backend is almost never the interesting part of the idea, and it is almost always where the first month goes.

So the position here is narrow and specific: you should never write authentication, sessions, roles, row-level permissions, file storage or real-time again. That is plumbing every product needs and no product competes on. Write the part that is actually yours.

The idea

One class is the whole definition

Declare a model once. The database schema, a unique index, a MongoDB validator, the class-level permissions and the OpenAPI schema are all derived from it — there is no migration to write and no DTO to keep in step.

@ParseClass('Product', {
  clp: { find: { requiresAuthentication: true } },
})
export default class Product extends BaseModel {

  @ParseField({ type: 'String', required: true })
  declare name: string;

  @ParseField({ type: 'String', unique: true })
  declare sku: string;

  @ParseField({ type: 'Number', min: 0 })
  declare price: number;
}

• ✓Schema generated from the decorators
• ✓Unique index on sku, created at boot
• ✓MongoDB validator so the database enforces min too
• ✓OpenAPI schema, with no annotations
• ✓Class-level permissions applied
• ✓Typed access — product.price, not .get()

Written with an assistant

There is so little of it to write that an AI can write most of it

Look at what you just read. The schema, the index, the validator, the permissions and the OpenAPI schema are one class. An assistant cannot leave five things out of step when there is only one thing.

That is the whole argument, and it is a mechanical one rather than a claim about any particular model. On a typical stack a new entity means keeping a migration, an entity class, a DTO, a validator and a controller consistent by hand — five files that drift from each other, which is exactly the kind of work AI is worst at. Here it is two files, generated with the edit points already marked.

  Which AI coding assistants do you use?

   • 1  Claude Code       CLAUDE.md + skills + agent
     2  Cursor            .cursor/rules/
     3  GitHub Copilot    .github/
     4  Windsurf          .windsurf/rules/
     5  Gemini CLI        GEMINI.md
     6  AGENTS.md         the cross-tool convention
     0  none

  Numbers, comma separated (6)

Why Parse Server

Authorisation the database enforces, not your endpoints

Two layers. Class-level permissions decide who may touch a class at all. An ACL on every row decides who may touch that particular record — and the database applies it to every query, whether or not the endpoint remembered to.

// once, when the record is created
note.setACL(implementACL({
  owner: [{ user: user.id, read: true, write: true }],
  roleRules: [{ role: 'Admin', read: true, write: true }],
  publicRead: status === 'published',
}));

// every query afterwards is filtered for free
const mine = await new Parse.Query(Note)
  .find({ sessionToken });   // no where clause needed

Routing

The method name is the route

@Route(Product)
class ProductFunctions {

  @CloudFunction({ methods: ['POST'] })
  static async createProduct(req) { … }
  // → POST /api/products/createProduct

  @CloudFunction({ methods: ['GET'] })
  static async listProducts(req) { … }
  // → GET  /api/products/listProducts
}

Concurrency

Two guards most Parse projects go without

@CloudFunction({ methods: ['POST'] })  // above
@Transactional()                        // below
static async placeOrder(req) {
  await order.save(null, { useMasterKey: true });
  await stock.save(null, { useMasterKey: true });
}  // both land, or neither


class Job extends BaseModel {
  @ParseVersionField()
  declare version: number;
}  // that is the entire feature

Honestly

Compared with NestJS

These are not really competitors, and it is worth being precise about why. NestJS is an application framework: it hands you structure — modules, DI, guards, pipes — and you build the backend inside it. Parse Server is a backend: users, sessions, permissions, files, and real-time already exist, and you customise what they do. This library is the layer that makes customising it feel like writing TypeScript instead of writing configuration.

So the question is not "which framework is better". It is how much of your backend is the part Parse already wrote. For a product with accounts, roles, per-row visibility, uploads, and a mobile client, that share is large and starting from Parse saves months. For a service that is mostly domain logic over an existing database, that share is near zero and NestJS wins outright.

The same rule, both ways

"Users may only see their own orders" — the difference that never stops costing you.

// NestJS — the filter lives in every query
findAll(user) {
  return this.repo.find({
    where: { ownerId: user.id },   // remember it
  });
}

async findOne(id, user) {
  const o = await this.repo.findOneBy({ id });
  if (o.ownerId !== user.id)         // and here
    throw new ForbiddenException();
  return o;
}

// …and in the report endpoint, the export
// job, and the admin screen added next
// quarter by someone else

// parse-server-kit — written once,
// when the row is created
order.setACL(implementACL({
  owner: [{ user: user.id,
            read: true, write: true }],
}));


// every query afterwards, everywhere:
await new Parse.Query(Order)
  .find({ sessionToken });

// no where clause. The database applies
// the rule whether or not the endpoint
// remembered to.

The full comparison, with code for auth and CRUD →

Where the effort went

Most of the work is in what fails quietly

A decorator that does nothing, a transaction that never opens, a field that reads back correctly but never reaches the database — none of these raise an error. Two have been made impossible, four now report themselves at boot, and the rest are written down.

The integration suite boots a real Parse Server against MongoDB and exercises versioned saves, stale-save conflicts and transaction rollback end to end — because the transaction layer leans on parse-server internals, and an upstream release can move them.

Read the troubleshooting guide →

Documentation

Everything you need, without leaving

Parse concepts link out to the Parse Platform docs where the detail belongs. Everything you reach for while building is here.

• ›Getting started — three commands to a running API
• ›AI assistants — the rules, in the file your tool already reads
• ›Tutorial · a first API — models to scheduled jobs, in twenty minutes
• ›Tutorial · orders & stock — money, races and permissions that follow status
• ›Models & fields — every field type and option
• ›fromParams — request body to typed object, safely
• ›Permissions & ACL — the two layers, and five patterns
• ›Queries — filters, pointers, paging, counting
• ›Relationships — pointers, arrays and relations
• ›Users & auth — signup, sessions, roles, reset
• ›Files & images — uploads and the ACL cascade
• ›Endpoints — routing, validation, OpenAPI
• ›Triggers — all 21 types, and cron
• ›Real-time — LiveQuery, scoped by the same ACL
• ›Transactions — atomic writes across the call
• ›Optimistic locking — one line against lost updates
• ›Seeding data — roles and a first admin, re-runnably
• ›Parse Dashboard — an admin console, one install away
• ›Errors — codes, throwing, what clients see
• ›Troubleshooting — symptom to page

Credit where it is due

Built on Parse Platform

Nearly everything this page calls a feature — users, sessions, roles, class-level permissions, row ACLs, LiveQuery, file adapters, push, the admin dashboard — is Parse Platform's work, not ours. Parse Server began at Parse, was open-sourced in 2016 when the hosted service closed, and has been maintained by its community ever since. It is a mature, actively released project with SDKs for the web, iOS, Android, Flutter and more.

This library is a layer on top of it. It does not fork Parse Server, replace it, or wrap it in an abstraction you then have to learn instead. It adds decorators, routing, schema generation and a CLI, and gets out of the way — a Parse concept behaves here exactly as the Parse documentation says it does, which is why these pages link out to it rather than paraphrasing.

• ›parseplatform.org — the project, its SDKs and its community
• ›Parse docs — the reference for every Parse concept
• ›parse-community/parse-server — the server itself
• ›parse-dashboard — the admin console, one install away