d0387c7aa2
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 |
||
|---|---|---|
| .. | ||
| bin | ||
| lib | ||
| .gitignore | ||
| CHANGELOG.md | ||
| pubspec.yaml | ||
| README.md | ||
A sample command-line application with an entrypoint in bin/, library code
in lib/, and example unit test in test/.