diff --git a/README.md b/README.md index cfa6162..0921f63 100644 --- a/README.md +++ b/README.md @@ -3,35 +3,56 @@
Auto formatted with Prettier, tested with Cypress ๐ŸŽ—

- Visit the live app | + Visit the live app | View client | View API

-![Tech logos](https://i.ibb.co/w4Y9K8Z/tech.jpg) +![Tech logos](https://i.ibb.co/0BgNRKC/logos.jpg) ![App screenshot](https://i.ibb.co/HDwwh6L/jira-clone-optimized.jpg) -## Setting up development environment +## Setting up development environment ๐Ÿ›  -1. Install postgreSQL if you don't have it already and create a database named `jira_development`. -2. `git clone https://github.com/oldboyxx/jira_clone.git` -3. Create an empty `.env` file in `/api`, copy `/api/.env.example` contents into it, and fill in your database username and password. -4. `npm run install-dependencies` -5. `cd api && npm start` -6. `cd client && npm start` in another terminal tab -7. App should now be running on `http://localhost:8080/` +- Install [postgreSQL](https://www.postgresql.org/) if you don't have it already and create a database named `jira_development`. +- `git clone https://github.com/oldboyxx/jira_clone.git` +- Create an empty `.env` file in `/api`, copy `/api/.env.example` contents into it, and fill in your database username and password. +- `npm run install-dependencies` +- `cd api && npm start` +- `cd client && npm start` in another terminal tab +- App should now be running on `http://localhost:8080/` -## Running cypress end-to-end tests +## Running cypress end-to-end tests ๐Ÿšฅ -1. Set up development environment -2. Create a database named `jira_test` and start the api with `cd api && npm run start:test` -3. `cd client && npm run test:cypress` +- Set up development environment +- Create a database named `jira_test` and start the api with `cd api && npm run start:test` +- `cd client && npm run test:cypress` + +## 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](https://github.com/typeorm/typeorm/blob/master/docs/migrations.md). + +### 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](https://www.google.com/search?q=email+and+password+authentication+node+js&oq=email+and+password+authentication+node+js). + +### Unit/Integration tests ๐Ÿงช + +Both Client and API are currently tested by through [end-to-end Cypress tests](https://github.com/oldboyxx/jira_clone/tree/master/client/cypress/integration). That's good enough for a relatively simple application such as this, even if it was a real product. However, as the app grows in complexity, it might be wise to start writing additional unit/integration tests. + +### Author: Ivor Reic โœ๏ธ + +- Website: https://codetree.co/ +- Skype handle: ivor.reic ๐Ÿ’ฌ
-

- Visit the live app | +

+ Visit the live app | View client | View API -

+ diff --git a/api/README.md b/api/README.md index abef62a..ea70a56 100644 --- a/api/README.md +++ b/api/README.md @@ -1,4 +1,4 @@ -# Project structure +# Project structure ๐Ÿ— The API codebase is fairly simple and should be easy enough to understand. @@ -16,21 +16,3 @@ The API codebase is fairly simple and should be easy enough to understand. | `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](https://github.com/typeorm/typeorm/blob/master/docs/migrations.md). - -#### 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](https://www.google.com/search?q=email+and+password+authentication+node+js&oq=email+and+password+authentication+node+js). - -#### Unit/Integration tests - -This API is currently tested by the Client through [end-to-end Cypress tests](https://github.com/oldboyxx/jira_clone/tree/master/client/cypress/integration). 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. diff --git a/client/README.md b/client/README.md index 22aff04..c7cbe33 100644 --- a/client/README.md +++ b/client/README.md @@ -1,4 +1,4 @@ -# Project structure +# Project structure ๐Ÿ— I've used this architecture on multiple larger projects in the past and it performed really well. @@ -6,6 +6,8 @@ There are two special root folders in `src`: `App` and `shared` (described below The main rule to follow: **Files from one module can only import from ancestor folders within the same module or from `src/shared`.** This makes the codebase easier to understand, and if you're fiddling with code in one module, you will never introduce a bug in another module. +
+ | File or folder | Description | | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `src/index.jsx` | The entry file. This is where we import babel polyfills and render the App into the root DOM node. |