I think your last chart is slightly incorrect: the game server is sending a message directly to the user, whereas it should theoretically only talk to the intermediate message queue (or frontend server)
My graph is a partial representation of the supermarket and does not contain all the goods. It has just the stuff that I've bought at least once and manually positioned into the nodes. Sometimes the supermarket decides to relocate groups of goods and I have to update my graph again, but it does not happen too often (they do it probably once or twice a year)
An app that helps me with shopping at my main supermarket.
I usually go always to the same supermarket twice a week. I was frustrated that every time I changed something in my shopping list I had to mentally recompute the optimal path to pick up everything.
Now with my app I am able to build the graph of the entire supermarket (each node represents a rack with shopping items) and then given my shopping list it computes the optimal path from the entrance to the exit. It's a version of the classical travelling salesman problem
No? In fact, if you understand what what I wrote, by generalizing this small piece of code it would mean that most of the codebase must be also partially rewritten to rust to be able to interoperate with the new data structures moved in rust. Thus these “less than 100 lines of code” refer to just this simple example program, which was fully rewritten in rust, hence, by generalizing, the premise was pointless
OP fully rewrote the example program in rust, by also moving the entire data structures there. This would mean that any interaction with these ndarrays could be possible only on the rust side, hence any other code that uses them must be rewritten, unless there’s some porting of rust ndarrays to python numpy ndarrays