hassanshaikley/2uassessment

This is a simple assessment that candidates need to complete in order to apply for a job at 2uLaundry.

2uAssessment

The business analyst assigned to your sprint team has presented you with two user stories to complete this sprint. This assessment asks you to complete these story cards to the best of your ability.

The assessment is more about creating a working solution that meets as many of the acceptance criteria as possible than it is about getting every detail perfect. It is not necessary to complete every acceptance criteria to submit the assessment. Complete what you can and leave "TODO:" comments with appropriate placeholder instructions anywhere you are unable to complete your code. You must turn the assignment by the end of the third day after you are given the assignment.

Fork this repo and push the code to your new forked repo. Submit the forked repo's URL to [email protected]

User story 1

As a vendor supplying services to 2ULaundry I need to submit invoices via an API in order to receive payment in a timely manner.

Acceptance criteria

1. The API accepts JSON formatted HTTP POST requests at the route '/Invoice' The following is a sample Invoice request that will be submitted to the API endpoint.

{
  "invoice_number": "12345",
  "total": "199.99",
  "currency": "USD",
  "invoice_date": "2019-08-17",
  "due_date": "2019-09-17",
  "vendor_name": "Acme Cleaners Inc.",
  "remittance_address": "123 ABC St. Charlotte, NC 28209"
}

2. The API returns an HTTP 200 Response code and the following message body

{
  "message": "invoice submitted successfully"
}

3. Store the invoices in a data store of your choice with an additional property and value "status": "pending"

User story 2

As a member of the 2ULaundry Accounting Team I need to see a list of invoices that have been submitted by vendors, but have not yet been approved for payment so that I can review and approve them.

Acceptance criteria

1. Create an interface with react.js that shows a list of unapproved invoices that are submitted via API described in user story #1.
2. Display the following fields for each invoice:"Invoice Number", "Vendor Name", "Vendor Address", "Invoice Total", "Invoice Date", "Due Date"
3. Create a solution that allows the user to select and approve invoices. Once an invoice is "Approved" it should dissappear from the list of available invoices.
4. When the user approves an invoice the "status" property for that invoice should be updated to "Approved"
5. When an invoice is submitted via the API from user story #1, it should populate in the list of displayed invoices without requiring the user to manually refresh the list of invoices.

Result

Running the tests

npm run test

Note that the tests will nuke the database. This isn't ideal and the ideal solution would be to use a separate database for tests.

Running the backend

Initialize the DB

Note: This step isn't necessary because I commit the SQLite DB.

npm run migrate

Seeding the database

npm run seed will seed the database

Run the server

In a terminal window run npm start

Building the frontend

Note: This steps isn't necessary because I commit the frontend build

cd into frontend/ and run npm run build

For development I was using npm run watch

Creating Data

If you want to use the API to create data you can use this curl command.

curl --location 'localhost:3000/Invoice' \
--header 'Content-Type: application/json' \
--data '{
    "invoice_number": "1",
    "total": "2",
    "currency": "USD",
    "invoice_date": "2019-08-07",
    "due_date": "2019-09-07",
    "vendor_name": "Acme Cleaners Inc.",
    "remittance_address": "123 ABC St. Charlotte, NC 28209"
}'

Suggestions and improvements

Note: This is my first time using Typescript so please bare with me.

Use an Integer to store the total instead of a string

For example Instead of "4.99" store 499, this gets around having to worry about float math errors and allows you the flexibility of using math functions instead of having to coerce it from a string every time.

I would do the same for invoice_number. There isn't really a reason for it to be a string.

Return more specific error messages

Right now the error messages are very generic. It doesn't tell the user why the request failed. One potential improvement would be to inform the user why a request failed.

Add tests for when things don't follow a happy path

I couldn't figure out how to do this with typescript. The test compilation step fails if a parameter is missing and I don't want to make parameters optional just to allow testing.

I was able to test all of the requests in Postman so at least there's that.

Use plural as the resource name for the routes

I generally agree with what google argues here https://cloud.google.com/apis/design/resource_names

So instead of POST /Invoice for creating an invoice I would go with POST /invoices.

Validate that a currency is an accepted value

We should add validation around currency so that it is a recognized currency like USD, CAD, etc. instead of letting any string willy nilly!

Use faker-js for testing not just the seed

If I wanted to improve the testing I would use faker-js to generate values for the tests to add randomnness and improve the quality of the tests.

Validate that the due date is after invoice date

It wouldn't make sense to have a due date before an invoice date. Adding validation for this improves data quality.

Client side validation of form data

We can do some client side validation of data.

Validate that the address is a real address

Using the USPS API one can validate that an address is valid. It would be advisable to do this and recommend the closest address and display that on the frontend if it is invalid.