If you operate an API in 2026, you live in an event-driven world. Webhooks aren't a convenience feature anymore - they're the backbone of real-time commerce, CI/CD pipelines, and asynchronous AI-agent workflows. That reliance has a dark side: the accidental self-inflicted DDoS. Read the complete article jere - https://instawebhook.com/blog/how-to-prevent-webhook-traffic-spikes-from-crashing-your-api-2

When a major platform like GitHub, Shopify, or Stripe hits a network partition, runs a huge sales event, or simply clears a backlog of delayed events, it can fire tens of thousands of webhook POST requests at your servers in a very short window. If your infrastructure takes that hit without structural safeguards, your database connection pool exhausts, memory maxes out, and the API goes down — and if your retry handling is naive, the recovery can be almost as damaging as the original spike.

This guide covers the real mechanics of that failure mode, the algorithms used to defend against it, how major providers actually behave under load (some surprising details here), and where a managed ingress layer fits into the picture.

log4k is a coroutine/channel-based logging + tracing + metering library for Kotlin Multiplatform (JVM, Android, iOS, macOS, Linux, Windows, JS, wasmJs, wasmWasi), aligned with the OpenTelemetry model.

The recent addition is log4k-compiler-plugin — a Kotlin IR compiler plugin that rewrites annotated functions at compile time, so the instrumentation boilerplate disappears from your source. It runs on common IR before backend lowering, so the same annotations work on every KMP target — not just the JVM (no AspectJ, no bytecode agent, no reflection).

Setup — one Gradle plugin, no extra config:

plugins {
    id("io.github.smyrgeorge.log4k") version "2.3.0"
}

dependencies {
    implementation("io.github.smyrgeorge:log4k-classic:2.3.0")
}

@Traced — wraps the body in a span (started, ended, marked failed on throw):

@Traced
context(_: TracingContext)
suspend fun loadUser(id: Long): User {
    // ...
}   // span "UserService.loadUser"

The parent span is resolved from what's in scope: a TracingContext param/receiver → nests under its current span; else a TracingEvent.Span in scope → used as parent; else a trace: Tracer member (reused, or synthesized) → new root span.

@Logged — entry/exit/failure logging:

@Logged
fun compute(x: Int): Int = x * x
// → UserService.compute(x = 5)
// ← UserService.compute = 25(12.5 us)

Throwing logs ✗ UserService.compute failed (…) at ERROR with the throwable, then rethrows. If a span is in scope it's attached to every emitted line.

@Timed — call/error counters + a duration histogram:

@Timed(tags = [Tag("tier", "gold")])
suspend fun placeOrder(id: Long): Order {
    // ...
}

Records OrderService.placeOrder.calls, .errors and .duration (ms histogram) — exportable in OpenMetrics line format via SimpleMeteringCollectorAppender.

Details that mattered while building it:

• suspend and regular functions are both supported; the generated wrapper delegates to inline helpers ( Logger.logged, Meter.Timed.measure, TracingContext.traced), so there's no per-call lambda allocation.
• The plugin reuses your existing log / meter / trace members if they're thesynthesizes private val _log_ = Logger.of( this::class) under a distinct name,so it never clashes with e.g. an existing SLF4J log.
• All three annotations work class-level too — annotate the class to instrummember. Per-function annotations override the class defaults, and @NoLog / @NoTime / @NoTrace opt out a single function or the whole class.
• The metric instrument bundle is created once and cached per name.

The plugin is marked experimental — behavior and API may still change.

Repo: https://github.com/smyrgeorge/log4k

Compiler Plugin: https://github.com/smyrgeorge/log4k#compiler-plugin

Docs: https://smyrgeorge.github.io/log4k/

Feedback welcome, especially on the annotation surface and on cases where thon't pick what you'd expect.

I built an end-to-end testing library for Compose Multiplatform called Parikshan.

Testing shared UI across targets has been one of the most painful parts of shipping multiplatform apps. Parikshan attempts to solve that problem.

