make up
- Run the api available on 0.0.0.0:3000
make down
to shut down the api
The whole project is composed of an api service, a postgres database and a redis cache (currently unused).
The api container is built using air
which is a hot-reload go docker image used solely for development
The project is split between 3 layers (packages) each with its own purpose. Each layer is independent of the layers below and its dependencies could be abstracted with mocks:
-
rest/
- Here lies all logic regarding request/response processing, payload validation and middlewares such as authentication
-
service/
- Here lies all the business logic of the application where for instance, upon performing a login (
/login
) the user email is validated, the password is compared against the hashed password which is stored and the token is generated
- Here lies all the business logic of the application where for instance, upon performing a login (
-
respository/
- Here lies all data retrieval functionality where the data access is abstracted using interfaces to obscure the type of datasource. For instance
UserRepository
currenlty uses a postgres database but it could be changed to MySQL / MariaDB / MongoDB without compromising the layers above it with changes
- Here lies all data retrieval functionality where the data access is abstracted using interfaces to obscure the type of datasource. For instance
For the /discover
endpoint logic the following assumptions were made:
attractiveness_score
is calculated based on positive swipes from a user representing the likelyhood of a future match. For ex. if a user has the tendency to positively swipe across other profiles then it is more likely that it has partial match to the current user
distance
is calculated using the postgres earthdistance
extension (https://www.postgresql.org/docs/current/earthdistance.html)
The returing profiles are sorted by attractiveness_score and closer distance to the current user.
-
/swagger
: auto generated api docs -
/healthz
: for checking service is healthy -
/user/create
: for creating a profile -
/login
: for authenticating a user -
/swipe
: for simulating a user swipe over a profile -
/discover
: for returing interesting profiles for a user with the following optional parameters:min_age
: number detailing minimum age for a prospective profilemax_age
: number detailing minimum age for a prospective profilegender
: the profile gender (M | F)
All requests go through a layer of validation using the https://github.com/go-playground/validator
package
-
Add unit tests: due to lack of time I mostly focused on developing the features and setting only partial e2e tests using
hurl
(https://hurl.dev) available on/hurl
folder of the repo. Unit test would provide an additional layer of safety to the source code. -
Add
/user/delete
endpoint to make each e2e test self sufficient. Currently we need to clear the db after each hurl test run as the user would fail the email validation upon creation -
Optimize discover query: The discover query would perform badly in large datasets, specially the portion where the
attractiveness_score
is calculated. This calculation could be abstracted in a db view. -
Add ci/cd pipeline to run unit tests and hurl e2e tests
-
Improve
/healthz
by pinging db and cache for ensuring connections/repositories are up