When developing a new application it may not be clear if the complexity of asynchronous control flow is justified. Initially the scale may be relatively small, but over time the scale may grow. The scaling or response size characteristics may not be uniform for all APIs offered by the application (e.g. health check vs file serving). ServiceTalk is designed to evolve with your application so that you can get started quickly and avoid/defer the complexity of asynchronous control flow in these cases. This can dramatically lower the bar to entry for ServiceTalk compared with most non-blocking I/O frameworks and avoid "application re-write" if scaling/data size characteristics change over time.
ServiceTalk APIs may use the term "blocking" in areas where the APIs may be identified as "synchronous". "blocking" in this context is meant to declare that the API "may block" the calling thread. This is done because there is no general way to determine if a method will return synchronously or block the calling thread, and "blocking" is the least common denominator.
This API paradigm is similar to concepts from
java.io and generally blocks the calling thread until all I/O is
completed. The result is aggregated into a single object (e.g.
This API paradigm performs I/O asynchronously (e.g. the calling thread is not blocked) and the user is notified when all
the I/O is complete. ServiceTalk provides a ReactiveStreams compatible
Asynchronous primitives such as
Single API provides a
similar experience to the
Promise pattern such as