Java Interview

Introduction

This is a microservice that is responsible for managing biological samples sent by patients to Delfi Diagnostics'. As a company, one of Delfi's main product is a diagnostic for cancer. A patient's blood is drawn by a phlebotomist and sent to Delfi's lab. This biological sample is analyzed by Delfi to determine if the patient has cancer or not. The result is sent back to the patient's physician.

The main responsibility of this microservice is to manage the lifecycle of the patient's biological sample. It exposes various REST endpoints that make up its contract for any calling service. For the purpose of this exercise it has been simplified to support the following functionality:

1. Authorized users can retrieve a paged list of all subjects
2. Authorized users can retrieve a particular subject based on its id
3. Authorized users can retrieve a particular subject based on its external id (an id given to the subject by our customer)
4. Authorized users can retrieve a paged list of all samples
5. Authorized users can retrieve a particular sample based on its id
6. Authorized users can accession a sample. This involves creating a subject, and their associated samples

Schema

The database is in Postgres and there are only two tables in the database.

graph LR;
	Subject -- has 1 or more --> Sample

Loading

A Subject has 1 or more Samples. Subject has the following properties:

• id: numeric (primary key)
• external_id: varchar
• create_dt: timestamp
• create_by: varchar
• mod_dt: timestamp
• mod_by: varchar

Sample has the following properties:

• id: numeric
• sample_type_id: varchar
• collection_date: timestamp
• subject_id: numeric (foreign key to subject.id)
• create_dt: timestamp
• create_by: varchar
• mod_dt: timestamp
• mod_by: varchar

System Architecture

The system is built-in on Micronaut framework. The system borrows principles from Domain-Driven Design and as such is structured along its two main domain models:

• sample
• subject

Each domain contains:

• A Feature class which contains all the business logic associated with the domain
• One or more model classes that represent DTOs and/or the database entity
• One or more repository classes that use JPA/Hibernate to interact with the database
• One or more controller classes that expose the REST endpoints and enforce authorization rules

flowchart LR;
	U((User)) --> |1. Authenticate| A[Auth0] .-> |2. JWT Token| U((User))
	U((User)) --> |3. GET w/ Bearer jwt token| Ctrl[Controller]
	Ctrl[Controller] ---> |4. Verifies token| A[Auth0]
	Ctrl[Controller] --> |5| Ft[Feature] .-> |10| Ctrl[Controller]
	Ft[Feature] --> |6| Repo[Repository]
	Repo[Repository] --> |7. JPA| d[(DB)]
	d[(DB)] .-> |8| Repo[Repository]
	Repo[Repository] .-> |9| Ft[Feature]
	Ctrl[Controller] ..->|11| U((User))
	style Ft stroke:#333,stroke-width:4px

Loading

Flow

Here is the standard user flow for accessing the service. A User authenticates with a separateAuth service to get a JWT token. The token includes the permissions granted to the user. The User then makes an HTTPS request to the service which is received by the Controller. The Controller verifies the JWT token for authenticity using the Auth service. It also checks if user has appropriate permissions based on the permissions present in the JWT token. The Controller deserializes the request and calls the Feature class which in turn handles all the business logic. Feature class uses the Repository class to interact with the database and returns any results back to the User via the Controller.

Exercise

Fix test

In this exercise we will fix a broken test

Add a feature (Optional)

In this exercise we will implement the feature to expose a REST endpoint to accession a new sample.