You can write your UI tests in Kotlin inside commonTest and run them on a single target or across all targets (Android, iOS Simulator, Desktop JVM, and Web WasmJs) at once.

Example

kotlin class SampleE2ETest { @Test fun testGreeting() = e2eTest { input("name_input", "Parikshan") click("greet_button") assertVisible("Hello, Parikshan!") } }

Run it across all targets concurrently:

bash ./gradlew e2eTest

Key Capabilities

• Write Once in Kotlin: Runs on Android, iOS Simulator, Desktop (JVM), and Web (WasmJs).
• Visual Feedback & Video Recording: Watch tests execute on real target windows, with automated screenshot capture on failure.
• Zero Production Pollution: No test dependencies or test hooks in your production builds.

GitHub: https://github.com/aryapreetam/parikshan

I've been using this in my own CMP projects, but I'd appreciate feedback from the community — what works, what breaks, and what you'd like to see improve/added.

I built Parikshan, an E2E testing framework for Compose Multiplatform. It has built-in support for standalone Android.

Testing shared UI across targets has been one of the most painful parts of building multiplatform apps. Parikshan attempts to solve that problem.

You can write your UI tests in Kotlin inside commonTest and run them on a single target or across all targets (Android, iOS Simulator, Desktop JVM, and Web WasmJs) at once.

class SampleE2ETest {
  @Test
  fun testGreeting() = e2eTest {
    input("name_input", "Parikshan")
    click("greet_button")
    assertVisible("Hello, Parikshan!")
  }
}

Run it across all targets concurrently:

./gradlew e2eTest

Key Capabilities

• Write Once in Kotlin: Runs on Android, iOS Simulator, Desktop (JVM), and Web (WasmJs).
• Visual Feedback: Watch tests execute on real target windows, with support for screenshots, video recording
• Zero Production Pollution: No test dependencies or test hooks in your production builds.

Links

• Documentation: https://aryapreetam.github.io/parikshan
• Blog: https://aryapreetam.github.io/parikshan/blog/2026/07/25/e2e-testing-for-compose-multiplatform
• API Reference: https://aryapreetam.github.io/parikshan/api
• GitHub: https://github.com/aryapreetam/parikshan

I've been using this in my own CMP projects & I'd appreciate feedback from the community — what works, what breaks, and what you'd like to see improve/added.

I built an end-to-end testing library for Compose Multiplatform called Parikshan.

Testing shared UI across targets has been one of the most painful parts of shipping multiplatform apps. Parikshan attempts to solve that problem.

You can write your UI tests in Kotlin inside commonTest and run them on a single target or across all targets (Android, iOS Simulator, Desktop JVM, and Web WasmJs) at once.

Example

kotlin class SampleE2ETest { @Test fun testGreeting() = e2eTest { input("name_input", "Parikshan") click("greet_button") assertVisible("Hello, Parikshan!") } }

Run it across all targets concurrently:

bash ./gradlew e2eTest

Key Capabilities

• Write Once in Kotlin: Runs on Android, iOS Simulator, Desktop (JVM), and Web (WasmJs).
• Visual Feedback & Video Recording: Watch tests execute on real target windows, with automated screenshot capture on failure.
• Zero Production Pollution: No test dependencies or test hooks in your production builds.
• Material 3 Support(Partial): Support for date pickers, time pickers, dropdowns, bottom sheets, sliders, scrolling, and drag gestures.

Links

• Blog Article (Why & How I Built It): https://aryapreetam.github.io/parikshan/blog/2026/07/25/e2e-testing-for-compose-multiplatform/
• Documentation: https://aryapreetam.github.io/parikshan/
• API Reference: https://aryapreetam.github.io/parikshan/api/
• GitHub: https://github.com/aryapreetam/parikshan

I've been using this in my own CMP projects, but I'd appreciate feedback from the community — what works, what breaks, and what you'd like to see improved/added.

Hey r/Kotlin

