The goal of this task is to provide an API with two endpoints: one for creating messages using the POST method and the other for reading a list of them. The reading endpoint should be paginated with cursor$-$based pagination $($for more details take a look at "Hints" section$).$

Requirements

The API must contain two endpoints:

POST $/$messages

$1.$ This endpoint will create a message stored in the local SQLite DB by calling provided saveMessage function. Each created message will receive an incremental id field from the database.

$2.$ The payload body of this request will look like this:

$```$json

$\{$

"date": $"2019-11-11",$

"author": "John",

"channel": "general",

"text": $"$Hi there"

$\}$

$```$

$3.$ The request will return a successful response with status code $201$

and no payload.

$4.$ If any of the properties is missing, the service should instead return a

$422$ status code.

GET $/$messages

$1.$ The endpoint should return the messages that are returned by findMessages function. This function does not accept any parameters and returns a Promise of all messages stored in the database. Order of those messages is not guaranteed.

$2.$ If no query parameters are specified, this endpoint will return all messages sorted by internal DB index $($propert id D$),$ in descending order. The default count of records will be $10.$

$3.$ The client may provide the following query parameters:

$3\mathrm{.}1.$ count $($number$)$ specifies the number of returned messages $($default: $10)$

$3\mathrm{.}2.$ next specifies a cursor pointing to the next record for the given request $($default: first records should be returned$)$

$-$ Clients should take next cursor from the payload of one of the requests $($see payload below paging.next$).$

$-$ Calling GET $/$messages with a next

cursor will give the

issuer the next data for the given query. e$.$g$.$ given messages A$,$ B$,$ C$,$ D$,$ first request with count $2$ returned messages D$,$ C and a next cursor. Sending second request with this next value and count $2$ should returns the next $2$ records: B and A$.$

$-$ If there is nothing to show in the next cursor then the next

property must be set to the empty string.

$-$ Adding new message should not result in any shifting or duplication of records while paging.

For example, say the request GET $/$messages has a total of $100$ messages. Initially, the first $10$ are returned with a cursor for messages $11-20.$ If a new message is then added, the query with a cursor must still return the messages that were previously in places

$11-20,$ even though they are actually $12-21$ now.

$4.$ Example payload of a response looks like this:

$```$json

$\{$

"data": $[$

$\{$

"date": $"2019-11-12",$

"author" : "John"

"channel": "general",

"text": $"$Hi hi$"$

$\},$

$\{$

"date": $"2019-11-11",$

"author": "John",

"channel": "random",

"text": $"$Hi there!"

$\}$

$],$

"paging":$\{$

"next": $"$MTMzNw$=="$

$\}$

$\}$

$```$

$5.$ Sorting by id

should result in the newest messages being shown

first. So if client adds messages A$,$ B$,$ C$,$ D $($in that order$)$ then by requesting GET $/$messages$?$count$=2$ they should gif messages D and C$.$

Hints

$1.$ You can store data in a cursor in any way you want as long as the endpoint behaves as required. This might be just an id of the last record or encoded structure.

$2.$ Common approach is to use id s from DB and filter the records that contain only higher$/$lower id$.$

This is possible when the id

is set by the database incrementally.

$3.$ Relying on internal "indexing" $($id field$)$ of the data to ensures that adding new messages will not "break" the cursor.

$4.$ The task uses following versions of dependencies:

$\{$

"dependencies": $\{$

"body$-$parser": $"1\mathrm{.}19\mathrm{.}0",$

"express": $"4\mathrm{.}17\mathrm{.}1"$

$\}$

$\}$