All skills
encoredev avatar

/go-service

@741d95a official
by Encoreencoredev/skills28 stars
5

Implement Encore.go services and lay out an application using service packages, internal subpackages, systems, and typed service calls. For service boundaries and architecture decisions, use `encore-architecture`.

  • 1 file
  • 4.1 KB
  • Updated 4 weeks ago
  • GitHub

Use this Skill: https://skilld.dev/gh/encoredev/skills/go-service

This session only. Nothing lands on disk.

SKILL.md

โ‰ˆ56 tokens always: the name and description. โ‰ˆ884 when used: this file.

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

Source: SKILL.md on GitHub

No third-party reports yet.

Signed by skilld at 741d95a. This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub 3 days ago.

Activeupdated 4 weeks ago
Other metadata
when_to_use
User wants to add or modify an Encore.go service or microservice, implement an already-chosen service layout, organize packages and directories, group services into system folders, or call another service. Trigger phrases: "add a Go service", "create a Go service", "add a microservice", "service package", "lay out these services", "Go package layout", "internal package", "call another service".
  • Go
  • encore
  • microservices
  • service-architecture
  • directory-structure
  • domain-driven-design
  • monolith
  • api-design
  • package-layout

README badge

README badge for encoredev/skills/go-service

Guides decomposition and directory layout for multi-service Encore Go applications. Covers monolith vs. microservices decisions, service boundary definition, and Go package structure โ€” from single-service projects to systems-of-services hierarchies with domain grouping.

Generated from the current SKILL.md.

When should I split my Encore Go app into multiple services?
Split when you have different scaling needs, different deployment cycles, or clear domain boundaries. Keep code together if it shares database tables or is tightly coupled. Use sub-packages instead of services just for code organization.
How do I make a package into an Encore service?
Any package with at least one `//encore:api` endpoint automatically becomes a service. No special configuration needed beyond adding the API annotation to a function.
Can services call each other in Encore Go?
Yes. Import another service's package and call its functions directly. Encore automatically converts these into RPC calls at runtime.
Can I have shared code that isn't a service?
Yes. Create packages without `//encore:api` endpoints for internal helpers, utilities, and shared logic. These won't become services.

Generated from the current SKILL.md. These answers refresh after source changes.