You can clone this repository but do not fork it

We will be building the API to use in the Northcoders News Sprint during the Front End block of the course.

Your database will be PSQL, and you will interact with it using Knex.

Clone this repo:

git clone https://github.com/northcoders/be-nc-news

cd be-nc-news

On GitHub create your own public repository for your project. Make sure NOT to initialise it with a README or .gitignore.

Next, you should hook your local version up to the newly created GitHub repo. Use the following terminal commands, making sure to check the git remotes with each step (git remote -v):

git remote remove origin

# This will prevent you from pushing to the original Northcoders' repo.

git remote add origin <YOUR-GITHUB-URL>

# This will add your GitHub location to your local git repository.
# You can confirm this by checking the new git remote.

In this repo we have provided you with the knexfile. Make sure to add it to the .gitignore once you start pushing to your own repository. If you are on linux insert your postgres username and password into the knexfile.

You have also been provided with a db folder with some data, a setup.sql file, a seeds folder and a utils folder. You should also take a minute to familiarise yourself with the npm scripts you have been provided.

Your second task is to make accessing both sets of data around your project easier. You should make 3 index.js files: one in db/data, and one in each of your data folders (test & development).

The job of index.js in each the data folders is to export out all the data from that folder, currently stored in separate files. This is so that, when you need access to the data elsewhere, you can write one convenient require statement - to the index file, rather than having to require each file individually. Make sure the index file exports an object with values of the data from that folder with the keys:

• topicData
• articleData
• userData
• commentData

The job of the db/data/index.js file will be to export out of the db folder only the data relevant to the current environment. Specifically this file should allow your seed file to access only a specific set of data depending on the environment it's in: test, development or production. To do this is will have to require in all the data and should make use of process.env in your index.js file to achieve only exporting the right data out.

HINT: make sure the keys you export match up with the keys required into the seed file

Your seed file should now be set up to require in either test or dev data depending on the environment.

You will need to create your migrations and complete the provided seed function to insert the appropriate data into your database.

This is where you will set up the schema for each table in your database.

You should have separate tables for topics, articles, users and comments. You will need to think carefully about the order in which you create your migrations. You should think carefully about whether you require any constraints on your table columns (e.g. 'NOT NULL')

Each topic should have:

• slug field which is a unique string that acts as the table's primary key
• description field which is a string giving a brief description of a given topic

Each user should have:

• username which is the primary key & unique
• avatar_url
• name

Each article should have:

• article_id which is the primary key
• title
• body
• votes defaults to 0
• topic field which references the slug in the topics table
• author field that references a user's primary key (username)
• created_at defaults to the current timestamp

Each comment should have:

• comment_id which is the primary key

• author field that references a user's primary key (username)

• article_id field that references an article's primary key

• votes defaults to 0

• created_at defaults to the current timestamp

• body

• NOTE: psql expects Timestamp types to be in a specific date format - not a unix timestamp as they are in our data! However, you can easily re-format a unix timestamp into something compatible with our database using JS - you will be doing this in your utility function... JavaScript Date object

You need to complete the provided seed function to insert the appropriate data into your database.

Utilising your data manipulation skills, you will also need to complete the utility functions provided - formatDate, makeRefObj, and formatComments for the seed function to work. Instructions on these utility functions are in the utils README.

Some advice: don't write all the utility functions in one go, write them when you need them in your seed

• Use proper project configuration from the offset, being sure to treat development and test environments differently.
• Test each route as you go, checking both successful requests and the variety of errors you could expect to encounter See the error-handling file here for ideas of errors that will need to be considered.
• After taking the happy path when testing a route, think about how a client could make it go wrong. Add a test for that situation, then error handling to deal with it gracefully.
• HINT: You will need to take advantage of knex migrations in order to efficiently test your application.

Your server must have the following endpoints:

GET /api/topics

GET /api/users/:username

GET /api/articles/:article_id
PATCH /api/articles/:article_id

POST /api/articles/:article_id/comments
GET /api/articles/:article_id/comments

GET /api/articles

PATCH /api/comments/:comment_id
DELETE /api/comments/:comment_id

GET /api

All of your endpoints should send the below responses in an object, with a key name of what it is that being sent. E.g.