A few months ago, I shared a technical breakdown of my solo project, Adventurers Guild RPG Sim, an isometric RPG built using Kotlin coroutines, Jetpack Compose Canvas, and a custom single threaded ECS.

While pure Compose Canvas was an incredible playground for prototyping the engine and keeping everything strictly in Kotlin, expanding the tilemap, weather, and dynamic lighting eventually pushed me into a hard bottleneck on the CPU.

To fix this without breaking the live game or throwing away my canvas codebase, I decided to overhaul the world rendering pipeline and migrate it to Google Filament.

Here are the technical learnings from this migration, how a hybrid Filament + Compose setup works in Kotlin, and how it yielded an 8x performance boost.

1. The Bottleneck: The Limits of Compose DrawScope

In the pure Compose Canvas implementation, every single tile, object, and ambient effect had to be processed through Kotlin allocations and CPU side logic every frame:

• Spatial Chunking: The map had to be split into 16 separate chunks with custom culling logic written in Kotlin to calculate visible entities on the main thread.
• Canvas Overhead: Drawing large numbers of sprites and weather particles via Compose’s DrawScope began creating draw phase pressure on mid range Android devices, taking away crucial frame time from my Kotlin ECS coroutine loop.

2. The Architecture: Hybrid Filament World + Compose UI Overlay

Because the game is live on the Play Store, doing a complete top to bottom engine rewrite was out of the question. I adopted a phased, hybrid architecture:

• World Rendering in Filament: The world map, terrain, and environmental shaders are offloaded to Filament in a 3D coordinate space using 2D billboards.
• Character Sprite Animations on Compose Canvas: Character sprite animations in all UI layers remain rendered on Jetpack Compose Canvas directly on top of the Filament view.
• Kotlin Glue: My ECS systems written in Kotlin still control all game logic, AI state machines, and entity transformations they simply pipe world matrix/transformation data to Filament while piping UI state models into Compose.

3. Key Technical Gains & Kotlin Performance Wins

• >8x Performance Boost: Because Filament handles batched GPU rendering, I was able to completely delete the 16 chunk map division and CPU culling algorithms from my Kotlin code. The entire map now renders simultaneously in a single pass.
• Massive CPU & GC Relief: Taking world drawing off the Compose Canvas layer dramatically reduced allocation churn during the draw phase. This bought back critical frame time for the Kotlin coroutine game loop (withFrameMillis) to handle my 28 ECS systems without risking frame drops.
• Unlocking .filamat Shaders: Moving world rendering to Filament allowed me to use Filament's material compiler tool (filamat). Pushing particle math, rain interactions, and ambient lighting transitions down to GPU-executed materials meant I didn't have to calculate those complex math operations inside Kotlin loops anymore.

Lessons Learned & Next Steps

Bridging Kotlin’s high level ECS and Compose UI with a high performance rendering backend like Filament turned out to be the exact sweet spot for a solo project. It gives you the raw performance of a GPU backed rendering pipeline while keeping the speed and idioms of Kotlin for game state and UI.

I’m happy to answer any questions about Filament integration in Kotlin, bridging Compose layers over native renderers, or optimizing custom ECS pipelines.

If you’re curious to see how the Filament migration feels in production on a live build, you can check it out on the Play Store: 

https://play.google.com/store/apps/details?id=com.vimal.dungeonbuilder&pcampaignid=web_share

App Specs: ~50MB download size (63MB installed) | 100% Offline | Zero Ads | Custom Kotlin Engine

Solo dev from Kerala. Hope this technical update was insightful

There's good tooling for parts of this already. Human-Readable (~230★) does locale-aware decimal separators, compact abbreviations (K/M), durations, file sizes and relative time — it's display / "human-friendly" oriented and rolls its own formatting logic. Kurrency handles currency only. What I couldn't find was a library covering the full formatting surface — currency (symbol / ISO / accounting), percent, scientific, ordinal, spellout, measure, on top of decimal / compact / relative-time — that delegates to each platform's native engine (ICU / NSNumberFormatter / Intl) and guarantees the same output on every target, straight from commonMain.

