7.7 KiB

Ruw Blame Geschiedenis

Code Grade & Production Readiness Report (Updated)

Overall grade: 7.0 / 10

The codebase has been refactored into a clear app/service layout with thin cmd entrypoints, shared internal/pkg libraries, health/readiness endpoints, structured middleware, and addressed reliability/security items. It is suitable for development and staging; production use still requires CORS restriction, optional metrics/tracing, and (if desired) request validation and OpenAPI.

1. What’s working well

Area	Notes
Structure	`cmd/<service>/main.go` is thin (~25 lines); `internal/app/*` holds per-service composition; `internal/pkg` has api (response, middleware, handler), location, bridge, decoder, config, kafkaclient, logger, model, controller, service, database, apiclient, appcontext.
Concurrency	Channels, `sync.WaitGroup`, and `AppState` with RWMutex; event loops live in app layer, not in main.
Shutdown	`signal.NotifyContext` + app `Run`/`Shutdown`; Kafka and MQTT cleanup in app.
Kafka	`KafkaManager`, generic `Consume[T]`, graceful close.
Observability	`/health` and `/ready` (DB ping); middleware: logging, recovery, request ID, CORS; logging to file with fallback to stderr if file open fails.
Reliability	No panics in library code for logger (fallback to stderr); MQTT connect returns error; server init returns error; `WriteMessages` errors checked in parser service and settings controller.
Security	TLS skip verify is configurable via `TLS_INSECURE_SKIP_VERIFY` (default false).
Testing	Unit tests for appcontext, utils, model, controller, service, config; integration tests for bridge/decoder.
Dependencies	Modern stack (slog, segmentio/kafka-go, gorilla/mux, gorm).

2. Fixes applied since last report

2.1 Startup and library behavior

Bridge: MQTT connect failure no longer panics; internal/pkg/bridge/mqtt.go returns error from NewMQTTClient, cmd/bridge/main.go exits with log.Fatalf on error.
Server: DB and config init live in internal/app/server; New/Init return errors; cmd/server/main.go uses log.Fatalf on error (no panic in library).
Logger: CreateLogger no longer uses log.Fatalf; on log file open failure it returns a logger that writes only to stderr and a no-op cleanup.

2.2 Ignored errors

parser_service.go: writer.WriteMessages(ctx, msg) return value is checked and propagated.
settings_controller.go: writer.WriteMessages error is checked; on failure returns 500 and logs; response sets Content-Type: application/json.
database: Unused global var DB *gorm.DB removed.

2.3 Security and configuration

TLS: config.Config has TLSInsecureSkipVerify bool (env TLS_INSECURE_SKIP_VERIFY, default false). Used in apiclient.UpdateDB and in location inference (NewDefaultInferencer(cfg.TLSInsecureSkipVerify)).
CORS: Not changed (origin policy left to operator; middleware supports configurable origins).

2.4 Observability

Health/readiness: Server exposes /health (liveness) and /ready (DB ping) via internal/pkg/api/handler/health.go.
Middleware: Recovery (panic → 500), logging (method, path, status, duration), request ID (X-Request-ID), CORS.

2.5 Code quality

Bridge: MQTT topic parsing uses strings.SplitN(topic, "/", 2) to avoid panic; CSV branch validates and logs (no writer usage yet).
Location: Magic numbers moved to named constants in internal/pkg/location/filter.go (e.g. SeenWeight, RSSIWeight, DefaultDistance).
Duplication: Bootstrap removed; each service uses internal/app/<service> for init, run, and shutdown.

3. Remaining / known limitations

3.1 Config and env

getEnvPanic in config still panics on missing required env. To avoid panics in library, consider a LoadServerSafe (or similar) that returns (*Config, error) and use it only from main with explicit exit. Not changed in this pass.

3.2 Security

CORS: Defaults remain permissive (e.g. *). Restrict to known frontend origins when deploying (e.g. via env or config).
Secrets: Still loaded from env only; ensure no secrets in logs; consider a secret manager for production.

3.3 API and validation

No OpenAPI/Swagger; no formal request/response contracts.
Many handlers still use http.Error or w.Write without a single response helper; api/response exists for new/consistent endpoints.
No request body validation (e.g. go-playground/validator); no idempotency keys.

3.4 Resilience and operations

Kafka consumer: on ReadMessage/unmarshal error, logs and continues; no dead-letter or backoff yet.
DB: no documented pool tuning; readiness only checks DB ping.
No metrics (Prometheus/OpenTelemetry). No distributed tracing.

4. Grade breakdown (updated)

Criterion	Score	Comment
Architecture	8/10	Clear app layer, thin main, pkg separation; handlers still take concrete DB/writer (can be abstracted later).
Reliability	7/10	No panics in logger/bridge init; WriteMessages errors handled; health/ready; logger fallback.
Security	6/10	TLS skip verify configurable (default off); CORS still broad; secrets in env.
Observability	7/10	Health/ready, request logging, request ID, recovery; no metrics/tracing.
API design	6/10	Response helpers and middleware in place; many handlers still ad-hoc; no spec/validation.
Testing	6/10	Good unit coverage; more integration/E2E would help.
Code quality	8/10	Clear structure, constants for magic numbers, dead code removed, duplication reduced.
Production readiness	6/10	Health/ready and error handling in place; CORS, metrics, and validation still to do.

Average ≈ 6.75; grade 7.0/10 – Refactor and applied fixes significantly improve structure, reliability, and observability; remaining work is mostly CORS, validation, and metrics/tracing.

5. Checklist (updated)

5.1 Reliability

Remove panics / log.Fatalf from library where possible (logger fallback; bridge returns error).
Check and handle WriteMessages in parser service and settings controller.
Add /health and /ready on server.
Document or add Kafka consumer retry/backoff and dead-letter if needed.
Make TLS skip verify configurable; default false.

5.2 Observability

Structured logging and request ID middleware.
Add metrics (e.g. Prometheus) and optional tracing.

5.3 API and validation

OpenAPI spec and validation.
Consistent use of api/response and JSON error body across handlers.
Restrict CORS to specific origins (operator-defined).

5.4 Operations

Document env vars and deployment topology.
Configurable timeouts; rate limiting if required.

5.5 Code and structure

Bridge topic parsing and CSV branch behavior clarified.
Unused database.DB global removed.
Location magic numbers moved to constants.
App layer and api/middleware/response in place.

6. Summary

Grade: 7.0/10 – Refactor and targeted fixes improve structure, reliability, and observability. Server has health/ready, middleware, and no panics in logger/bridge init; TLS skip verify is configurable; WriteMessages and logger errors are handled.
Still to do for production: Restrict CORS, add metrics (and optionally tracing), validate requests and adopt consistent API responses, and document operations. Config loading can be made panic-free by adding safe loaders that return errors.
Not changed by design: CORS policy left for operator to configure (e.g. via env or config).

7.7 KiB Ruw Blame Geschiedenis