You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a part of our v6 release plans we will move to an async/await first approach. This will modernise the codebase, improve the consumer APIs and enable Swift error handling as a result.
This should also enable us to extend to the Linux platform.
The current approach (using Combine) is often difficult to maintain, has inherent issues regarding thread safety, cancellation, etc. All of which can be resolved, but the async/await equivalents are generally easier to achieve and maintain.
Async/await APIs also result in simpler APIs and more clarity at the call-site.
Its a large scale change that will require a large effort before we can provide a detailed design, let alone implementation.
This discussion is to provide insight into the roadmap and planned development for v6 concurrency.
Thread safety
In addition to async/await we will explore the use of actors and other concurrency features to bring thread safety to the library.
The current release has had several reports concerning thread safety but its current design makes this difficult to resolve.
Cancellation
Cancellation is equally solvable via combine, however again, the design as it stands is slightly more complex to resolve. Async/await APIs have a far simpler cancellation model that can be used (optionally) by the API consumer. Implementing cancellation across libraries is also simpler to model using modern concurrency.
Subscriptions
Since the release of Async stream APIs, its also now possible to implement subscriptions using a familiar Swift solution.
Additionally there may be other use-cases where multiple results are possible from an API. For example, there are situations where an existing Combine publisher returns 1 or 2 results and AsyncStream may serve as an appropriate solution for those situations.
Note: detailed design will be added here at a later date.
Backwards compatibility
While the goal is to shift away from Combine in the core libraries, we also recognise that existing users need an upgrade path. To better support those users, we plan on including a new package, which will include Combine publisher APIs that wrap the newer async/await APIs.
While these APIs may still require code updates to support other new features, this should at least ease migration, by not forcing those users to shift away from publisher paradigms present in their existing code.
Additionally this approach bring other concurrency features, like thread safety, to these users by default.
Summary
Concurrency in SwiftGraphQL is extremely important and we believe the way forward is an async/await first approach. Bringing with it Swift error handling support, cancellation and thread safety.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Platforms support
Overview
As a part of our v6 release plans we will move to an async/await first approach. This will modernise the codebase, improve the consumer APIs and enable Swift error handling as a result.
The current approach (using Combine) is often difficult to maintain, has inherent issues regarding thread safety, cancellation, etc. All of which can be resolved, but the async/await equivalents are generally easier to achieve and maintain.
Async/await APIs also result in simpler APIs and more clarity at the call-site.
Its a large scale change that will require a large effort before we can provide a detailed design, let alone implementation.
This discussion is to provide insight into the roadmap and planned development for v6 concurrency.
Thread safety
In addition to async/await we will explore the use of actors and other concurrency features to bring thread safety to the library.
The current release has had several reports concerning thread safety but its current design makes this difficult to resolve.
Cancellation
Cancellation is equally solvable via combine, however again, the design as it stands is slightly more complex to resolve. Async/await APIs have a far simpler cancellation model that can be used (optionally) by the API consumer. Implementing cancellation across libraries is also simpler to model using modern concurrency.
Subscriptions
Since the release of Async stream APIs, its also now possible to implement subscriptions using a familiar Swift solution.
Additionally there may be other use-cases where multiple results are possible from an API. For example, there are situations where an existing Combine publisher returns 1 or 2 results and
AsyncStream
may serve as an appropriate solution for those situations.Backwards compatibility
While the goal is to shift away from Combine in the core libraries, we also recognise that existing users need an upgrade path. To better support those users, we plan on including a new package, which will include Combine publisher APIs that wrap the newer async/await APIs.
While these APIs may still require code updates to support other new features, this should at least ease migration, by not forcing those users to shift away from publisher paradigms present in their existing code.
Additionally this approach bring other concurrency features, like thread safety, to these users by default.
Summary
Concurrency in SwiftGraphQL is extremely important and we believe the way forward is an async/await first approach. Bringing with it Swift error handling support, cancellation and thread safety.
Laying the groundwork for future releases.
Beta Was this translation helpful? Give feedback.
All reactions