fauxjira/api/README.md

Project structure

The API codebase is fairly simple and should be easy enough to understand.

File or folder	Description
src/index.ts	The entry file. This is where we setup middleware, attach routes, initialize database and express.
src/routes.ts	This is where we define all routes, both public and private.
src/constants	Constants are values that never change and are used in multiple places across the codebase.
src/controllers	Controllers listen to client's requests and work with entities and the database to fetch, add, update, or delete data.
src/database	Database related code and seeds go here.
src/entities	This is where we put TypeORM entities, you could think of them as models. We define columns, relations, validations for each database entity.
src/errors	This is where we define custom errors. The catchErrors function helps us avoid repetitive try/catch blocks within controllers.
src/middleware	Middleware functions can modify request and response objects, end the request-response cycle, etc. For example authenticateUser method verifies the authorization token and attaches currentUser to the request object.
src/serializers	Serializers transform the data fetched from the database before it's sent to the client.
src/utils	Utility(helper) functions that are used in multiple places across the codebase. For example utils/typeorm.ts functions help us validate data and avoid writing repetitive code.

What's missing?

There are features missing from this showcase API which should exist in a real product:

Migrations

We're currently using TypeORM's synchronize feature which auto creates the database schema on every application launch. It's fine to do this in a showcase product or during early development while the product is not used by anyone, but before going live with a real product, we should introduce migrations.

Proper authentication system

We currently auto create an auth token and seed a project with issues and users for anyone who visits the API without valid credentials. In a real product we'd want to implement a proper email and password authentication system.

Unit/Integration tests

This API is currently tested by the Client through end-to-end Cypress tests. That's good enough for a relatively simple application such as this, even if it was a real product. However, as the API grows in complexity, it might be wise to start writing additional API-specific unit/integration tests.