API should have a Docker file so that deployment is simplified and reduced to 1 or 2 bash commands.

Routes should be tested. This can be done in a few ways and this issue may serve as a parent issue with new issues created for each type of testing.

In order to accommodate multiple contributors and ensure a stable build remains on Master branch, Gitflow would be a good adoption.

Routes should be load tested once the API is hosted.

Good example framework iv used before : https://locust.io/

Docker-compose is a very handy tool for defining and running multi container applications.

It would be good to try and utilise this in the project; but ideally we would want to find a use for it to make it worth the time. One thought is we could make use of some message queues using either RabbitMQ or ActiveMQ.
Another possible use case would be to set up a NGINX container and host 2 or more API containers for load-balancing.

Open to ideas on this.

The allStops endpoint should return all of the stops in the Galway area.

This will submit a request to RTPi and attempt to get all the stops in a X metre radius from Galway city centre.

Should be rate-limited in the future so that it isn't abused.

Currently the nearby route takes in the parameters and queries the API but doesn't find stops close to the co-ordinates. For example, taking the point of GMIT the API returned stops in Dublin.

A problem with the distance calculation possibly.

The API should be served on some Platform.

Good candidates are :
Heroku, Google Cloud, Azure, AWS in no order

This endpoint will take in 2 parameters; longitude and latitude which represent the co ordinate location we are querying for.

The endpoint should then take these co ordinates and find the nearest X stops to that location.

Depends on the stops endpoint as it will more than likely use it for information

• [] #2

Related to appsandwich/galwaybus#1

The old RTPI endpoint this repo depended on no longer works and will need to be changed.
This might require refactoring the implementation a bit.

The good news is Vinny, the original developer for the Galway bus repo, has updated his repo with the new endpoints.

@appsandwich ,do you want to try and merge our projects into an Github Org or something? I think the idea can be expanded even further.
You got a working project is JS
I had an almost working project in TS with OpenAPI documentation.

API's commonly use rate limiting to deter malicious requests aiming to slow down the system for others and also ensure clients don't just spam the routes.

The main routes which benefit most from these are the routes related to Stop resources as these are the most complex.

Seen as how we are using Typescript for this API we should be leveraging its type casting. This means that our objects are what we expect every time. With the absence of these types the code inherits some of the same shortcomings as raw JavaScript.

In the event that a type does not exist or contain all the data required for a variable we can create our own type (combine 2 or more types), and we can also use the object spread operator to combine objects together if necessary.

Server logging is very useful when trying to debug a potential error.

Some form of server logging should be set up rather than just using console.log everywhere.
A good candidate for this would be : Bunyan

Currently some of the routes have a very high cost both in terms of how long it takes to get information and how long it takes to format it.

Stops for Galway should be cached in some way to speed up queries.
This wont affect the routes which return times for a stop; in fact it should speed them up.

This may serve as a parent issue as the task is broken down into smaller ones.