Productivity

encore-service

encoredev/skills · updated Apr 8, 2026

$npx skills add https://github.com/encoredev/skills --skill encore-service
summary

Every Encore service needs an encore.service.ts file:

skill.md

Encore Service Structure

Instructions

Creating a Service

Every Encore service needs an encore.service.ts file:

// encore.service.ts
import { Service } from "encore.dev/service";

export default new Service("my-service");

Minimal Service Structure

my-service/
├── encore.service.ts    # Service definition (required)
├── api.ts               # API endpoints
└── db.ts                # Database (if needed)

Application Patterns

Single Service (Recommended Start)

Best for new projects - start simple, split later if needed:

my-app/
├── package.json
├── encore.app
├── encore.service.ts
├── api.ts
├── db.ts
└── migrations/
    └── 001_initial.up.sql

Multi-Service

For distributed systems with clear domain boundaries:

my-app/
├── encore.app
├── package.json
├── user/
│   ├── encore.service.ts
│   ├── api.ts
│   └── db.ts
├── order/
│   ├── encore.service.ts
│   ├── api.ts
│   └── db.ts
└── notification/
    ├── encore.service.ts
    └── api.ts

Large Application (System-based)

Group related services into systems:

my-app/
├── encore.app
├── commerce/
│   ├── order/
│   │   └── encore.service.ts
│   ├── cart/
│   │   └── encore.service.ts
│   └── payment/
│       └── encore.service.ts
├── identity/
│   ├── user/
│   │   └── encore.service.ts
│   └── auth/
│       └── encore.service.ts
└── comms/
    ├── email/
    │   └── encore.service.ts
    └── push/
        └── encore.service.ts

Service-to-Service Calls

Import other services from ~encore/clients:

import { user } from "~encore/clients";

export const getOrderWithUser = api(
  { method: "GET", path: "/orders/:id", expose: true },
  async ({ id }): Promise<OrderWithUser> => {
    const order = await getOrder(id);
    const orderUser = await user.get({ id: order.userId });
    return { ...order, user: orderUser };
  }
);

When to Split Services

Split when you have:

Signal Action
Different scaling needs Split (e.g., auth vs analytics)
Different deployment cycles Split
Clear domain boundaries Split
Shared database tables Keep together
Tightly coupled logic Keep together
Just organizing code Use folders, not services

Service with Middleware

import { Service } from "encore.dev/service";
import { middleware } from "encore.dev/api";

const loggingMiddleware = middleware(
  { target: { all: true } },
  async (req, next) => {
    console.log(`Request: ${req.requestMeta?.path}`);
    return next(req);
  }
);

export default new Service("my-service", {
  middlewares: [loggingMiddleware],
});

Middleware Targeting

Control which endpoints middleware applies to:

// Apply to all endpoints
middleware({ target: { all: true } }, handler);

// Apply only to authenticated endpoints
middleware({ target: { auth: true } }, handler);

// Apply only to exposed (public) endpoints
middleware({ target: { expose: true } }, handler);

// Apply to raw endpoints only
middleware({ target: { isRaw: true } }, handler);

// Apply to streaming endpoints only
middleware({ target: { isStream: true } }, handler);

// Apply to endpoints with specific tags
middleware({ target: { tags: ["admin", "internal"] } }, handler);

Middleware Request Object

The request object provides access to:

const myMiddleware = middleware(
  { target: { all: true } },
  async (req, next) => {
    // For typed and streaming APIs
    const meta = req.requestMeta;  // { method, path, pathParams }

    // For raw endpoints
    const rawReq = req.rawRequest;
    const rawRes = req.rawResponse;

    // For streaming endpoints
    const stream = req.stream;

    // Custom data to pass to handlers
    req.data = { startTime: Date.now() };

    const resp = await next(req);

    // Modify response headers
    resp.header.set("X-Response-Time", `${Date.now() - req.data.startTime}ms`);

    return resp;
  }
);

Guidelines

  • Services cannot be nested within other services
  • Start with one service, split when there's a clear reason
  • Use ~encore/clients for cross-service calls (never direct imports)
  • Each service can have its own database
  • Service names should be lowercase, descriptive
  • Don't create services just for code organization - use folders instead
general reviews

Ratings

4.736 reviews
  • Anika Lopez· Dec 4, 2024

    We added encore-service from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.

  • Dev Ghosh· Nov 27, 2024

    encore-service is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.

  • Arjun Gill· Nov 23, 2024

    encore-service fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.

  • Noor Desai· Oct 18, 2024

    Solid pick for teams standardizing on skills: encore-service is focused, and the summary matches what you get after install.

  • Hassan Sharma· Oct 14, 2024

    encore-service has been reliable in day-to-day use. Documentation quality is above average for community skills.

  • Yash Thakker· Sep 25, 2024

    Keeps context tight: encore-service is the kind of skill you can hand to a new teammate without a long onboarding doc.

  • Noah Brown· Sep 25, 2024

    Useful defaults in encore-service — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.

  • Harper Sethi· Sep 25, 2024

    encore-service has been reliable in day-to-day use. Documentation quality is above average for community skills.

  • William Khan· Sep 17, 2024

    encore-service is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.

  • Ava Anderson· Sep 13, 2024

    Registry listing for encore-service matched our evaluation — installs cleanly and behaves as described in the markdown.

showing 1-10 of 36

1 / 4