The client first requests stops from the TS server (`0.0.0.0:80`), then the path from the Dart server (`localhost:8001`). It will be trivial to move the TS logic to the Dart server since the Dart server is the one that parsed all that data, and it's anyway in a `JSON` file.
There is a `server/GET_ROUTES.json` file, but it's not needed. I just included it for easier debugging. `server/GET_STOPS.json` includes both the stops and the routes, and the client does some (inefficient) work to re-organize it.
The Dart server uses a basic A* implementation to sort find direct routes and routes with transfers. The A* logic is in `src/shared/lib/src/graph/graph.dart`. This file defines the state itself, and `package:a_star` on Pub.dev (mine) defines the algorithm. `src/shared/bin/path.dart` is the whole of the Dart server.
TODO:
- add unit tests
- this PR breaks almost nothing, so there is duplicate work being done on the client and some unused logic
- return a structured path object for the client to use as it wants. This PR just sends a well-formatted string
Makes a new (dart) package called `shared`, which contains:
- the code needed to parse through OCCT and BC data
- any data definitions for types in that data (eg, stops)
- shared utils
The client will then import types from this package. This PR also re-generates the GET_STOPS json file to include OCCT
