hubwork

A demo freelancing REST API

Getting started

I'm using docker support for spring boot. So you can just up the API with

$ ./gradlew bootRun

If you want to up it without docker, please do as instructed in build.gradle.kts:

remove spring-boot-docker-compose and postgresql from classpath
add h2 to classpath

When creating jobs and requests, owner_ids and worker_ids must be provided. Note that,

ODD id numbers corresponds to CUSTOMERS and
EVEN id numbers to WORKERS and
20 users and 5 businesses are populated at startup.
use app.setup.count.user and app.setup.count.business to change these numbers

For example, following payload is invalid when creating a Job

{
  "title": "Job 1",
  "description": "My first job",
  "price": 1000,
  "state": "PENDING",
  "due_date": "23-07-2023",
  "currency_code": "USD",
  "owner_id": 2,
  "payment_methods": [
    "CREDIT_CARD"
  ]
}

It would be valid if $.owner_id is 1 (or any other odd number)

Caveats

I have used several non-standard practices while implementing this to save time. While some are not optimal, some are my personal preferences. In addition to the following, there could be other bad or non-standard practices. But these are the significant ones I can think of.

Not using DTOs

I'm not using DTOs but endpoint-specific payloads and carefully serialized entity objects for this API.

Endpoint-specific payload is helpful since this is a small project; with them, I could evolve my API as I wrote it. Separate validations are possible for separate endpoints with their payload type being different. See:

Since my JPA entities are directly exposed through API, I have used @JsonIgnore and @JsonProperty to transform my entities into a more suitable shape at serialization. See:

Directly using Hibernate-Validator

Here, I have deviated from the standard practice of using @Valid with @ControllerAdvice or @ExceptionHandler to implement validations. I'm using my own ApiError inspired by the ProblemDetail specification. While using an exception handler with ProblemDetail would be the more architecturally clean approach, I chose to use this ApiError:

It gives me more control over the error responses
Since this is a small API, I don't have to create an unnecessary array of exception types, which then I would use with exception handlers

Things I could not do on time

Tests for Request management.

I could not write the test cases for RequestService and RequestApiController. Currently, the only way to test these functionalities is with the swagger UI.

Mail notification.

This is under development at the time of writing this document. I'll push it under a different branch when completed.

UPDATE (06 July 2023): A basic implementation of mail notifications has been added. However there are several things to improve

nisalb / hubwork