Initial implementation of Assets Favourites API service by nikoumba · Pull Request #60 · GlobalWebIndex/platform-go-challenge

nikoumba · 2025-12-11T11:02:15Z

Summary

This PR introduces the initial version of the Assets Favourites API service. It exposes endpoints for managing per-user favourites (list, add, remove, edit description) across different asset types (chart, insight, audience).

What’s included

HTTP API for:
- GET /v1/users/{userId}/favourites (with type filter + pagination)
- POST /v1/users/{userId}/favourites
- DELETE /v1/users/{userId}/favourites/{assetId}
- PATCH /v1/users/{userId}/favourites/{assetId}
Domain layer for favourites and assets, with validation and service logic
In-memory repository with concurrency safety (RWMutex) and deterministic pagination
Simple auth abstraction (X-User-ID header) wired as middleware
Observability:
- /health endpoint
- /metrics (Prometheus)
- Docker + Prometheus + Grafana stack with a basic dashboard
OpenAPI spec file
Tests:
- Unit tests for domain, repository, service, handlers, and infrastructure
- Basic integration tests through the HTTP router
Makefile for a consistent local workflow (make fmt, make test, make run, etc.)
Design documentation

How to run

# Using Makefile
make run

# Or directly with Go
go run ./cmd/api

# Or run full stack (API + Prometheus + Grafana)
docker compose up --build

Submitted by Nikos Koumbakis as part of the GWI Engineering take-home challenge.

…metrics endpoints

…health check endpoint

…tion

…mits

… review

…smatch

dzacharakis

Hi @SpiralOutDotEu 👋

Thanks for your work on this assignment!

I added some comments on your PR with a few questions. I’d love to hear your feedback when you get a chance.

Thanks,
Dimitris

dzacharakis · 2025-12-17T15:58:48Z

+	Chart       *ChartPayload    `json:"chart,omitempty"`
+	Insight     *InsightPayload  `json:"insight,omitempty"`
+	Audience    *AudiencePayload `json:"audience,omitempty"`


Could there be a case where more than one is set?

Good catch. Right now the mapper uses the field that matches the type on the model and silently ignores any extras.
Even that the domain model enforces a single variant, it would be better to validate this at the DTO/mapper level and early reject payloads when more than one is set.

dzacharakis · 2025-12-17T16:05:05Z

+
+# HTTP listen address for the API (matches internal/config)
+# If unset, the service defaults to :8080
+HTTP_ADDR=:8080


How would you use secret keys as environment variables in a production-grade application?

Depending on the deployment environment, I’d use a secret manager (AWS/Azure/GCP) or HashiCorp Vault with clear rotation policies and access control, and have the platform inject them as environment variables or files.

dzacharakis · 2025-12-17T16:15:50Z

+	Chart    *Chart
+	Insight  *Insight
+	Audience *Audience


Could you explain why you selected this option? Can you identify any other possible alternatives?

I looked at a couple of options here. Go-style polymorphism (an Asset interface with ChartAsset / InsightAsset / AudienceAsset) would definitely work, but for this small service it felt like unnecessary extra complexity and type switches for what is basically a “shape of data” problem.

I ended up with a tagged union instead, as it stays type-safe and keeps the JSON side simple. If this were a bigger system and assets had more behaviours, I’d probably use an Asset interface with concrete types for each asset kind.

dzacharakis · 2025-12-17T16:44:27Z

+
+	// userFavourites stores favourites per user:
+	//   userID -> assetID -> Favourite
+	userFavourites map[string]map[string]favourites.Favourite


What would occur if two users happen to mark a specific asset as a favourite?
How could you implement functionality to retrieve all users who have favourited an asset?

This was a simplification assumption, in order to keep it small for this take-home task.
As it is now, two users favoriting the same asset by content, will get two separate assets.
In a real system, asset should be a separate entity with their own lifecycle, and favourites would point to their assetId, instead of the full content.
In order to be able to support users who have favourited an asset, I'd add a reverse index, like assetId->[]userId and a ListUsersByAssetId(ctx, assetId) method.

dzacharakis · 2025-12-17T16:54:27Z

+		return
+	}
+
+	entry, err := h.svc.AddFavourite(ctx, userID, domainAsset)


If I understand correctly, AddFavourite doesn’t just assign an existing asset to a user—it both creates the Asset and marks it as a favourite. Shouldn’t the Asset already exist beforehand? Typically, you could only add something as a favourite once it already exists.

Yes correct. Same as the previous comment, this was a simplification assumption in order to focus on the favourites handling.
On a real system I would expect that assets are generated from other processes, so that our favourites entity would be a join of userId, assetId and the custom description.
So the schema would be (userId, assetId, customDescription)

dzacharakis · 2025-12-17T17:02:45Z

+
+.PHONY: all tidy fmt vet build test run
+
+all: tidy fmt vet build test


Nice — providing a Makefile with common commands is helpful. Is there any Go development tool that might be missing from this list and could add value?

I’d add a stronger linter like golangci-lint or staticcheck, and definitely a test coverage target.

nikoumba · 2025-12-18T09:33:43Z

Hi @dzacharakis ,

Thanks a lot for taking the time to review the assignment and for your comments.
I’ve gone through them and replied inline.

Happy to clarify anything further.

Nikos

dzacharakis · 2025-12-18T11:24:55Z

Thank you too, Nikos, for your responses to my comments.
All good on my end. Good luck with the next steps, and wishing you a Merry Christmas and happy holidays!

nikoumba · 2025-12-18T12:33:41Z

Merry Christmas and happy holidays!

nikoumba added 22 commits December 7, 2025 19:23

docs: add challenge description and context

5b45ef2

docs: define domain model and core use cases

98e5750

docs: add api shape and openapi spec

fecd6d3

docs: add architecture and coding standards

681baa8

docs: add README with architecture and documentation overview

98cbd6d

docs: update API shape with error responses and add health check and …

b5b24fc

…metrics endpoints

chore: initialize project structure with configuration, routing, and …

7492039

…health check endpoint

feat(domain): add favourites models and repository interface

dffc8fb

feat(repository): add in-memory favourites repository implementation

7fa6238

feat(domain): add favourites service layer

278141a

feat(api): add v1 favourites HTTP layer

2791bbd

feat(app): wire favourites routes and add integration tests

91a9af1

feat(auth): add pluggable authenticator and user auth middleware

9a1a84f

feat(logging): add request logging middleware and wire router

ad408cb

feat(metrics): add prometheus http metrics and middleware

480ff60

chore(observability): add docker stack with prometheus and grafana

8e12209

chore(test): standardize test function names to use underscore conven…

40d5ba1

…tion

feat(favourites): add paginated listing support with service-level li…

72a0742

…mits

chore(go): align module to go 1.24 for wider compatibility and easier…

45d06c5

… review

fix(auth): tighten user-bound routing and add integration test for mi…

239340f

…smatch

fix(docs): align OpenAPI spec with actual implementation

31fe7ad

docs: improve README and add review scenario

22f2107

dzacharakis reviewed Dec 17, 2025

View reviewed changes


		.PHONY: all tidy fmt vet build test run

		all: tidy fmt vet build test

Conversation

nikoumba commented Dec 11, 2025

Uh oh!

dzacharakis left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nikoumba commented Dec 18, 2025

Uh oh!

dzacharakis commented Dec 18, 2025

Uh oh!

nikoumba commented Dec 18, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants