waiterio/api

(school project) service api in javascript using express and node

waiterio/api 🌐

The api for the frontend of the waiter service build with postgres and node. To get started, read the installation instructions below. If would like to request a feature or report a bug, please submit an issue.

Installation

There are two ways to get the api up and running. The simplest way is to press this magical 🌈 button that deploys the project to your one of your heroku dynos.

If you'd rather get your hands dirty and do it yourself, you first of all need to clone this repository. After you have done that, you need to install the required dependencies using npm. During the installation of the required modules you might as well grab a cup of coffee (depending on your internet connection this might take a little longer).

$ npm install

After the dependencies are installed, all that's left is configuring the applications settings to your liking. You can find the settings in the settings.js file in the projects root directory.

{
	"port": 8081,
	"saltRounds": 10,
	"environment": "development",
	"secret": "SuperSecretWaiterIOStuff",
	"expireDays": 7,
	"database": "waiter.db"
}

Try it yourself

There's a live demo of this api at: https://waiterio-api.herokuapp.com/

api's Issues

LIMIT Filter for DB Queries

There should be a limit filter of how many items are returned to the api user. This should be done in the same manner as the sorting parameter.

/api/orders?limit=100

The above would result in a limit of 100 orders. It should work on every endpoint that returns more than on element.

DELETE Orders Endpoint

This endpoint will not really delete the order, but rather deactivate it and it's order items, so the reports will not be messed up.

Automatic Unit Tests

To maintain code quality and product reliability, automatic tests help to test weather new features work and if existing features did not break. There are a number of different Frameworks that are widely available, such as MochaJS and Sinon.

User Authentication for the API

Introducing a more secure API using user management and granting them access with the help of JSON Web Tokens

Endpoint for Documentation of the API

Using the designated endpoint /resources/ should be used to display general information about the API.

Use a Logger like Winston to monitor the API

A Logger can be used to log stuff. Logging stuff is good.

bad db initialization

https://github.com/waiterio/api/blob/master/common/postgres.js

• that will re-load and re-initialize the entire database layer every time you are calling getConnection. That's a really bad design ;)

What you do there should be done only once.

Auth service for the admin-login

Potentially later it is also used for a multiple user login. I think about a registration form for new users which get access on our servers with waiterio. This differs from our currently "self hosted open source" approach. What do you think? Maybe a free plan for developers and a cheap one for non technicians?

Sorting Options for all Data Endpoints

Like the /orders/ endpoint, all other endpoints such as /dishes/ and /users/ deserve the same sorting capabilities. This can be easily achieved by using the already common function getOrderByQuery from the DBHelpers.

Make categories_id of the dishes table optional

Reason behind this is that dishes should be allowed to exist without a category

dishes: POST file upload

The dishes POST endpoint have to accept and process the dishes->image. The process should check if the image is valid (eg. image size...) and save it to a image database. Maybe a AWS service could be senseful for this!?

dishes: POST returns a 500 error

a complete OAuth Implementation

https://hueniverse.com/oauth/guide/terminology/

WebSockets Order Stream for the Kitchen Order View

Let us build a little socket service for that! http://socket.io/

Can't convert INT to currency

Convert database field type for price to float

dishes: DELETE returns a 500 error

Global Validation for Input that has to go in the DB

A general validation object that can be given a set of inputs and simple rules which it then validates the data against and returns true or false as in valid or invalid.

Authentication Rate Limit

To improve security and protect the api against basic brute force attracts, a rate limit should be enforced on all /auth endpoints

"Deploy to Heroku" Button

Allowing anyone to deploy a working copy of this project to their Heroku Account with the push of a button. Instructions can be found here: https://devcenter.heroku.com/articles/heroku-button

Essentially it is adding an app.json file to the root of this project containing information about the project

{
  "name": "Node.js Sample",
  "description": "A barebones Node.js app using Express 4",
  "repository": "https://github.com/heroku/node-js-sample",
  "logo": "https://node-js-sample.herokuapp.com/node.png",
  "keywords": ["node", "express", "static"]
}

Also the Button must be included in the README.md File, like so

[![Deploy](https://www.herokucdn.com/deploy/button.svg)](https://heroku.com/deploy)

Flaky Test "testOrders.js"

This seems to be a little bit flaky, maybe a race condition. Occasionally Travis says this endpoint returns an empty array instead of the data. It should be investigated. Example of a broken build: https://travis-ci.org/waiterio/api/builds/130572053