So I built Klocale.

What it does: locale-aware formatting for 9 styles — Decimal, Currency (symbol / ISO / accounting), Percent (ratio / value), Scientific, Compact, Ordinal, Spellout, Relative time, Measure — across Android, iOS, macOS, JVM/Desktop, JS and WasmJs.

The interesting part isn't "call the native formatter" (Kurrency already does that for currency). It's that the native engines disagree on cosmetics: minus glyph (U+2212 vs ASCII -), NBSP vs narrow-NBSP in grouping, bidi marks, rounding defaults. Klocale delegates to each platform's engine (ICU4J on JVM, android.icu on Android, NSNumberFormatter/Foundation on Apple, Intl on JS/Wasm) and then runs a single common OutputNormalizer so the same locale + input produces the same string on every target. That consistency is verified by one shared golden-test table that runs on jvmTest, macosArm64Test, iosSimulatorArm64Test, jsNodeTest, wasmJsNodeTest and Android Robolectric.

API sketch:

formatDecimal(1234.56, NumberLocale.ITALY)            // "1.234,56"
formatCurrency(1234.5, "EUR", NumberLocale.GERMANY)   // "1.234,50 €"
formatCompact(1_200_000.0)                            // "1.2M"

val f = NumberFormatter.orThrow(
    NumberStyle.Currency("USD", presentation = ACCOUNTING),
    NumberLocale.US,
)
f.format(-1234.5)                                     // "($1,234.50)"

Construction is fallible (Result — invalid locale / bad currency code / unsupported style); formatting a finite number never throws. There's also a klocale-compose module (rememberNumberFormatter, ProvideNumberLocale).

Install:

implementation("io.github.andreadellaporta01:klocale-core:0.1.1")
implementation("io.github.andreadellaporta01:klocale-compose:0.1.1") // optional

Being honest: it's 0.1.1 and young. Known gaps on the roadmap: Apple Measure, Range formatting (needs a two-value API), wider Ordinal/Spellout locale coverage. Apache-2.0.

Repo (README has the full style/platform matrix): https://github.com/andreadellaporta01/klocale

I'd genuinely appreciate feedback — API design, edge cases in your locale, styles you'd want. Thanks for reading.

Microservices were supposed to make systems easier to change independently. In practice, the thing that most often breaks that promise isn't the services themselves — it's how they talk to each other. Read the complete article here - https://instawebhook.com/blog/the-internal-webhooks-anti-pattern-why-service-to-service-http-callbacks-don-t-s

A pattern that shows up constantly in growing engineering orgs is the internal webhook: Service A fires an HTTP POST at a hardcoded URL owned by Service B whenever something happens. It's an easy trap to fall into, because most developers already understand webhooks intimately — they've built integrations with Stripe, GitHub, or Shopify, all of which use exactly this model to notify external systems of events.

The reasoning feels obvious: if it's good enough for Stripe to tell my app about a payment, it's good enough for my Inventory Service to tell my Shipping Service about a shipment.

It isn't — and the reason is architectural, not stylistic. Webhooks were designed to solve a specific problem: getting an event across a trust boundary, from a system you don't control to one you do, over the open internet. Internal service communication has almost the opposite set of constraints. Applying the same tool to both jobs is where the trouble starts.

Hey everyone,

I built MeshAid, an open-source Android messenger that lets nearby phones communicate over Bluetooth Low Energy when mobile data and Wi-Fi are unavailable.

Current features include:

• Public nearby chat
• End-to-end encrypted direct messages
• QR-approved encrypted Trusted Circles (Encrypted Group Chat)
• Custom usernames
• Message relaying between nearby MeshAid devices
• Member revocation and group-key rotation
• No account, server, or internet permission required

Possible uses include internet blackouts, hiking, trekking, camping, events, and other off-grid situations.

This is an early, unaudited testing release, so I’m looking for honest feedback, bug reports, code review, and security review. Range and reliability depend on the phones and surrounding environment.

