New AntTP release time and this one is a bit of a whopper!
- Migrates from adhoc async command execution (for uploads) to an async command queue. Implementation uses tokio channels.
- Allows more control over command sequencing and better monitoring of progress. The command sequence is serialised to ensure order is maintained (retries and optional parallelism can be added later).
- Enables each command to be encapsulated via the command pattern, reducing complexity in the caching client.
- Further decouples caching from uploads, allowing immediate cache updates for all uploads (mutable and immutable data). Allows low latency HTTP client experience, while slow commands are executed, in sequence, in the background.
- Simplifies REST API for Scratchpads.
- Improvements to API for Scratchpads, Registers Swagger docs
- Refactors to move command module to within client module.
- Adds GetPointerCommand and CheckPointerCommand, GetGraphEntryCommand, GetPointerCommand, GetRegisterCommand, GetScratchpadCommand, to get latest version and cache it (with TTL). Allows background refreshing of cache.
- Client logic moved to above commands to simplify.
- Reduced lock time for autonomi client, as doesn’t need exclusive access. This reduces latency, improving response times.
- Removes locks from client retrieval in CreateChunkCommand and ChunkGetter to improve performance.
- Adds command endpoint to return the status of background commands. These include updating the cache for mutables, as well as mutable and immutable uploads.
- Updates supporting command and models for commands.
- Reduced logging noise
The big news are the changes to the way background tasks are handled. They used to be fired off as adhoc async jobs, but that made them isolated and harder to control or monitor. These are now moved to a channels based queue, allowing them to be executed in order, with possibilities to retry on error, etc.
There is a new /anttp-0/command swagger endpoint to go with this too. If you are running a local instance, you can see this in the usual Swagger interface: http://localhost:18888/swagger-ui/
They say pictures are worth a thousand words, so here are some:
The command log of background refreshes of the pointer cache, when hitting pages which resolve pointers to data:
Uploading a tar file with Swagger:
Then seeing the associated background command, along with when it was waiting in the queue, when it started running and when it completed.
The time figures are in milliseconds and took about 17s to upload the 2.5 MB test file (for those interested!). However, the upload page returned instantly, with the sync to the network happening in the background. EDIT: Actually, the tar file had already been uploaded, so that 17s was validating all the chunks were present - it usually takes a bit longer, which is why background tasks are nice!
To complete the picture, the AntTP log during the upload:
So, what does this all mean? Why is it important?
The goal is a slick user experience. When using AntTP web apps on Autonomi (like IMIM), two things are important:
- The user isn’t sitting waiting for something to happen on the UI. They want to do the action, it happen immediately, then do something else.
- The UI dev complexity should be as low as possible. Having a mechanism to easily post data, then easily check the status of it later is useful for this. The new command endpoint can be searched for associated tasks, then surfaced to the UI as appropriate.
Autonomi is a distributed network that thrives on being ‘eventually consistent’. This new logic embraces that behaviour, allowing the AntTP to sync with the Autonomi network without interrupting or slowing down the user flow - instead of the user waiting 17s to upload a file, it feels immediate to the user.
But isn’t the data unavailable until it is uploaded? To other people, this is true. For the user interacting with AntTP, the data is all persisted to the cache prior to the background upload. This means everything feels like it has been uploaded! Pointers, registers, scratchpads, chunks, etc… all of them are immediately accessible, creating a silky smooth user experience.
IMIM already takes advantage of these features and I’ll be adding some logic to surface the command endpoint results too. The plan is to have a status icon on the page, that will notify if there is a network sync issue. The rest of the time, it will just be out of the way of annoying the user.
Moreover, IMIM uses pointers for blogs and the app itself. These are refreshed in the background command queue now. You always get the last value, then it retrieves the latest in the background for the next request. Given there can be many duplicate pointer lookups, the new queue will discard duplicate requests (TODO: there is a bit of work to include the time-to-live again here, but that’s trivial and I’ll add it to the next release).
Anyway, probably a bit of a technical one, but I hope to do some demos with IMIM to show it all working soon!
Github: Release v0.16.2 · traktion/AntTP · GitHub
Dockerhub: https://hub.docker.com/r/traktion/anttp
Cargo: cargo install anttp
Edit: You may still need to cargo install anttp --locked if it fails to build.