
encore-go-service
โ 25by 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.
WHEN YOUR AGENT SHOULD USE IT
A QUICK BOUNDARYUSE 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.sqlApplication 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.sqlMulti-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.goLarge 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.goService-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.goGuidelines
- A package becomes a service when it has
//encore:apiendpoints - 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-architecturewhen the service boundaries have not been decided
npx skills add encoredev/skills --skill "encore-go-service" --full-depthRun this in your project โ your agent picks the skill up automatically.
BEFORE IT WILL WORK
Nothing โ it works as soon as it is installed.
Licensed under Apache-2.0โ you can use, modify, and redistribute it under that license's terms.
View the full license file on GitHub โ