eonist / cuekit Goto Github PK

View Code? Open in Web Editor NEW

1.0 0.0 0.0 16 KB

🚂 Interruptible queuing system for closures

Swift 100.00%

queue asynchronous async retry timeout

cuekit's Introduction

CueKit 🚂

Interruptible queuing system for closures

on cue - a signal for action

Description 🏷

A way to run tasks one after the other. (with support for canceling tasks)

Problem 🤯

Hard to queue up tasks that needs to be preformed one after the other
Hard to unit-test network code
Async network code all over the place is hard to reason about and hard to make bug free
Features such as timeout and retry are hard to build into DispatchWorkItem or NSOperationQueue

Solution: 💊

Ability to add and remove items to the queue
The Queue should be able to be run from start to finish
Has tasks that can .start() and .stop() and has .onComplete() callback
Tasks should have the ability to support timeout and retry
The Queue should be able to paused/stopped, resumed/started, reset/canceled (⚠️️ resume is not supported, only cancel ⚠️️)
Queues should be able to be nested? Queues within queues? (maybe) (reach-goal, ⚠️️ not currently supported ⚠️️) 🤔

Example:

let networkTasks: [NetworkTask] = (0..<5).map { _ in // Create 5 network tasks
   .init { (_ value: Any?) in
      guard let strValue: String = (value as? Data)?.stringUTF8 else { XCTFail(); return }
      Swift.print("strValue:  \(strValue) ✨")
   }
} // For loop network task
let queue: Queue = .init()
queue.onComplete = {
   Swift.print("queue test completed ✅")
   expectation.fulfill() // If this line is called, then test passed
}
queue.enqueue(networkTasks) // Add tasks and begin executing

Todo: 📝

Look at pagination service project for mock-api inspo ✅
Take a look at TestRunner (it has FIFO style architecture) ✅
Add timeout callback? ✅ (would need to separate network and db transaction in one task, in order to cancel transaction if network task is not complete etc) (can use Dispatchueue with timeout ?)
Do research on other cancelable closures in swift. ✅ There should be another one in your dispatch research etc (DispatchWorkItem)
Do tests with timers and background calls etc ✅
Test with run, add and cancel buttons 👈
Explain some of the use cases
Maybe subclass NSOperation (investigation needed) see issues ✨
Add support for result type? instead of just Any?
Add hasNext() like TestRunner? 🚫

cuekit's People

Contributors

Stargazers

cuekit's Issues

Queues should be able to continue when new tasks are added

And added while it runs

Add this to readme

Make Queue generic

See https://github.com/eonist/Iterator project

Support nested queues

requires isSuspended
requires dealing with tasks that are in progress etc

For now use one queue for all tasks. (simpler to reason about, and simpler code)

Add ability to resume queues after app quits

Would need support for queues to resume
Also for tasks and their content to be Codable and storable in plist or json etc

(Maybe not needed, might be too complex and unececary for the intent of this framework)

Consider making CueKitPlus which is based on NSOperation and supports timeout and retry

With intimate knowledge of building CueKit v1

Consider using Apples new Dequeue

https://swift.org/blog/swift-collections/

Add support for Result in callbacks?

see title

Make persistent queue system ala getLotus

from getlotus:

Under the hood
Lotus needs to be in sync with GitHub to ensure the state of notifications stays the same between the two. To do that, Lotus sends API requests to GitHub to mark notifications as read or unread.

Previously, I triggered those API requests immediately after you clicked a "mark as read" button (for example). However, requests can fail, take longer than expected or be triggered in parallel with other conflicting requests (e.g. mark as unread). Also, all in-flight requests can be canceled and lost if user quits the app.

To solve that, I implemented a persistent queue in Lotus. As soon as you mark notification as read, a new job is added to a queue. Then queue executes pending jobs one by one. While that is happening, queue's state is updated in the database to make sure no jobs are lost. If queue is currently processing a job and user quits the app, that same job will be restarted after app is launched again.

Here are the modules I've used to build it:

yocto-queue - Queue data structure.
p-timeout - Handles job timeouts.
p-retry - Retries failed jobs.
This feature was a much needed improvement and now I can sleep well at night, knowing that notifications are safely synced between Lotus and GitHub.

https://github.com/sindresorhus/yocto-queue

https://github.com/sindresorhus/p-timeout

https://github.com/sindresorhus/p-retry