See T1889:
- Server side: add endpoint handling, main class, unit tests
- Client side: add endpoint handling
- Documentation: add endpoint dedicated section
Details
Details
- Reviewers
zack seirl - Commits
- rDGRPHd04c698a7f92: Add new 'leaves' API endpoint
Diff Detail
Diff Detail
- Repository
- rDGRPH Compressed graph representation
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
Comment Actions
As observed above, the code structuring isn't great, but I'm accepting nonetheless to get the interface and tests in, as a stable point, we'll plan a more general refactoring of all the algos implementation.
| api/server/src/main/java/org/softwareheritage/graph/algo/Leaves.java | ||
|---|---|---|
| 33–38 | This pattern of computing the algo result in the constructor, storing it (potentially forever), and returning it upon get() isn't great. More generally, algorithms are not great fit for dedicated classes, as they tend to be stateless, like all our visit-ish algorithms. We should revisit this to have algorithms as methods of a graph class that contains the nodes/edges and aggregate (via composition) external maps. I'm approving this diff anyway, as it doesn't make things worse than existing algorithms, but we should revisit the approach. | |
| 40 | I'm guessing this is the same dfs code (more or less) of the dfs we have behind visit. Having algorithms as methods rather than classes would also ease reusing them more easily across the implementation of different endpoints. | |