Ki-labs Restful endpoint is a solution to the coding test sent by Ki-labs
Spring Boot was chosen because of the ease of use and the ease of bootstrapping an application with minimal effort.
Postgresql was chosen because it is the most advanced, SQL-compliant and open-source objective-RDBMS since it tries to adopt the ANSI/ISO SQL standards together with the revisions.
Also it's support for concurrency is achieved without read locks thanks to the implementation of Multiversion Concurrency Control (MVCC), which also ensures the ACID compliance.
It is highly programmable, and therefore extendable.
To start your application in the dev profile, simply run:
./gradlew
Don't forget to set the following env vars:
- SPRING_DATASOURCE_URL
- SPRING_DATASOURCE_USERNAME (Optional based on postgres setup)
- SPRING_DATASOURCE_PASSWORD (Optional based on postgres setup)
To optimize the restful application for production, run:
./gradlew -Pprod clean bootRepackage
To ensure everything worked, run:
java -jar build/libs/*.war
You can also fully dockerize the application and all the services that it depends on. To achieve this, first build a docker image of your app by running:
./gradlew publish
Then run:
docker-compose -f docker/app.yml up -d
or simply run ./publish.sh
You can access the app using any of the JSON client using the url /v1
Both employees and candidates has the same properties:
- first name
- last name
All CRUD operations for the employees managed under employees resource
Method | URI | Description |
---|---|---|
GET | /v1/employees | list all employees |
POST | /v1/employees/{id} | create employee |
PUT | /v1/employees/{id} | update employee |
DELETE | /v1/employees/{id} | delete employee |
GET | /v1/employees/{id} | show employee |
The same goes for Candidates under the resource
candidates
Expected availability model is as follows:
- day: Day of the next week to submit the availability Available Values are
SATURDAY,SUNDAY,MONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIDAY
- person_id: either a candidate or an employee based on the URI provided
- times: Array of available hours in that day with two propertied:
- from: integer value representation of hours and minutes e.g 1500 means 15:00
- to : integer value representation of hours and minutes
Submitting availability would be done under /v1/<resource>/submit-availability
with a POST
request for the following resources:
- employees
- candidates
Getting available times for interview is done by sending a GET
request to the URI /v1/candidates/{id}/possible-interview-times?interviewers={id1}&&interviewer={id2}..
it will return employees submitted time slots that matches the available time slots for this candidate.
In this section I'll share some of the questions and points that I had in mind but due to the time limit I had to make a lot of assumptions and cut back the test to the barebones of the requirements:
- The Interview matching can be done using the Knapsack strategy trying to fit the interviewer time slots to employees free time slots
- The model needs a some of alteration to work properly since it assumes that employees and candidates only submit availability of the next week.
/v1/<resource>/submit-availability
URI can be altered to be/v1/<resource>/{id}/submit-availability
and in that case we wont need theperson_id
in the request body.- Validation should be done in the availability submission so users can't submit overlapping availability time slots
- Upon the creation of the interview the time slot should be split in two different time slots with one marked as occupied and the remaining time slot should be marked as free.
- Do we need to have authentication and authorization over the api calls and over the data?
- Do we want to use Oauth Mechanism or JWT if we decided to implement authentication?
- What is the API versioning strategy? using sub-domains or include the api version in the URI?
- what are the content types that are accepted to be served by the app
- Can we use ETag for caching?
- what kind of protocols our app supports?