You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This document describes the current architecture, coding conventions, testing and deployment practices for `nclip`. It's targeted at contributors and any automated copilot/coding agent assisting with the codebase.
127
+
128
+
### 1) Test and Script Cleanup (must follow)
129
+
130
+
All integration tests and scripts must clean up the artifacts they create. Recommended patterns:
131
+
- Create test artifacts with a predictable prefix (e.g. `nclip-test-<slug>`), and delete only matching files during cleanup.
132
+
- When prefixing isn't possible, delete files in `./data` only if they are recently modified (e.g. `-mmin -60`) and/or explicitly recorded in a temp file during the test run.
133
+
- Always remove temporary files in `/tmp/` created by tests (use explicit names).
134
+
135
+
This avoids accidental deletion of unrelated data and keeps CI reproducible.
136
+
137
+
---
138
+
139
+
### 2) High-level Architecture
140
+
141
+
- Language: Go (1.25+ recommended)
142
+
- HTTP framework: Gin
143
+
- Storage abstraction: `PasteStore` interface (Filesystem and S3 implementations)
144
+
- Data model: JSON metadata + raw binary content
145
+
- Configuration: environment variables and CLI flags
146
+
147
+
### 3) API Endpoints (current)
148
+
149
+
- GET / — Web UI (upload form)
150
+
- POST / — Upload paste (returns paste URL)
151
+
- POST /burn/ — Burn-after-read paste
152
+
- GET /{slug} — HTML view
153
+
- GET /raw/{slug} — Raw content download (sets Content-Disposition)
Note: The concrete methods in this repository follow this pattern (filesystem uses files, S3 uses object + metadata JSON files).
188
+
189
+
### 6) Implementation notes
190
+
191
+
- Content-Type: Prefer client-provided `Content-Type` header; fall back to filename extension and then content-based detection. Keep `utils/mime.go` small and testable.
192
+
- Filenames: Download endpoints should include a user-friendly extension (via `utils.ExtensionByMime`). Text content should be served inline; binaries as attachments.
193
+
- Burn-after-read: Ensure atomic delete after the first successful read (store-level delete or transactional approach).
194
+
- Slugs: Uppercase alphanumeric by default; configurable length.
195
+
196
+
### 7) Error handling and logging
197
+
198
+
- Return JSON errors: `{ "error": "message" }`
199
+
- Use appropriate HTTP status codes
200
+
- Prefer structured logs (key/value or JSON); guard verbose debug behind a debug flag or environment variable
149
201
150
-
- Unit tests for all storage implementations
151
-
- HTTP endpoint tests using httptest
152
-
- Mock PasteStore for handler testing
153
-
- Integration tests with real storage backends
154
-
- Test both Lambda and server deployment modes
202
+
### 8) Testing
155
203
204
+
- Unit tests for utils, storage, and services
205
+
- Handler tests using httptest and a Mock PasteStore
206
+
- Integration tests (scripts/integration-test.sh) exercise the real binary and filesystem backend
207
+
- CI runs: unit tests, `golangci-lint` (includes `gocyclo`), and integration tests on main/dev branches
156
208
157
-
##Environment Variables
209
+
### 9) CI / Linting
158
210
159
-
All main configuration is via these environment variables (all have CLI flag equivalents):
211
+
-`golangci-lint`is used (configurable via `.golangci.yml`). `gocyclo` is enabled; keep functions under complexity thresholds where practical. Refactor complex helpers into small, testable functions.
-`GIN_MODE`, `AWS_LAMBDA_FUNCTION_NAME`, and `S3_BUCKET` are used only in deployment workflows (e.g., GitHub Actions, Lambda detection), not for app configuration.
174
-
- NCLIP_MONGO_URL and --mongo-url are no longer supported.
215
+
- Server mode: standard HTTP server with filesystem storage
216
+
- Lambda mode: S3-backed, same codebase. Use `AWS_LAMBDA_FUNCTION_NAME` or environment-driven adapter to detect Lambda runtime. Wrap Gin with an adapter (aws-lambda-go-api-proxy or similar).
175
217
218
+
### 11) Security and operational notes
176
219
177
-
## Deployment Modes
220
+
- No authentication required by design; consider adding rate-limiting or abuse protection for public deployments.
221
+
- Ensure S3 permissions are scoped to required actions only.
178
222
179
-
1.**Server mode**: Uses filesystem, full HTTP server
180
-
2.**AWS Lambda**: Uses S3, same codebase with Lambda adapter
181
-
3.**Both Lambda and server mode should use the same main.go, and use the AWS_LAMBDA_FUNCTION_NAME variable to determine the mode. (Don't separate 2 main.go for 2 modes )**
223
+
---
182
224
183
-
Both modes share identical API and behavior.
225
+
If you want, I can also:
226
+
- Convert integration-test cleanup to a prefix-based approach, or
227
+
- Add a short contributor checklist in this file with exact commands to run locally (build, run server, run integration tests).
184
228
185
-
## Lambda Deployment with S3
186
-
- The Lambda code should support http v2.0 payload format. (This is the default for new Lambda functions behind an API Gateway HTTP API.)
187
-
- Use AWS Lambda Go SDK
188
-
- Wrap Gin router with Lambda adapter
189
-
- S3 bucket is specified via `NCLIP_S3_BUCKET` env var
190
-
- Ensure the Lambda execution role has permissions for S3 actions: `s3:GetObject`, `s3:PutObject`, `s3:DeleteObject`
229
+
If you'd like this file split into separate CONTRIBUTING.md and ARCHITECTURE.md files I can create them as well.
0 commit comments