{
  "id": 8249240,
  "title": "Dois projetos, dois back-ends: quando vale separar a API",
  "url": "https://urgent.news/2026/09/18/dois-projetos-dois-back-ends-quando-vale-separar-a-api",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-18T13:01:29.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/davimaxmillan/dois-projetos-dois-back-ends-quando-vale-separar-a-api-55f1"
  },
  "original_language": "pt",
  "account": "Two projects, two back-ends: when to separate the API\n\nThe author has two personal projects addressing a similar issue - managing classes, students, and activities. ProfessorOS is a single Next.js project with all components within the same process, while leanpulse has a separate back-end built with NestJS communicating with a different Next.js front-end. By placing the two side by side, the author can draw lessons on when each approach makes sense, not as a fixed rule, but as a reflection on having taken both paths in practice.\n\nIn ProfessorOS, the author uses Next.js API routes for everything: authentication, business rules (like calculating semester grades), and Prisma access. There is no separate API - the front-end and back-end are practically the same deployment. This works well for a single-person project (no other team consuming the same API), the domain is relatively contained (personal academic management), and the goal is to deliver quickly without overhead of coordinating two services.\n\nIn leanpulse, the NestJS back-end exists independently from the front-end. This means more moving parts - two services to deploy (front on Vercel, back on Render), more CORS and environment variable configuration between them. In exchange, the author gains a standalone API structured in modules (NestJS puts code this way by default) ready to be consumed by any front-end, not just the one integrated with it. The author learned that neither approach is inherently better - they solve different problems. The author's criterion after the fact is that for a project meant for them, alone, to solve a specific thing, the monolithic approach of ProfessorOS delivers value faster. If there is any chance of multiple front-ends (or multiple people) needing to talk to the same business logic in the future, separating the back-end from the start avoids painful refactoring later.\n\nThe author admits this decision wasn't made with this level of clarity at the time. It only became obvious after comparing the two ready projects.",
  "summary": "Tenho dois projetos pessoais que resolvem um problema parecido — gestão de turmas, alunos e atividades — mas com arquiteturas bem diferentes. O ProfessorOS é um projeto Next.js \"só\", com tudo dentro do mesmo processo: front-end, rotas de API e acesso ao banco convivendo na mesma aplicação. Já o leanpulse tem um back-end separado, construído em NestJS, conversando com um front-end Next.js à parte.…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}