{
  "topics": [
    {
      "description": "Code is love, code is life",
      "slug": "coding"
    },
    {
      "description": "FOOTIE!",
      "slug": "football"
    },
    {
      "description": "Hey good looking, what you got cooking?",
      "slug": "cooking"
    }
  ]
}

GET /api/topics

• an array of topic objects, each of which should have the following properties:
  • slug
  • description

GET /api/users/:username

• a user object which should have the following properties:
  • username
  • avatar_url
  • name

GET /api/articles/:article_id

• an article object, which should have the following properties:

  • author which is the username from the users table
  • title
  • article_id
  • body
  • topic
  • created_at
  • votes
  • comment_count which is the total count of all the comments with this article_id - you should make use of knex queries in order to achieve this

PATCH /api/articles/:article_id

• an object in the form { inc_votes: newVote }

  • newVote will indicate how much the votes property in the database should be updated by

  e.g.

  { inc_votes : 1 } would increment the current article's vote property by 1

  { inc_votes : -100 } would decrement the current article's vote property by 100

• the updated article

POST /api/articles/:article_id/comments

• an object with the following properties:
  • username
  • body

• the posted comment

GET /api/articles/:article_id/comments

• an array of comments for the given article_id of which each comment should have the following properties:
  • comment_id
  • votes
  • created_at
  • author which is the username from the users table
  • body

• sort_by, which sorts the comments by any valid column (defaults to created_at)
• order, which can be set to asc or desc for ascending or descending (defaults to descending)

GET /api/articles

• an articles array of article objects, each of which should have the following properties:
  • author which is the username from the users table
  • title
  • article_id
  • topic
  • created_at
  • votes
  • comment_count which is the total count of all the comments with this article_id - you should make use of knex queries in order to achieve this

• sort_by, which sorts the articles by any valid column (defaults to date)
• order, which can be set to asc or desc for ascending or descending (defaults to descending)
• author, which filters the articles by the username value specified in the query
• topic, which filters the articles by the topic value specified in the query

PATCH /api/comments/:comment_id

• an object in the form { inc_votes: newVote }

  • newVote will indicate how much the votes property in the database should be updated by

  e.g.

  { inc_votes : 1 } would increment the current comments's vote property by 1

  { inc_votes : -1 } would decrement the current comments's vote property by 1

• the updated comment

DELETE /api/comments/:comment_id

• delete the given comment by comment_id

• status 204 and no content

If you have reached this point, go back and review all of the routes that you have created. Consider whether there are any errors that could occur that you haven't yet accounted for. If you identify any, write a test, and then handle the error. Even if you can't think of a specific error for a route, every controller that invokes a promise-based model should contain a .catch block to prevent unhandled promise rejections.

As soon as you think that you have handled all the possible errors that you can think of, let someone on the teaching team know. One of us will be able to take a look at your code and give you some feedback. While we are looking at your code, you can continue with the following:

GET /api

• JSON describing all the available endpoints on your API

Make sure your application and your database is hosted using Heroku

See the hosting.md file in this repo for more guidance

Write a README for your project. Check out this guide for what sort of things should be included.

It should also include the link to where your Heroku app is hosted.

Take a look at GitHub's guide for mastering markdown for making it look pretty!

To make sure that an API can handle large amounts of data, it is often necessary to use pagination. Head over to Google, and you will notice that the search results are broken down into pages. It would not be feasible to serve up all the results of a search in one go. The same is true of websites / apps like Facebook or Twitter (except they hide this by making requests for the next page in the background, when we scroll to the bottom of the browser). We can implement this functionality on our /api/articles and /api/comments endpoints.

GET /api/articles

• Should accepts the following queries:
  • limit, which limits the number of responses (defaults to 10)
  • p, stands for page which specifies the page at which to start (calculated using limit)
• add a total_count property, displaying the total number of articles (this should display the total number of articles with any filters applied, discounting the limit)

GET /api/articles/:article_id/comments

Should accept the following queries:

• limit, which limits the number of responses (defaults to 10)
• p, stands for page which specifies the page at which to start (calculated using limit)

POST /api/articles

DELETE /api/articles/:article_id

POST /api/topics

POST /api/users
GET /api/users