The information in our interactive Radar is currently only available in English. To get information in your native language, please download the PDF here.



    • With the increased adoption of a microservices architecture, we're building more distributed applications than before. Although there are many benefits of a decoupled architecture, the complexity and the effort involved in proving the correctness of the overall system has dramatically increased. Jepsen provides much needed tooling to verify correctness in coordination of task schedulers, test eventual consistency, linearizability and serializability characteristics of distributed databases. We've used Jepsen in a few projects and we like the fact that we can test drive configurations, inject and correct faults, and verify the state of the system after recovery.

    • An open source framework developed by WeChat, MMKV provides fast key-value storage for mobile apps. It uses iOS memory-mapping features to avoid the need to explicitly save changes and is extremely fast and performant. In the event of an unexpected crash, MMKV allows the app to restore the data quickly.

    • MockK is a library for mocking written in Kotlin. Its main philosophy is to provide first-class support for Kotlin language features such as Coroutines or lambda blocks. As a native library, it helps our teams to write clean and concise code on testing Kotlin applications instead of using incommodious wrappers of Mockito or PowerMock.

    • TypeScript is a carefully considered language and its consistently improving tools and IDE support continues to impress us. With a good repository of TypeScript-type definitions, we benefit from all the rich JavaScript libraries while gaining type safety. This is particularly important as our browser-based code base continues to grow. The type safety in TypeScript lets you use IDEs and other tools to provide deeper context into your code and make changes and refactor code with safety. TypeScript, being a superset of JavaScript, and documentation and the community has helped ease the learning curve.


    • Apache Beam is an open source unified programming model for defining and executing both batch and streaming data-parallel processing pipelines. Beam provides a portable API layer for describing these pipelines independent of execution engines (or runners) such as Apache Spark, Apache Flink or Google Cloud Dataflow. Different runners have different capabilities and providing a portable API is a difficult task. Beam tries to strike a delicate balance by actively pulling innovations from these runners into the Beam model and also working with the community to influence the roadmap of these runners. Beam has a rich set of built-in I/O transformations that cover most of the data pipeline needs and it also provides a mechanism to implement custom transformations for specific use cases. The portable API and extensible IO transformations make a compelling case for assessing Apache Beam for data pipeline needs.

    • We tend to be quite skeptical of business process model and notation (BPMN) tools in general as they're often associated with low-code environments and their downsides. Although the OSS BPMN framework Camunda provides some of this whizziness, it also offers workflow and decision engines that can be directly integrated as a library in your Java code. This makes it easy to test, version and refactor workflows. Camunda also integrates with Spring and Spring Boot, among other frameworks, making it a solid choice.

    • Flutter is a cross-platform framework that enables you to write native mobile apps in Dart. It benefits from Dart and can be compiled into native code and communicates with the target platform without bridge and context switching—something that can cause performance bottlenecks in frameworks such as React Native or Weex. Flutter's hot-reload feature is impressive and provides superfast visual feedback when editing code. Currently, Flutter is still in beta, but we'll continue keeping an eye on it to see how its ecosystem matures.

    • Kotlin is no longer just a great fit for mobile app development. New tools and frameworks have emerged that demonstrate the value of the language for web application development as well. Ktor is one such framework. In contrast to other web frameworks that support Kotlin, Ktor is written in Kotlin, using language features such as coroutines which allows for an asynchronous non-blocking implementation. The flexibility to incorporate different tools for logging, DI or a templates engine—in addition to its lightweight architecture—makes Ktor an interesting option for our teams for creating RESTful services.

    • One insight we gained after talking with our teams is that Python is making a comeback across many technology domains. In fact, it's well on its way to become the most-used programming language. In part, this is driven by its adoption by data scientists and in machine learning, but we also see teams adopting it to build microservices. Nameko is a super-lightweight microservices framework and an alternative to Flask for writing services. Unlike Flask, Nameko only has a limited set of features that includes WebSocket, HTTP and AMQP support. We also like its focus on testability. If you don't need features such as templating that Flask provides, then Nameko is worth a look.

    • Polly.js is a simple tool that helps teams test JavaScript websites and applications. Our teams particularly like that it enables them to intercept and stub HTTP interactions which allows for easier and faster testing of JavaScript code without having to spin up dependent services or components.

    • PredictionIO is an open source machine-learning server. Developers and data scientists can use it to build intelligent applications for prediction. Like all intelligent applications, PredictionIO has three parts: data collection and storage, model training, and model deployment and expose service. Developers could focus on implementing data-processing logic, model algorithm and prediction logic based on the corresponding interfaces and liberate themselves from data storage and model training deployment. In our experience, PredictionIO can support both small and large volumes of data with low concurrency. We mostly use PredictionIO to build predictive services for small and medium-sized enterprises or as a proof of concept when building more complex, customized prediction engines.

    • In the previous Radar we mentioned Headless Chrome for front-end test. With the adoption of Chrome DevTools Protocol (CDP) by other browsers a new set of libraries is emerging for browser automation and testing. CDP allows for fine-grained control over the browser even in headless mode. New high-level libraries are being created using CDP for testing and automation. Puppeteer is one of these new libraries. It can drive headless Chrome through a single-page application, obtain time-trace for performance diagnostics and more. Our teams found it faster and also more flexible than alternatives based on WebDriver.

    • Quantum computing currently exists in a twilight zone of being available for testing without having arrived yet. While we're still waiting for the hardware to arrive, we can experiment with and learn from languages and simulators. Although IBM and others have been making good progress, we've paid particular attention to Microsoft's efforts based around the Q# language and its simulator (32 qubits locally and 40 on Azure). If you want to start wrapping your head around the potential future of programming, check out their set of samples on GitHub.

    • The SAFE stack—short for Suave, Azure, Fable, and Elmish—brings a number of technologies into a coherent stack for web development. It's built around the F# programming language, both on the server side and in the browser, and therefore has a focus on functional, type-safe programming with an asynchronous approach. It offers productivity features such as hot reloading and lets you substitute parts of the stack, for example, the server-side web framework or the cloud provider.

    • The adoption of a new language typically spawns the emergence of new tools that support mature engineering practices such as test automation. Kotlin is no exception. Spek is a testing framework—inspired by well-known tools such as Cucumber, RSpec and Jasmine—that writes tests in Gherkin and Specification, allowing teams to bring mature practices such as behaviour-driven development into the Kotlin space.

    • We're trying out troposphere as a way of defining the infrastructure as code on AWS for our projects that use AWS CloudFormation instead of Terraform. troposphere is a Python library that allows us to write Python code to generate CloudFormation JSON descriptions. What we like about troposphere is that it facilitates catching JSON errors early, applying type checking, and unit testing and DRY composition of AWS resources.

    • WebAssembly is a big step forward in the capabilities of the browser as a code execution environment. Supported by all major browsers and backward compatible, it's a binary compilation format designed to run in the browser at near native speeds. It opens up the range of languages you can use to write front-end functionality, with early focus on C, C++ and Rust, and it's also an LLVM compilation target. When run in the sandbox, it can interact with JavaScript and shares the same permissions and security model. When used with Firefox's new streaming compiler, it also results in faster page initialization. Although it's still early days, this W3C standard is definitely one to start exploring.

    • Spring Framework 5, released over a year ago, embraces reactive streams, a standard for asynchronous stream processing with non-blocking backpressure. The WebFlux module introduces a reactive alternative to the traditional Spring MVC module for writing web applications in the Spring ecosystem. After working with it on a number of applications, our teams have come away impressed and report that the reactive (functional) approach improves code readability and system throughput. They do note, though, that adopting WebFlux requires a significant shift in thinking and recommend to factor this into the decision to choose WebFlux over Spring MVC.


      Unable to find something you expected to see? Your item may have been on a previous radar

      New or moved,No change