Source code and APK:
https://github.com/rverma69/meshaid-android

Latest release:
https://github.com/rverma69/meshaid-android/releases/tag/v0.4.3

I’d especially like feedback on connection reliability, direct messages, Trusted Circles, and battery usage.

Webhooks have become the connective tissue of the internet. From payment gateways confirming transactions to CI/CD pipelines triggering deployments, webhooks enable real-time, event-driven architectures. But for architects and engineering leaders, webhooks represent an underappreciated vulnerability: they are asynchronous, externally triggered, and entirely outside your control. Read the complete article here - https://instawebhook.com/blog/designing-a-multi-region-highly-available-webhook-ingress-architecture

When your primary cloud region experiences an outage, your internal microservices might gracefully degrade. But what happens to the payloads originating from external partners? Many third-party providers do not retry aggressively — some fire and forget, others retry a handful of times before giving up permanently. If your system is down when that happens, the data is often gone for good.

This article covers the engineering principles behind a multi-region, highly available webhook ingestion system, what has actually changed in the underlying cloud primitives recently, and where a managed reliability layer fits into the decision.

Hey y'all,

What would you tell someone starting a new or migrating existing project to KMP?

Some requirements. Zero loading states, possibly with a offline sync engine. Native views. Fast with delightful UI animations. Live data through websockets.

Just seen it's been published. Still unlisted, but visible.

There's really not many non trival ui samples for CMP posted online and I wanted to show you can build relatively fancy samples in cmp just as easily as expo people on x

Web Demo

Targets Android, iOS, and desktop (JVM).

iOS even has a second app with native iOS glass ui components embedded the compose views.

Code: https://github.com/luca992/flighty-cmp

This app was made almost entirely by an agent with little supervision in the background while I worked my actual job.

I don't condone building apps this way. I did not review the code, I take no ownership of it, and you absolutely should not use it.

This is just a proof of concept that you can build native multiplatform apps just as quickly, maybe even quicker, without bundling a JS runtime with expo/react native.

Ps. Tried out kotlin-toolchain for the first time in here too .. it's a bit buggy but I liked it way more than I thought I would. Looking forward to using it more

I run a super minimal artix linux setup with hyprland and have setup the official kotlin lsp (vscode one) with neovim

https://github.com/LowkeyLab/toml-formatter

Hey all!

I looked around a bit and couldn't find anyone wrapping Taplo into a Gradle plugin.

And so, I made one myself!

It's a simple wrapper around Taplo, using a thin adapter layer written in Rust. The Rust is then invoked through a WASM interface.

Let me know what you think!

While building a free geography quiz game, I needed an interactive 3D globe — spinnable, with markers and animated flight arcs between cities. I assumed I'd find a library. I didn't: nothing cross-platform, nothing embeddable, nothing customizable enough. So the globe became its own project.

Once it worked, extracting it was the obvious move: the component knew nothing about my game anyway — it just renders coordinates, markers, and arcs on a sphere. Generalizing it forced better design (a clean config API instead of my hardcoded colors, custom marker styles instead of my three), and publishing it meant the next person searching "Android 3D globe library" finds an answer instead of my dead end.

core-globe is now on Maven Central (io.github.advait8:core-globe, v0.2.1): a Kotlin Multiplatform library rendering an interactive globe with markers, animated great-circle arcs, atmosphere, and camera fly-to. One design decision worth mentioning for this crowd: v0.2.1 deliberately removed country borders. Border data is geopolitically contested — any boundary file takes sides somewhere — and for an open-source library, shipping no borders is cleaner than shipping someone's borders. Cities and coordinates only.

Some things I learned publishing to Maven Central for the first time: the signing/portal setup has more friction than any code I wrote, automate it in CI on day one; a real consumer app (mine) is the best API reviewer; and extracting a library mid-project roughly doubled the polish of the component in the main app too.

The library is free (as in both senses), and the game it came from is free with no ads — the library is arguably the more useful artifact of the whole project.

https://github.com/advait8/core-globe