More flows

I’ve drawn two more flows, that’s related to each other. The first is when the user gets the result of a crawl (crawl flow described here). From the frontend, the user clicks a link to show the results from a crawl (results are shown per site).

As shown in the graph, this is a really simple flow, that fetches result from the database and returns it to the client. The flow definitely looks over engineered, but this is still my naive architecture, and I think there may be benefits from following the same structure, even if one definitely could argue that a call to the database from the API endpoint would be sufficient.

The second flow is more interesting, that’s for creating a report from the result. The result of a crawl session is a list of report entries, basically a report entry has a test identifier, a success boolean and an optional fail reason. This list is what is returned to the client from the first flow.

The user then selects a number of entries to be included in a report, and post this to the API, to get a PDF report. The PDF is stored in a BlobStorage, and the information is stored in a database.

Since this is the Friday after two weeks, and that marks the date for the first feedback, I’m very excited. Am I on the right track, or am I way of?

Next week, we need to stablish vocabulary for the project, since it occurred the other day that the developer that isn’t part of my team says “report” about what we call “result”. We need that result to create the PDF-report, and since the PDF-report is obviously a report, it seems confusing to also call the crawl result a report.