Contributing¶
Development Setup¶
Prerequisites¶
For iOS development (optional):
Getting Started¶
Web client at http://localhost:3000, API at http://localhost:8080. Default login: admin / changeme.
Running Services Individually¶
# Start only infrastructure
make infra
# Run Go API locally
make api-dev
# Run Next.js dev server
make web-dev
iOS Client Setup¶
Select the Vincenty scheme, choose a simulator, and run. The app needs the API running — enter http://localhost:8080 when prompted.
Code Conventions¶
Go (API)¶
- Strict layered architecture: Handler → Service → Repository
- Go stdlib
net/httpwith Go 1.22+ method-pattern routing - Middleware pattern:
func(http.Handler) http.Handler - Typed errors in
modelpackage, translated to HTTP status codes in handlers pgx/v5for database access, no ORM- All configuration via environment variables
- Run
go fmtandgo vetbefore committing
TypeScript (Web)¶
- Next.js with App Router, server components by default
- UI components via shadcn/ui
- All API calls through
src/lib/api.ts(auto-refresh on 401) - React Context for auth/WebSocket state, custom hooks for data fetching
- Tailwind CSS v4 utility classes
Swift (iOS)¶
- MVVM with Observation framework (
@Observable) - All network calls through
APIClient.shared - Kebab-case file naming (e.g.,
map-screen.swift), PascalCase for models - MapLibre Native SDK via UIViewRepresentable
Adding a New Feature¶
API — New Domain Resource¶
- Add domain struct and DTOs to
internal/model/ - Add a migration in
internal/database/migrations/ - Create repository in
internal/repository/ - Create service in
internal/service/ - Create handler in
internal/handler/ - Register routes in
cmd/server/main.go
Web Client — New Page¶
- Add TypeScript types to
src/types/api.ts - Create data-fetching hook in
src/lib/hooks/ - Add page component under
src/app/(app)/
iOS Client — New Feature¶
- Add Codable models to
Models/ - Create
@Observableview model inFeatures/{feature}/ - Create SwiftUI views, wire into navigation
- Add
.accessibilityLabelto icon-only buttons
Pull Request Process¶
- Create an issue first — discuss the approach before writing code
- Branch from
main— use descriptive names:feature/...,fix/...,docs/... - Keep PRs focused — one feature or fix per PR
- Test your changes —
go build ./...,go vet ./...,make devmust work - Update documentation — if you add config variables, endpoints, or change behavior
- Open the PR — describe what and why, reference the issue, include screenshots for UI changes
Code of Conduct¶
Be respectful and constructive. Focus on the work, not the person.