go-service

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 auth method=GET path=/users/:id
func GetUser(ctx context.Context, params *GetUserParams) (*User, error) {
    // This makes "user" a service
}

Choose the access level of each endpoint on purpose. Use auth for endpoints that return personal data such as email, and confirm the signed-in caller may view the requested user before returning it. Keep public for data that is meant to be anonymous and is not sensitive. The examples here are short excerpts: parameter types, response types and helper functions are left out, so complete them and review the result before use.

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
}

This example leaves out an ownership check. Before returning the order, confirm the signed-in caller owns it, and return a permission or not found error otherwise. The called service endpoint also checks authorization and validates its input itself, because each cross-service call is a network RPC call.

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, but they are network RPC calls: each called endpoint validates its input and enforces authorization itself rather than relying on the caller
• Mark endpoints that only other services call as private
• Endpoints authorize access to the specific object requested
• Use auth or private by default, and use public only for data that is meant to be anonymous and is not sensitive
• 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