Archive for the ‘en-US’ Category
[NodeCongress2021] Introduction to the AWS CDK: Infrastructure as Node – Colin Ihrig
In the evolving landscape of cloud computing, developers increasingly seek tools that bridge the gap between application logic and underlying infrastructure. Colin Ihrig’s exploration of the AWS Cloud Development Kit (CDK) offers a compelling entry point into this domain, emphasizing how Node.js enthusiasts can harness familiar programming paradigms to orchestrate cloud resources seamlessly. By transforming abstract infrastructure concepts into executable code, the CDK empowers teams to move beyond cumbersome templates, fostering agility in deployment pipelines.
The CDK stands out as an AWS-centric framework for infrastructure as code, akin to established solutions like Terraform but tailored for those versed in high-level languages. Supporting JavaScript, TypeScript, Python, Java, and C#, it abstracts the intricacies of CloudFormation—the AWS service for defining and provisioning resources via JSON or YAML—into intuitive, object-oriented constructs. This abstraction not only simplifies the creation of scalable stacks but also preserves CloudFormation’s core advantages, such as consistent deployments and drift detection, where configurations are automatically reconciled with actual states.
Streamlining Cloud Architecture with Node.js Constructs
At its core, the CDK operates through a hierarchy of reusable building blocks called constructs, which encapsulate AWS services like S3 buckets, Lambda functions, or EC2 instances. Colin illustrates this with a straightforward Node.js example: instantiating a basic S3 bucket involves minimal lines of code, contrasting sharply with the verbose CloudFormation equivalents that often span pages. This approach leverages Node.js’s event-driven nature, allowing developers to define dependencies declaratively while integrating seamlessly with existing application codebases.
One of the CDK’s strengths lies in its synthesis process, where high-level definitions compile into CloudFormation templates during the “synth” phase. This generated assembly includes not just templates but also ancillary artifacts, such as bundled Docker images for Lambda deployments. For Node.js practitioners, this means unit testing infrastructure alongside application logic—employing Jest for snapshot validation of synthesized outputs—without ever leaving the familiar ecosystem. Colin’s demonstration underscores how such integration reduces context-switching, enabling rapid iteration on cloud-native designs like serverless APIs or data pipelines.
Moreover, the CDK’s asset management handles local files and images destined for S3 or ECR, necessitating a one-time bootstrapping per environment. This setup deploys a dedicated toolkit stack, complete with storage buckets and IAM roles, ensuring secure asset uploads. While incurring nominal AWS charges, it streamlines workflows, as evidenced by Colin’s walkthrough of provisioning a static website: a few constructs deploy a public-read bucket, sync local assets, and expose the site via a custom domain—potentially augmented with Route 53 for DNS or CloudFront for edge caching.
Navigating Deployment Cycles and Best Practices
Deployment via the CDK CLI mirrors npm workflows, with commands like “cdk deploy” orchestrating updates intelligently, applying only deltas to minimize disruption. Colin highlights the CLI’s versatility—listing stacks with “cdk ls,” diffing changes via “cdk diff,” or injecting runtime context for dynamic configurations—positioning it as an extension of Node.js tooling. For cleanup, “cdk destroy” reverses provisions, though manual verification in the AWS console is advisable, given occasional bootstrap remnants.
Colin wraps by addressing adoption barriers, noting the CDK’s maturity since its 2019 general availability and its freedom from vendor lock-in—given AWS’s ubiquity among cloud-native developers. Drawing from a Cloud Native Computing Foundation survey, he points to JavaScript’s dominance in server-side environments and AWS’s 62% market share, arguing that the CDK aligns perfectly with Node.js’s ethos of unified tooling across frontend, backend, and operations.
Through these insights, Colin not only demystifies infrastructure provisioning but also inspires Node.js developers to embrace declarative coding for resilient, observable systems. Whether scaling monoliths to microservices or experimenting with ephemeral environments, the CDK emerges as a pivotal ally in modern cloud engineering.
Links:
[DevoxxPL2019] Enhancing Career Through Effective Communication: Strategies for Developers
Lecturer
Piotr Stawirej operates as a software engineer at Revolut, with a background from Politechnika Łódzka. As a clean code enthusiast and TDD/BDD advocate, he trains on architecture and people skills, drawing from 12+ years in development.
Abstract
This inquiry addresses communication’s pivotal role in developers’ success, beyond technical prowess. It identifies common pitfalls like poor first impressions or ineffective feedback, proposing techniques from Dale Carnegie for building rapport, influencing ideas, and handling conflicts. Through personal anecdotes, it analyzes emotional intelligence’s impact on career progression, team dynamics, and personal growth, while advocating experimentation for practical mastery.
Communication Barriers: Common Developer Pitfalls
Developers often prioritize code over interpersonal skills, leading to frustrations in idea adoption or managerial interactions. Piotr shares experiences: aggressive presentations alienate audiences, underscoring preparation’s importance.
Context: in tech, 85% success ties to emotions; unchecked behaviors block advancements. Analytically, this manifests in overlooked suggestions or code review disputes.
Implications: fosters awareness, encouraging shifts from confrontation to collaboration.
Building Rapport: Techniques for Likability
Carnegie’s principles guide: smile genuinely, remember names, listen actively. Piotr exemplifies: using names personalizes, active listening validates.
Methodologically, avoid arguments—seek common ground. Analytically, this defuses tensions, promoting constructive dialogues.
Implications: strengthens relationships, easing idea acceptance.
Influencing Positively: Winning Without Conflict
Praise publicly, criticize privately; address faults indirectly. Piotr recounts: framing suggestions as questions empowers recipients.
Analytically, this leverages psychology for motivation. Implications: accelerates career by aligning teams.
Changing Behaviors: Gentle Approaches
Admit faults first, use questions over commands. Piotr’s story: self-deprecation eases corrections.
Analytically, reduces defensiveness. Implications: cultivates growth mindsets.
Practical Experimentation: Applying Skills Daily
Start small: experiment with techniques, observe outcomes. Piotr urges: internalize through practice.
Implications: transforms workplaces, enhancing satisfaction.
Links:
[DevoxxPL2019] User Login
Successful Login
- Navigate to login page
- Enter username “user” and password “pass”
- Verify dashboard visible
Steps code in Java:
@Step(“Navigate to login page”)
public void navigate() {
// code
}
Analytically, markdown's familiarity lowers barriers. Implications: accelerates onboarding, but lacks Gherkin's structure for some.
## Taiko Integration: Scriptless Web Automation
Taiko, a Chrome DevTools wrapper, enables intuitive interactions sans selectors. Dmitry demos on TodoMVC: open URLs, write inputs, click elements.
Code:
const { openBrowser, goto, write, click } = require(‘taiko’);
await openBrowser();
await goto(“todomvc.com”);
await write(“Buy milk”);
await click(“Add”);
“`
Analytically, natural APIs reduce fragility from UI changes. Implications: speeds test creation, though Chrome exclusivity limits cross-browser testing.
Practical Application: End-to-End Testing Flows
Combining Gauge specs with Taiko steps, Dmitry automates todo flows: create, complete, filter.
Specs drive discussions; Taiko handles executions reliably.
Analytically, this revives BDD by minimizing overheads. Implications: boosts test reliability, encouraging widespread use.
Organizational Adoption: Challenges and Strategies
Despite simplicity, resistance persists from legacy habits. Dmitry advises gradual introductions, emphasizing communication benefits.
Implications: transforms testing from chore to collaborative asset, enhancing product quality.
Links:
[KotlinConf2019] Exploring the Power of Kotlin/JS
Sebastian Aigner, a developer advocate at JetBrains, captivated KotlinConf2019 with his deep dive into Kotlin/JS, the JavaScript target for Kotlin. With a passion for web development, Sebastian showcased how recent advancements make Kotlin/JS a compelling choice for building web applications. From streamlined tooling to seamless JavaScript interoperability, he outlined the current state and future potential of Kotlin/JS, inspiring both newcomers and seasoned developers to leverage Kotlin’s paradigms in the browser.
Simplifying Development with the New Gradle Plugin
Kotlin/JS has evolved significantly, with the new Kotlin/JS Gradle plugin emerging as the cornerstone for browser and Node.js development. Sebastian explained that this plugin unifies previously fragmented approaches, replacing deprecated plugins like kotlin2js and kotlin-frontend. Its uniform Gradle DSL simplifies project setup, offering sensible defaults for Webpack bundling without requiring extensive configuration. For developers transitioning to multi-platform projects, the plugin’s compatibility with the Kotlin multi-platform DSL minimizes changes, enabling seamless integration of additional targets. By automating JavaScript environment setup, including yarn and package.json, the plugin empowers Kotlin developers to focus on coding rather than managing complex JavaScript tooling.
Mastering Dependency Management with npm
The JavaScript ecosystem, with over a million npm packages, offers unparalleled flexibility, and Kotlin/JS integrates effortlessly with this vast library. Sebastian highlighted how the Gradle plugin manages npm dependencies directly, automatically updating package.json when dependencies like React or styled-components are added. This eliminates the need for separate JavaScript environment setup, saving time, especially on non-standard platforms like Windows. Developers can import Kotlin libraries (e.g., coroutines, serialization) alongside JavaScript packages, with Gradle handling the JavaScript-specific versions. This unified approach bridges the gap between Kotlin’s structured ecosystem and JavaScript’s dynamic world, making dependency management intuitive even for those new to JavaScript.
Bridging Kotlin and TypeScript with Dukat
Interoperating with JavaScript’s dynamic typing can be challenging, but Sebastian introduced Dukat, an experimental tool that converts TypeScript declaration files into Kotlin external declarations. By leveraging TypeScript’s de facto standard for type definitions, Dukat enables type-safe access to npm packages, such as left-pad or react-minimal-pie-chart. While manual external declarations require tedious annotation, Dukat automates this process, generating headers for packages with TypeScript support or community-contributed definitions. Sebastian encouraged early adoption to provide feedback, noting that Dukat already powers browser and Node.js API wrappers. This tool promises to simplify integration with JavaScript libraries, reducing the friction of crossing the static-dynamic typing divide.
Enhancing Testing and Debugging with Source Maps
Testing and debugging are critical for robust applications, and Kotlin/JS delivers with integrated tools. Sebastian demonstrated how the Gradle plugin supports platform-specific test runners like Karma, allowing tests to run across browsers (e.g., Firefox, headless Chrome). Source maps, automatically generated since Kotlin 1.3.60, provide detailed stack traces for Node.js and interactive debugging in browser DevTools. Developers can set breakpoints in Kotlin code, inspect variables, and trace errors directly in Chrome’s console, as shown in Sebastian’s pong game demo. Gradle test reports further enhance diagnostics, offering HTML-based insights into test failures, making Kotlin/JS development as robust as its JVM counterpart.
Optimizing with the IR Backend
The upcoming Intermediate Representation (IR) backend marks a significant leap for Kotlin/JS. Sebastian outlined its benefits, including aggressive code size optimizations through dead code elimination. Unlike the current backend, which may ship the entire standard library, the IR backend, combined with Google Closure Compiler, reduces zipped file sizes dramatically—down to 30 KB from 3.9 MB in some cases. Faster compilation speeds, especially for incremental builds, enhance developer productivity, particularly in continuous build scenarios with Webpack’s dev server. The IR backend also supports platform-agnostic compiler plugins, simplifying multi-platform development. Sebastian noted that pre-alpha IR support in Kotlin 1.3.70 requires manual exports due to its closed-world assumption, urging developers to explore early releases.
Looking Ahead: WebAssembly and Framework Support
Sebastian concluded with a glimpse into Kotlin/JS’s future, highlighting potential support for ECMAScript 6 modules and frameworks like Angular and Vue.js. While JetBrains provides React wrappers, extending first-class support to other frameworks requires addressing their unique tooling and compilers. The IR backend also opens doors to WebAssembly, enabling Kotlin to target browsers more efficiently. Though no timelines were promised, these explorations reflect JetBrains’ commitment to aligning Kotlin/JS with modern web trends. Sebastian’s call to action—trying the Code Quiz app at the Kotlin booth and contributing to Dukat—emphasized community involvement in shaping Kotlin/JS’s evolution.
Links:
[DevoxxPL2019] Revitalizing Behavior-Driven Development for Web Testing with Gauge and Taiko
Lecturer
Dmitry Vinnik functions as an Engineering Manager at Meta, specializing in AI/ML, where he leads teams on cutting-edge solutions. As a Lead Developer Advocate for Open Source and Business Messaging, he promotes tools enhancing productivity, with a passion for software quality and international speaking engagements.
Abstract
This review revitalizes Behavior-Driven Development for web testing, contrasting traditional frameworks with Gauge and Taiko. It explores BDD principles, Gauge’s markdown-based specifications versus Cucumber’s Gherkin, and Taiko’s scriptless automation. Through demonstrations on a todo app, it assesses methodologies for cross-team communication, test maintenance, and browser interactions, while contemplating impacts on adoption and organizational dynamics.
BDD Fundamentals: Communication Over Automation
Behavior-Driven Development bridges stakeholders by expressing behaviors in natural language, yet adoption falters from tool complexities. Dmitry contextualizes this: BDD aims for shared understanding, but frameworks like Cucumber introduce regex-heavy steps, alienating non-technical participants.
Gauge counters with markdown specs, free from rigid syntax, allowing plain English descriptions. Steps implement in languages like Java or JavaScript, fostering flexibility.
Analytically, this decouples narratives from executions, easing maintenance. Implications: enhances collaboration, though requires discipline to avoid verbosity.
Gauge Versus Cucumber: Simplifying Specifications
Cucumber’s Gherkin mandates “Given-When-Then,” parsed via regex, complicating updates. Gauge uses markdown, supporting tables and parameters natively.
For a login scenario:
“`
[DevoxxPL2019] Mastering Kubernetes Development Within IntelliJ: Seamless Integration and Debugging
Lecturer
Ivan Portyankin works as a software engineer at Google, contributing to Google Cloud Platform and Cloud Code for IntelliJ. Based in New York City, he focuses on tools that simplify cloud-native development, with a background in enhancing developer productivity through IDE integrations.
Abstract
This discussion examines the capabilities of Google Cloud Tools for IntelliJ in streamlining Kubernetes development workflows. It covers motivations for IDE-centric approaches, conversions from plain Java apps to containerized deployments, and features like live debugging and continuous updates. Through demonstrations, it analyzes methodologies for YAML minimization, cluster interactions, and hot-swapping, while reflecting on implications for developer efficiency and Kubernetes adoption barriers.
Motivational Landscape: Bridging Code and Cluster Management
Kubernetes’ complexity often deters developers, as traditional workflows involve extensive CLI commands and YAML configurations, diverting focus from core coding. Ivan addresses this by showcasing tools that embed orchestration directly into IDEs like IntelliJ, allowing seamless transitions from local development to production deployments.
Contextually, this aligns with the rise of cloud-native paradigms, where teams seek to abstract infrastructure. Google’s Cloud Code plugin exemplifies this, supporting Java, Kotlin, Go, and other languages across JetBrains IDEs and VS Code.
Analytically, the approach reduces cognitive load: developers remain in familiar environments, avoiding context switches. Implications: accelerates iterations, lowers entry barriers for Kubernetes newcomers, fostering broader adoption in enterprises.
Application Conversion: From Monolith to Microservices
Starting with a plain Java app, Ivan demonstrates scaffolding Kubernetes manifests via Cloud Code. For a voting service, the plugin generates deployments, services, and ingresses, minimizing manual YAML edits.
Methodologically, select templates for languages like Java/Spring Boot, auto-populating fields. Deploy to clusters like GKE or Minikube directly from IDE run configurations.
For multi-language setups—Java, Kotlin/Go—the tool handles diverse runtimes, ensuring consistent deployments.
Analytically, this decouples app logic from ops, but requires accurate kubeconfig setups. Implications: enables polyglot teams, though debugging multi-pod interactions demands careful logging.
Live Debugging and Continuous Deployment: Enhancing Iteration
Cloud Code enables remote debugging on Kubernetes pods without config changes. Ivan attaches debuggers to running containers, setting breakpoints in code.
For updates, continuous mode rebuilds and redeploys on saves, hot-swapping classes where possible.
Methodologically, use Skaffold under the hood for builds; configure via skaffold.yaml for custom pipelines.
Analytically, this mirrors local debugging, bridging dev-prod gaps. Implications: shortens feedback loops, boosting productivity, though network latency can affect remote sessions.
Ecosystem Extensions and Future Directions: Beyond Basics
The plugin supports Helm for complex apps, though basic; future enhancements target better template editing.
Analytically, open-source nature invites contributions, accelerating features like multi-cluster management. Implications: democratizes Kubernetes, but skill gaps in underlying tools persist.
In essence, IDE integrations transform Kubernetes from ops burden to developer enabler.
Links:
[KotlinConf2019] Simplifying Async APIs with Kotlin Coroutines
Tom Hanley, a senior software engineer at Toast, enthralled KotlinConf2019 with a case study on using Kotlin coroutines to tame a complex asynchronous API for an Android card reader. Drawing from his work integrating a third-party USB-connected card reader, Tom shared how coroutines transformed callback-heavy code into clean, sequential logic. His practical insights on error handling, debugging, and testing offered a roadmap for developers grappling with legacy async APIs.
Escaping Callback Hell
Asynchronous APIs often lead to callback hell, where nested callbacks make code unreadable and error-prone. Tom described the challenge of working with a third-party Android SDK for a card reader, which relied on void methods and listener interfaces for data retrieval. A naive implementation to fetch device info involved mutable variables and blocking loops, risking infinite loops and thread-safety issues. Such approaches, common with legacy APIs, complicate maintenance and scalability. Tom emphasized that coroutines offer a lifeline, allowing developers to wrap messy APIs in a clean, non-blocking interface that reads like sequential code, preserving the benefits of asynchrony.
Wrapping the Card Reader API with Coroutines
To streamline the card reader API, Tom developed a Kotlin extension that replaced callback-based interactions with suspend functions. The original API required a controller to send commands and a listener to receive asynchronous responses, such as device info or errors. By introducing a suspend getDeviceInfo function, Tom enabled callers to await results directly. This extension ensured referential transparency, where functions clearly return their results, and allowed callers to control asynchrony—waiting for completion or running tasks concurrently. The approach also enforced sequential execution for dependent operations, critical for the card reader’s connection and transaction workflows.
Communicating with Channels
Effective inter-thread communication was key to the extension’s success. Rather than relying on shared mutable variables, Tom used Kotlin channels to pass events and errors between coroutines. When the listener received device info, it sent the data to a public channel; errors were handled similarly. The controller extension used a select expression to await the first event from either the device info or error channel, throwing errors or returning results as needed. Channels, with their suspending send and receive operations, provided a thread-safe alternative to blocking queues. Despite their experimental status in Kotlin 1.3, Tom found them production-ready, supported by smooth IDE migration paths.
Mastering Exception Handling
Exception handling in coroutines requires careful design, as Tom learned through structured concurrency introduced in Kotlin 1.3. This feature enforces a parent-child relationship, where canceling a parent coroutine cancels its children. However, Tom discovered that a child’s failure propagates upward, potentially crashing the app in launch coroutines if uncaught. For async coroutines, exceptions are deferred until await is called, allowing try-catch blocks to handle them. To isolate failures, Tom used supervisorJob to prevent child cancellations from affecting siblings and coroutineScope blocks to group all-or-nothing operations, ensuring robust error recovery for the card reader’s unreliable USB connection.
Debugging and Testing Coroutines
Debugging coroutines posed initial challenges, but Tom leveraged powerful tools to simplify the process. Enabling debug mode via system properties assigns unique names to coroutines, appending them to thread names and enhancing stack traces with creation details. The debug agent, a JVM tool released post-project, tracks live coroutines and dumps their state, aiding deadlock diagnosis. For testing, Tom wrapped suspend functions in runBlocking blocks, enabling straightforward unit tests. He advised using launch and async only when concurrency is needed, marking functions as suspend to simplify testing by allowing callers to control execution context.
Moving Beyond Exceptions with Sealed Classes
Reflecting on exception handling’s complexity, Tom shifted to sealed classes for error handling. Initially, errors from the card reader were wrapped in exceptions, but frequent USB failures made catching them cumbersome. Exceptions also obscured control flow and hindered functional purity. Inspired by arguments likening exceptions to goto statements, Tom adopted domain-specific sealed classes (e.g., Success, Failure, Timeout) for each controller command’s result. This approach enforced explicit error handling via when statements, improved readability, and allowed result types to evolve independently, aligning with the card reader’s diverse error scenarios.
Links:
[DevoxxPL2019] Micronaut Versus Spring Boot: Assessing Framework Alternatives
Lecturer
Vladimir Dejanović occupies the role of senior director for B2C technology at PVH, managing tech for fashion labels including Tommy Hilfiger and Calvin Klein. Leading the Amsterdam Java User Group as founder, he holds JavaOne Rockstar and CodeOne Star status, often presenting on Java ecosystems and patterns.
Abstract
This evaluation pits Micronaut against Spring Boot, exploring their strengths in Java app construction. It details comparison drivers, a CRUD repository task, and metrics like launch speed, resource consumption, and native compilation. Via coding sessions, it gauges philosophies, efficiency, and feature sets, while contemplating appropriateness for fresh initiatives versus legacy code.
Driving the Comparison: Libraries Versus Integrated Solutions
Deciding between modular libraries and all-inclusive frameworks shapes Java projects. Vladimir delineates: libraries afford customization but integration labor, frameworks like Spring Boot deliver ready solutions potentially at efficiency expense.
Background: Spring’s prowess incurs reflection-based costs, evident in clouds. Micronaut vows comparable might minus drawbacks, using build-time computations.
Analytically, suits service-oriented architectures needing swift boots. Ramifications: frameworks hasten prototypes, but burdens affect expansion; Micronaut’s method may streamline allocations.
Task Design and Execution: CRUD in Repositories
For contrast, Vladimir crafts a person-rating CRUD: compute from age/name, persist. Spring Boot uses annotations for models/repositories, leveraging CrudRepository’s auto-implementations.
Snippet:
@Entity
public class Person {
@Id
@GeneratedValue
private Long id;
private String name;
private int age;
private int rating;
// accessors
}
@Repository
public interface PersonRepository extends CrudRepository<Person, Long> {}
Micronaut necessitates explicit codings, annotating @Repository, implementing interfaces manually.
Analytically, Spring’s brevity accelerates, Micronaut’s clarity aids comprehension. Ramifications: Spring for quick builds; Micronaut for tuned performances.
Efficiency Metrics: Boot Times, Usage, Native Builds
Boot: Micronaut quicker from compile injections, Spring slower via runtime scans. Usage: Micronaut lighter, sans proxies.
Native: Micronaut natively compatible; Spring lacks direct backing.
Analytically, advantages Micronaut in ephemeral or constrained contexts. Ramifications: lowered cloud expenses, rapid initiations improving experiences.
Feature Landscape and Guides: Production Viability
Micronaut expands swiftly, backing Kafka, GraphQL, gRPC, discoveries. Guides/tutorials excel.
Spring Boot’s ripeness provides extensive links, but heavier.
Analytically, both facilitate rapid resolutions, Micronaut’s freshness attracts innovators. Ramifications: Micronaut for pioneers; keep Spring for established bases.
Final Appraisals: Judicious Choices
Both shine in output, Spring slightly in ease, Micronaut in efficacy. Maintain Spring legacies; ponder Micronaut for novices.
Ramifications: context-driven selections balance rapidity and extensibility.
Links:
[DevoxxPL2019] Resilience Patterns in Microservices: Beyond Hystrix
Lecturer
Tomasz Skowroński contributes to resilience-focused libraries and speaks on fault tolerance in distributed systems.
Abstract
This overview introduces resilience patterns for microservices, transitioning from Hystrix to Resilience4j. It explains time limiters, rate limiters, bulkheads, retries, and circuit breakers, using analogies and code to demonstrate configurations and executions. It appraises integration with existing code, order of application, and higher-layer usages, while considering effects on system stability and developer explicitness.
Introducing Resilience: Patterns for Fault Tolerance
Resilience ensures responsiveness amid failures, vital in distributed setups. Tomasz analogizes to Dunkirk evacuation, where limited boats mirror API calls—use responsibly.
Hystrix, Netflix’s library, implemented circuit breakers but ceased development. Resilience4j succeeds, embracing Java 8+ functional styles sans annotations or AOP.
Analytically, this shift favors lightweight, composable resilience over monolithic commands. Implications: easier adoption in diverse stacks, reducing overhead.
Time and Rate Limiters: Controlling Execution Durations and Frequencies
Time limiters enforce timeouts on futures or suppliers, preventing indefinite waits. Configure via builders:
TimeLimiterConfig config = TimeLimiterConfig.custom()
.timeoutDuration(Duration.ofMillis(500))
.build();
TimeLimiter timeLimiter = TimeLimiter.of(config);
Callable<String> callable = TimeLimiter.decorateFutureSupplier(timeLimiter, () -> CompletableFuture.supplyAsync(this::slowMethod));
This decorates calls, throwing on timeouts.
Rate limiters restrict invocations per period, using permissions:
RateLimiterConfig config = RateLimiterConfig.custom()
.limitForPeriod(50)
.limitRefreshPeriod(Duration.ofMinutes(1))
.timeoutDuration(Duration.ofSeconds(3))
.build();
RateLimiter rateLimiter = RateLimiter.of("backend", config);
Runnable restrictedCall = RateLimiter.decorateRunnable(rateLimiter, this::backendMethod);
Analytically, parameters like refresh periods balance throughput and protection. Implications: prevents overloads, though misconfigurations cause premature failures.
Bulkheads and Retries: Isolating and Recovering from Failures
Bulkheads isolate via thread pools or semaphores, limiting concurrent calls:
BulkheadConfig config = BulkheadConfig.custom()
.maxConcurrentCalls(100)
.maxWaitDuration(Duration.ofMillis(10))
.build();
Bulkhead bulkhead = Bulkhead.of("backend", config);
Supplier<String> decorated = Bulkhead.decorateSupplier(bulkhead, this::backendMethod);
Retries attempt failed calls, configurable for attempts and waits.
Analytically, exponential backoffs mitigate thundering herds. Implications: boosts reliability, but excessive retries amplify loads.
Circuit Breakers: Caching Failures for Protection
Circuit breakers track successes/failures in buffers, opening on thresholds to block calls, periodically probing recovery.
Configurations define states: closed (allow), open (block), half-open (test).
Analytically, sliding windows maintain recent histories. Implications: shields backends during outages, explicit via decorators.
Strategic Application: Ordering, Layers, and Myths
Order matters: circuit breakers before retries avoid futile attempts. Apply at gateways or clouds for broader protection.
Myths: not all patterns always; failure-fast over safe sans explicit fallbacks.
Implications: explicitness via decorators clarifies intent, fostering robust designs.
Links:
[KotlinConf2019] Kotlin Coroutines: Mastering Cancellation and Exceptions with Florina Muntenescu & Manuel Vivo
Kotlin coroutines have revolutionized asynchronous programming on Android and other platforms, offering a way to write non-blocking code in a sequential style. However, as Florina Muntenescu and Manuel Vivo, both prominent Android Developer Experts then at Google, pointed out at KotlinConf 2019, the “happy path” is only part of the story. Their talk, “Coroutines! Gotta catch ’em all!” delved into the critical aspects of coroutine cancellation and exception handling, providing developers with the knowledge to build robust and resilient asynchronous applications.
Florina and Manuel highlighted a common scenario: coroutines work perfectly until an error occurs, a timeout is reached, or a coroutine needs to be cancelled. Understanding how to manage these situations—where to handle errors, how different scopes affect error propagation, and the impact of launch vs. async—is crucial for a good user experience and stable application behavior.
Structured Concurrency and Scope Management
A fundamental concept in Kotlin coroutines is structured concurrency, which ensures that coroutines operate within a defined scope, tying their lifecycle to that scope. Florina Muntenescu and Manuel Vivo emphasized the importance of choosing the right CoroutineScope for different situations. The scope dictates how coroutines are managed, particularly concerning cancellation and how exceptions are propagated.
They discussed:
* CoroutineScope: The basic building block for managing coroutines.
* Job and SupervisorJob: A Job in a coroutine’s context is responsible for its lifecycle. A key distinction is how they handle failures of child coroutines. A standard Job will cancel all its children and itself if one child fails. In contrast, a SupervisorJob allows a child coroutine to fail without cancelling its siblings or the supervisor job itself. This is critical for UI components or services where one failed task shouldn’t bring down unrelated operations. The advice often given is to use SupervisorJob when you want to isolate failures among children.
* Scope Hierarchy: How scopes can be nested and how cancellation or failure in one part of the hierarchy affects others. Understanding this is key to preventing unintended cancellations or unhandled exceptions.
Cancellation: Graceful Termination of Coroutines
Effective cancellation is vital for resource management and preventing memory leaks, especially in UI applications where operations might become irrelevant if the user navigates away. Florina and Manuel would have covered how coroutines support cooperative cancellation. This means that suspending functions in the kotlinx.coroutines library are generally cancellable; they check for cancellation requests and throw a CancellationException when one is detected.
Key points regarding cancellation included:
* Calling job.cancel() initiates the cancellation of a coroutine and its children.
* Coroutines must cooperate with cancellation by periodically checking isActive or using cancellable suspending functions. CPU-bound work in a loop that doesn’t check for cancellation might not stop as expected.
* CancellationException is considered a normal way for a coroutine to complete due to cancellation and is typically not logged as an unhandled error by default exception handlers.
Exception Handling: Catching Them All
Handling exceptions correctly in asynchronous code can be tricky. Florina and Manuel’s talk aimed to clarify how exceptions propagate in coroutines and how they can be caught.
They covered:
* launch vs. async:
* With launch, exceptions are treated like uncaught exceptions in a thread—they propagate up the job hierarchy. If not handled, they can crash the application (depending on the root scope’s context and CoroutineExceptionHandler).
* With async, exceptions are deferred. They are stored within the Deferred result and are only thrown when await() is called on that Deferred. This means if await() is never called, the exception might go unnoticed unless explicitly handled.
* CoroutineExceptionHandler: This context element can be installed in a CoroutineScope to act as a global handler for uncaught exceptions within coroutines started by launch in that scope. It allows for centralized error logging or recovery logic. They showed examples of how and where to install this handler effectively, for example, in the root coroutine or as a direct child of a SupervisorJob to catch exceptions from its children.
* try-catch blocks: Standard try-catch blocks can be used within a coroutine to handle exceptions locally, just like in synchronous code. This is often the preferred way to handle expected exceptions related to specific operations.
The speakers stressed that uncaught exceptions will always propagate, so it’s crucial to “catch ’em all” to avoid unexpected behavior or crashes. Their presentation aimed to provide clear patterns and best practices to ensure that developers could confidently manage both cancellation and exceptions, leading to more robust and user-friendly Kotlin applications.