Details
-
New Feature
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
Description
The python backend should start with a statement about how it is run as a Flask web app which facilities the API, along with swagger being used for the API documentation. There should then be quick overview of the cluster connection.
The endpoint functions should be explained in the following order, which roughly follows the order in which the user progresses through the app:
- signup - A basic K/V insert op, the first thing both the user and developer will do.
- login - The next logical step, a K/V get op.
- flightPaths - this provides the main functionality so should be done before the autofill, despite the fact the user will encounter it after the autofill.
- airport name - this can be introduced on the idea that the user may not know what the database knows the airport names as, so we need an autofill.
- updateflights - The "Buy" button after the user has added the flight to their cart. We can explain that the cart is managed locally vue as we don't need to store the cart data in the database.
- getflights - The user will usually immediately check that their flight has been stored, so we can talk about the need for RYOW here.
- hotels - Done last, both as this is FTS (more complex than query), and is the most likely the last thing the user will use.
Any changes/fixes needed for the try-cb-python repo, be this documentation or structural, will be included under this ticket.