Labsco
encoredev logo

encore-go-service

โ˜… 25

by encoredev ยท part of encoredev/skills

How an Encore Go app gets split into separate services: any folder with an endpoint in it becomes one, and calling another service reads like calling an ordinary function.

๐Ÿ”ฅ๐Ÿ”ฅ๐Ÿ”ฅโœ“ VerifiedFreeQuick setup
๐Ÿงฉ One of 28 skills in the encoredev/skills package โ€” works on its own, and pairs well with its siblings.

WHEN YOUR AGENT SHOULD USE IT

A QUICK BOUNDARY

USE FOR

  • Turn a single package into a service just by adding one API endpoint to it.
  • Split a growing app into separate service packages like user, order, and notification.
  • Call another service's function directly and let Encore turn it into an RPC.
  • Group related services under a shared folder once an app gets large.

DO NOT USE FOR

  • Deciding where service boundaries should go is a separate skill's job, not this one.

This is the playbook your agent receives when the skill activates โ€” you don't need to read it to use the skill, but it's here to audit before installing.

Encore.go Service Structure

Instructions

In Encore.go, each package with an API endpoint is automatically a service. No special configuration needed.

Creating a Service

Simply create a package with at least one //encore:api endpoint:

// user/user.go
package user

import "context"

type User struct {
    ID    string `json:"id"`
    Email string `json:"email"`
    Name  string `json:"name"`
}

//encore:api public method=GET path=/users/:id
func GetUser(ctx context.Context, params *GetUserParams) (*User, error) {
    // This makes "user" a service
}

Minimal Service Structure

user/
โ”œโ”€โ”€ user.go          # API endpoints
โ”œโ”€โ”€ db.go            # Database (if needed)
โ””โ”€โ”€ migrations/      # SQL migrations
    โ””โ”€โ”€ 1_create_users.up.sql

Application Patterns

Single Service

An application can define its APIs in one root service package:

my-app/
โ”œโ”€โ”€ encore.app
โ”œโ”€โ”€ go.mod
โ”œโ”€โ”€ api.go           # All endpoints
โ”œโ”€โ”€ db.go            # Database
โ””โ”€โ”€ migrations/
    โ””โ”€โ”€ 1_initial.up.sql

Multi-Service

Each service lives in its own package:

my-app/
โ”œโ”€โ”€ encore.app
โ”œโ”€โ”€ go.mod
โ”œโ”€โ”€ user/
โ”‚   โ”œโ”€โ”€ user.go
โ”‚   โ”œโ”€โ”€ db.go
โ”‚   โ””โ”€โ”€ migrations/
โ”œโ”€โ”€ order/
โ”‚   โ”œโ”€โ”€ order.go
โ”‚   โ”œโ”€โ”€ db.go
โ”‚   โ””โ”€โ”€ migrations/
โ””โ”€โ”€ notification/
    โ””โ”€โ”€ notification.go

Large Application (System-based)

Group related services into systems:

my-app/
โ”œโ”€โ”€ encore.app
โ”œโ”€โ”€ go.mod
โ”œโ”€โ”€ commerce/
โ”‚   โ”œโ”€โ”€ order/
โ”‚   โ”‚   โ””โ”€โ”€ order.go
โ”‚   โ”œโ”€โ”€ cart/
โ”‚   โ”‚   โ””โ”€โ”€ cart.go
โ”‚   โ””โ”€โ”€ payment/
โ”‚       โ””โ”€โ”€ payment.go
โ”œโ”€โ”€ identity/
โ”‚   โ”œโ”€โ”€ user/
โ”‚   โ”‚   โ””โ”€โ”€ user.go
โ”‚   โ””โ”€โ”€ auth/
โ”‚       โ””โ”€โ”€ auth.go
โ””โ”€โ”€ comms/
    โ”œโ”€โ”€ email/
    โ”‚   โ””โ”€โ”€ email.go
    โ””โ”€โ”€ push/
        โ””โ”€โ”€ push.go

Service-to-Service Calls

Just import and call the function directly - Encore handles the RPC:

package order

import (
    "context"
    "encore.app/user"  // Import the user service
)

//encore:api auth method=GET path=/orders/:id
func GetOrderWithUser(ctx context.Context, params *GetOrderParams) (*OrderWithUser, error) {
    order, err := getOrder(ctx, params.ID)
    if err != nil {
        return nil, err
    }
    
    // This becomes an RPC call - Encore handles it
    orderUser, err := user.GetUser(ctx, &user.GetUserParams{ID: order.UserID})
    if err != nil {
        return nil, err
    }
    
    return &OrderWithUser{Order: order, User: orderUser}, nil
}

Internal Helpers (Non-Service Packages)

Create packages without //encore:api endpoints for shared code:

my-app/
โ”œโ”€โ”€ user/
โ”‚   โ””โ”€โ”€ user.go       # Service (has API)
โ”œโ”€โ”€ order/
โ”‚   โ””โ”€โ”€ order.go      # Service (has API)
โ””โ”€โ”€ internal/
    โ”œโ”€โ”€ util/
    โ”‚   โ””โ”€โ”€ util.go   # Not a service (no API)
    โ””โ”€โ”€ validation/
        โ””โ”€โ”€ validate.go

Guidelines

  • A package becomes a service when it has //encore:api endpoints
  • Services cannot be nested within other services
  • Cross-service calls look like regular function calls
  • Each service can have its own database
  • Package names should be lowercase, descriptive
  • Don't create services just for code organization - use sub-packages instead
  • Use encore-architecture when the service boundaries have not been decided