Imagine it’s 3 a.m. and your pager goes off. A downstream service is failing, and after an hour of debugging you trace the issue to a tiny, undocumented schema change made by an upstream team. The fix is simple, but it comes with a high cost in lost sleep and operational downtime.

This is the nature of many modern data pipelines. We’ve mastered the art of building distributed systems, but we’ve neglected a critical part of the system: the agreement on the data itself. This is where data contracts come in, and how they fail without the right tools to enforce them.

The importance of data contracts

Data pipelines are a popular tool for sharing data from different producers (databases, applications, logs, microservices, etc.) to consumers to drive event-driven applications or enable further processing and analytics. These pipelines have often been developed in an ad hoc manner, without a formal specification for the data being produced and without direct input from the consumer on what data they expect. As a result, it’s not uncommon for upstream producers to introduce ad hoc changes consumers don’t expect and can’t process. The result? Operational downtime and expensive, time-consuming debugging to find the root cause.

Data contracts were developed to prevent this.

Data contract design requires data producers and consumers to collaborate early in the software design life cycle to define and refine requirements. Explicitly defining and documenting requirements early on simplifies pipeline design and reduces or removes errors in consumers caused by data changes not defined in the contract.

Data contracts are an agreement between data producers and consumers that define schemas, data types, and data quality constraints for data shared between them. Data pipelines leverage distributed software to map the flow of data and its transformation from producers to consumers. Data contracts are foundational to properly designed and well behaved data pipelines.

Why we need data contracts

Why should data contracts matter to developers and the business? First, data contracts reduce operational costs by eliminating unexpected upstream data changes that cause operational downtime.

Second, they reduce developer time spent on debugging and break-fixing errors. These errors are caused downstream from changes the developer introduced without understanding their effects on consumers. Data contracts provide this understanding.

Third, formal data contracts aid the development of well-defined, reusable data products that multiple consumers can leverage for analytics and applications.

The consumer and producer can leverage the data contract to define schema and other changes before the producer implements them. The data contract should specify a cutover process, so consumers can migrate to the new schema and its associated contract without disruption.

Three important data contract requirements

Data contracts have garnered much interest recently, as enterprises realize the benefits of shifting their focus upstream to where data is produced when building operational products that are data-driven. This process is often called “shift left.”

In a shift-left data pipeline design, downstream consumers can share their data product requirements with upstream data producers. These requirements can then be distilled and codified into the data contract.

Data contract adoption requires three key capabilities:

• Specification — define the data contract
• Implementation — implement the data contract in the data pipeline
• Enforcement — enforce the data contract in real-time

There are a variety of technologies that can support these capabilities. However, Apache Kafka and Apache Flink are among the best technologies for this purpose.

Apache Kafka and Apache Flink for data contracts

Apache Kafka and Apache Flink are popular technologies for building data pipelines and data contracts due to their scalability, wide availability, and low latency. They provide shared storage infrastructure between producers and consumers. In addition, Kafka allows producers to communicate the schemas, data types, and (implicitly) the serialization format to consumers. This shared information also allows Flink to transform data as it travels between the producer and consumer.

Apache Kafka is a distributed event streaming platform that provides high-throughput, fault-tolerance, and scalability for shared data pipelines. It functions as a distributed log enabling producers to publish data to topics that consumers can asynchronously subscribe to. In Kafka, topics have schemas, defined data types, and data quality rules. Kafka can store and process streams of records (events) in a reliable and distributed manner. Kafka is widely used for building data pipelines, streaming analytics, and event-driven architectures.

Apache Flink is a distributed stream processing framework designed for high-performance, scalable, and fault-tolerant processing of real-time and batch data. Flink excels at handling large-scale data streams with low latency and high throughput, making it a popular choice for real-time analytics, event-driven applications, and data processing pipelines.

Flink often integrates with Kafka, using Kafka as a source or sink for streaming data. Kafka handles the ingestion and storage of event streams, while Flink processes those streams for analytics or transformations. For example, a Flink job might read events from a Kafka topic, perform aggregations, and write results back to another Kafka topic or a database.

Kafka supports schema versioning and can support multiple different versions of the same data contract as it evolves over time. Kafka can keep the old version running with the new version, so new clients can leverage the new schema while existing clients are using the old schema. Mechanisms like Flink’s support for materialized views help accomplish this.

How Kafka and Flink help implement data contracts

Kafka and Flink are a great way to build data contracts that meet the three requirements outlined earlier—specification, implementation, and enforcement. As open-source technologies, they play well with other data pipeline components that are often built using open source software or standards. This creates a common language and infrastructure around which data contracts can be specified, implemented, and enforced.

Flink can help enforce data contracts and evolve them as needed by producers and consumers, in some cases without modifying producer code. Kafka provides a common, ubiquitous language that supports specification while making implementation practical.

Kafka and Flink encourage reuse of the carefully crafted data products specified by data contracts. Kafka is a data storage and sharing technology that makes it easy to enable additional consumers and their pipelines to use the same data product. This is a powerful form of software reuse. Kafka and Flink can transform and shape data from one contract into a form that meets the requirements of another contract, all within the same shared infrastructure.

You can deploy and manage Kafka yourself, or leverage a Kafka cloud service and let others manage it for you. Any data producer or consumer can be supported by Kafka, unlike strictly commercial products that have limits on the supported producers and consumers.

You could get enforcement via a single database if all the data managed by your contracts sits in that database. But applications today are often built using data from many sources. For example, data streaming applications often have multiple data producers streaming data to multiple consumers. Data contracts must be enforced across these different databases, APIs, and applications.

You can specify a data contract at the producer end, collaborating with the producer to get the data in the form you need. But enforcement at the producer end is intrusive and complex. Each data producer has its own authentication and security mechanisms. The data contract architecture would need to be adapted to each producer. Every new producer added to the architecture would have to be accommodated. In addition, small changes to schema, metadata, and security happen continuously. With Kafka, these changes can be managed in one place.

Kafka sits between producers and consumers. With Kafka Schema Registry, producers and consumers have a way of communicating what is expected by their data contract. Because topics are re-usable, the data contract may be re-usable directly or it could be incrementally modified and then re-used.

Kafka also provides shared, standardized security and data infrastructure for all data producers. Schemas can be designed, managed, and enforced at Kafka’s edge, in cooperation with the data producer. Disruptive changes to the data contract can be detected and enforced there.

Data contract implementation needs to be simple and built into existing tools, including continuous integration and continuous delivery (CI/CD). Kafka’s ubiquity, open source nature, scalability, and data re-usability make it the de facto standard for providing re-usable data products with data contracts.

Best practices for developers building data contracts

As a data engineer or developer, data contracts can help you deliver better software and user experiences at a lower cost. Here are a few guidelines for best practices as you start leveraging data contracts for your pipelines and data products.

1. Standardize schema formats: Use Avro or Protobuf for Kafka due to their strong typing and compatibility features. JSON Schema is a suitable alternative but less efficient.
2. Automate validation: Use CI/CD pipelines to validate schema changes against compatibility rules before deployment. Make sure your code for configuring, initializing, and changing Kafka topic schemas is part of your CI/CD workflows and check-ins.
3. Version incrementally: Use semantic versioning (e.g., v1.0.0, v1.1.0) for schemas and document changes. This should be part of your CI/CD workflows and run-time checks for compatibility.
4. Monitor and alert: Set up alerts for schema and type violations or data quality issues in Kafka topics or Flink jobs.
5. Collaborate across teams: Ensure producers and consumers (e.g., different teams’ Flink jobs) agree on the contract up front to avoid mismatches. Leverage collaboration tools (preferably graphical) that allow developers, business analysts, and data engineers to jointly define, refine, and evolve the contract specifications.
6. Test schema evolution: Simulate schema changes in a staging environment to verify compatibility with Kafka topics and Flink jobs.

You can find out more on how to develop data contracts with Kafka here.

Key capabilities for data contracts

Kafka and Flink provide a common language to define schemas, data types, and data quality rules. This common language is shared and understood by developers. It can be independent of the particular data producer or consumer.

Kafka and Flink have critical capabilities to make data contracts practical and widespread in your organization:

• Broad support for potential data producers and consumers
• Widespread adoption, usage, and understanding, partly due to their open source origins
• Many implementations available, including on-prem, cloud-native, and BYOC (Bring Your Own Cloud)
• The ability to operate at both small and large scales
• Mechanisms to modify data contracts and their schemas as they evolve
• Sophisticated mechanisms for evolving schemas and reusing data contracts when joining multiple streams, each with its own data contract.

Data contracts require a new culture and mindset that encourage data producers to collaborate with data consumers. Consumers need to design and describe their schema and other data pipeline requirements in collaboration with producers, and guided by developers and data architects.

Kafka and Flink make it much easier to specify, implement, and enforce the data contracts your collaborative producers and consumers develop. Use them to get your data pipelines up and running faster, operating more efficiently, without downtime, while delivering more value to the business.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

A coordinated token farming campaign continues to flood the open source npm registry, with tens of thousands of infected packages created almost daily to steal tokens from unsuspecting developers using the Tea Protocol to reward coding work.

On Thursday, researchers at Amazon said there were over 150,000 packages in the campaign. But in an interview on Friday, an executive at software supply chain management provider Sonatype, which wrote about the campaign in April 2024, told CSO that number has now grown to 153,000.

And while this payload merely steals tokens, other threat actors are paying attention, said Sonatype CTO Brian Fox.

When Sonatype wrote about the campaign just over a year ago, it found a mere 15,000 packages that appeared to come from a single person.

With the swollen numbers reported this week, Amazon researchers wrote that it’s “one of the largest package flooding incidents in open source registry history, and represents a defining moment in supply chain security.”

This campaign is just the latest way threat actors are taking advantage of security holes in a number of open source repositories, which runs the risk of damaging the reputation of sites like npm, PyPI and others.

Related content: Supply chain attacks and their consequences

“The malware infestation in open-source repositories is a full-blown crisis, out of control and dangerously eroding trust in the open-source upstream supply chain,” said Dmitry Raidman, CTO of Cybeats, which makes a software bill of materials solution.

As evidence, he pointed to the Shai‑Hulud worm’s rapid exploitation of the npm ecosystem, which shows how quickly attackers can hijack developer tokens, corrupt packages, and propagate laterally across the entire dependency ecosystem. “What began as a single compromise explodes in a few hours, leaving the whole ecosystem and every downstream project in the industry at risk in a matter of days, regardless of whether it is open source or commercial.”

This past September, Raidman wrote about the compromise of the Nx build system after threat actors pushed malicious versions of the package into npm. Within hours, he wrote, developers around the world were unknowingly pulling in code that stole SSH keys, authentication tokens, and cryptocurrency wallets.

These and more recent large scale uploads of malicious packages into open source repositories are “just the beginning,” he warned, unless developers and repository maintainers improve security.

The Amazon and Sonatype reports aren’t the first to detect this campaign. Australian researcher Paul McCarty of SourceCodeRed confirmed to us this is the spam he dubbed ‘IndonesianFoods’ in a blog this week.

The Tea Protocol

The Tea Protocol is a blockchain-based platform that gives open-source developers and package maintainers tokens called Tea as rewards for their software work. These tokens are also supposed to help secure the software supply chain and enable decentralized governance across the network, say its creators on their website.

Developers put Tea code that links to the blockchain in their apps; the more an app is downloaded, the more Tea tokens they get, which can then be cashed in through a fund. The spam scheme is an attempt to make the blockchain think apps created by the threat actors are highly popular and therefore earn a lot of tokens.

At the moment, the tokens have no value. But it is suspected that the threat actors are positioning themselves to receive real cryptocurrency tokens when the Tea Protocol launches its Mainnet, where Tea tokens will have actual monetary value and can be traded.

For now, says Sonatype’s Fox, the scheme wastes the time of npm administrators, who are trying to expel over 100,000 packages. But Fox and Amazon point out the scheme could inspire others to take advantage of other reward-based systems for financial gain, or to deliver malware.

What IT leaders and developers should do

To lower the odds of abuse, open source repositories should tighten their access control, limiting the number of users who can upload code, said Raidman of Cybeats. That includes the use of multi-factor authentication in case login credentials of developers are stolen, he said, and adding digital signing capabilities to uploaded code to authenticate the author.

IT leaders should insist all code their firm uses has a software bill of materials (SBOM), so security teams can see the components. They also need to insist developers know the versions of the open source code they include in their apps, and confirm only approved and safe versions are being used and not automatically changed just because a new version is downloaded from a repository.

Sonatype’s Fox said IT leaders need to buy tools that can intercept and block malicious downloads from repositories. Antivirus software is useless here, he said, because malicious code uploaded to repositories won’t contain the signatures that AV tools are supposed to detect.

In response to emailed questions, the authors of the Amazon blog, researchers Chi Tran and Charlie Bacon, said open source repositories need to deploy advanced detection systems to identify suspicious patterns like malicious configuration files, minimal or cloned code, predictable code naming schemes and circular dependency chains.

“Equally important,” they add, “is monitoring package publishing velocity, since automated tools create at speeds no human developer could match. In addition, enhanced author validation and accountability measures are crucial for prevention. This includes implementing stronger identity verification for new accounts, monitoring for coordinated publishing activity across multiple developer accounts, as seen in this campaign, and applying ‘guilt by association’ principles where packages from accounts linked to malicious activity receive heightened scrutiny. Repositories should also track behavioral patterns like rapid account creation followed by mass package publishing, which are hallmarks of automated abuse.”

CISOs discovering these packages in their environments “face an uncomfortable reality,” the Amazon authors add: “Their current security controls had failed to detect a coordinated supply chain attack.”

SourceCodeRed’s McCarty said IT leaders need to protect developers’ laptops, as well as their automated continuous integration and delivery pipelines (CI/CD). Traditional security tools like EDR and SCA don’t scan for malware, he warned. “The number of people that buy Snyk thinking it does this is huge,” he said. 

McCarty has created two open source malware scanning tools. One, opensourcemalware.com, is an open database of malicious content like npm packages. It can be checked to see if a package being used is malicious. The second is the automated open-source MALOSS tool, which is effectively a scanner that checks opensourcemalware.com and other sources automatically. MALOSS can be used in a CI/CD pipeline or on a local workstation.

He also recommends the use of a commercial or open source package firewall, which effectively allows a developer to only install approved packages. 

“The enterprise has more options than I think they realize,” he told CSO. “They just often don’t realize that there are tools and solutions to address this risk.  Maturity is really low in this space.”

Google has released version 2 of its Python client library to query the Data Commons platform, which organizes the world’s publicly available statistical data. The library supports custom instances, among other capabilities.

Announced June 26, the Data Commons Python library can be used to explore the Data Common knowledge graph and retrieve statistical data from more than 200 datasets. Available domains include demographics, economy, education, environment, energy, health, and housing. Developers can use the library’s custom instances to programmatically query any public or private instance, whether hosted locally or on the Google Cloud Platform. Developers can use custom instances to seamlessly integrate proprietary datasets with the Data Commons knowledge graph, according to Google.

Based on the V2 REST API, the Data Commons Python library in version 2 supports Pandas dataframe APIs as an integral module, with a single installation package allowing seamless use with other API endpoints in the same client, Google says. API key management and other stateful operations are built into the client class. Integration with Pydantic libraries improves type safety, serialization, and validation. Additionally, multiple response formats are supported, including JSON and Python dictionaries. With the library, developers can map entities from other datasets to entities in Data Commons. The Data Commons Python API client library is hosted on GitHub and available on pypi.org.

Microsoft has launched the fifth preview of its planned .NET 10 open source developer platform. The preview release fits C# 14 with user-defined compound assignment operators and enhances the .NET runtime with escape analysis, among other updates.

Announced June 10, .NET 10 Preview 5 can be downloaded from dotnet.microsoft.com. It includes enhancements to features ranging from the runtime and C# 14 to F# 10, NET MAUI, ASP.NET Core, and Blazor.

C# 14 type authors can now implement compound assignment operators in a user-defined manner that modifies the target in place rather than creating copies. Pre-existing code is unchanged and works the same as before. Meanwhile, in the .NET runtime, the JIT compiler’s escape analysis implementation has been extended to model delegate invokes. When compiling source code to IL (intermediate language), each delegate is transformed into a closure class with a method corresponding to the delegate’s definition and fields matching any captured variables. At runtime, a closure object is created to instantiate the captured variables along with a Func object to invoke the delegate. This runtime preview also enhances the JIT’s inlining policy to take better advantage of profile data. Additionally, F# 10 introduces scoped warning controls with a new #warnon directive supporting fine-grained control over compiler diagnostics.

A production release of .NET 10 is expected this November. .NET 10 Preview 5 follows Preview 4, announced May 13. The first preview was unveiled February 25, followed by a second preview on March 18, and the third preview, announced April 10. Other improvements featured in Preview 5 include:

• For ASP.NET Core, developers now can specify a custom security descriptor for HTTP.sys request queues using a new RequestQueueSecurityDescriptor property on HttpSysOptions. This enables more granular control over access rights for the request queue, allowing developers to tailor security to an application’s needs.
• The OpenAPI.NET library used in ASP.NET Core OpenAPI document generation has been upgraded to v2.0.0-preview18.
• Blazor now provides an improved way to display a “not Found” page when navigating to a non-existent page. Developers can specify a page to render when NavigationManager.NotFound() is called by passing a page type to the Router component using the NotFoundPage parameter.
• For .NET MAUI, projects now can combine XML namespaces into a new global namespace, xmlns="http://schemas.microsoft.com/dotnet/maui/global", and use these without prefixes.
• For Windows Presentation Foundation, the release introduces a shorthand syntax for defining Grid.RowDefinitions and Grid.ColumnDefinitions in XAML, with support for XAML Hot Reload. Performance and code quality are also improved.

Developers using Microsoft’s Visual Studio Code (VSCode) editor are being warned to delete, or at least stay away from, 10 newly published extensions which will trigger the installation of a cryptominer.

 The warning comes from researchers at Extension Total, who said possibly as many as 1 million of these malicious extensions, which pretend to be popular development tools, may have been installed since April 4, when they were published on Microsoft’s Visual Studio Code Marketplace. However, the researchers also suspect the threat actors may have inflated the download numbers.

Continue reading on CSO.

Microsoft’s recent launch of a standalone version of the MongoDB compatibility layer for its global-scale Azure Cosmos DB brought back an old name. Back in 2018, when the company unveiled a public version of the Project Florence database engine that powers much of Azure, they called it DocumentDB. That original name worked well for some of the database’s personalities, but its support for much more than JSON documents soon led to a new, now more familiar name. Cosmos DB has continued to evolve, with its document database capabilities offering a familiar set of MongoDB-compatible APIs.

A recent set of updates introduced the vCore variant of Azure Cosmos DB, which moves from the multi-tenant, cross-region, transparently scalable resource unit-based Cosmos DB to an alternative architecture that behaves more like traditional Azure services, with defined host virtual machines and a more predictable pricing model. The vCore-based MongoDB APIs are the same as those used with the cloud-scale resource unit version, but the underlying technologies are quite different, and moving from one version to the other requires a complete migration of your data.

Last week Microsoft revealed the differences in the two implementations when it unveiled an open-source release of the vCore Cosmos DB engine. Built on the familiar PostgreSQL platform, the new public project adds NoSQL features with the MongoDB APIs. As it focuses purely on storing JSON content, Microsoft decided to bring back the original DocumentDB name.

The new DocumentDB comes with a permissive MIT license and is intended to provide a standard NoSQL environment for your data to reduce the complexity associated with migrating from one platform to another. Choosing to work with PostgreSQL is part of that, as it has long been a popular platform for developers, one that’s had something of a recent renaissance.

A modern NoSQL database with PostgreSQL roots

By open sourcing a tool that’s already widely used in Azure, Microsoft is giving developers the ability to run something that’s already proven to work well. Most of the features we expect to find in a modern NoSQL store are already there, from basic CRUD (create, read, update, delete) operations to more complex vector search tools and the indexes needed to support them. This ensures you will be able to build on and extend a database that can support most scenarios.

DocumentDB sits on top of the existing PostgreSQL platform, which manages storage, indexing, and other key low-level operations. The result is that DocumentDB is implemented using two components: one to add support for BSON (Binary JavaScript Object Notation) data types and one to support the DocumentDB APIs, adding CRUD operations, queries, and index management.

BSON is the fundamental data type used in MongoDB but with implementations in most common languages. If you’re going to build a common NoSQL store based on MongoDB APIs, then BSON will be the way you represent your standard NoSQL data structures, such as key-value pairs and arrays. It’s easy to build JSON documents, but using BSON allows you to store and search content more effectively.

You can think of DocumentDB as a stack. At the bottom is PostgreSQL itself, then the DocumentDB extension that gives the database the ability to work with BSON data. Once installed it lets you parse BSON data and then use the PostgreSQL engine to build indexes, not only using the database engine’s standard tools but also other extensions. The result is the ability to deliver complex indexes that support all kinds of queries.

One useful feature is the ability to use PostgreSQL’s vector index capabilities to build your BSON data into a retrieval-augmented generation (RAG) application or use nearest-neighbor searches to build recommendation engines or identify fraud patterns. There’s a lot of utility in a NoSQL database with many different indexing options; it gives you the necessary foundations for many different application types—all working on the same data set.

Getting started with DocumentDB

This first public release of DocumentDB inherits code already running in Azure, so it’s ready to build and use, hosted on GitHub. The instructions in the project wiki are focused on using VS Code and Docker to build on top of WSL 2.0, though you can use any Linux via VS Code’s remote engine. You build the container, then make, install, and launch the binaries. The DocumentDB container already holds PostgreSQL, so once setup is complete, you can connect to its shell and start experimenting with BSON support.

From the shell, you can embed API calls in select statements. This allows you to experiment with operations before adding them to calls from your code. The shell lets you build collections, add items, and experiment with CRUD operations. Other operations apply filters and support queries, as well as building indexes across one or more fields in a collection. You can find a lengthy list of documented API functions in the project wiki, grouped into common sets of operations.

For now, the GitHub wiki is the main source of documentation for DocumentDB. It’s a little on the thin side and could do with more examples. However, DocumentDB is currently intended for developers who want an alternative to MongoDB, one that’s available with an open source license rather than a source-available license. For now, as there’s no SDK, you’ll need to build your own calls to the API. These are based on MongoDB, so porting applications shouldn’t be too complex.

Why this? Why now?

The reasoning behind the DocumentDB project seems to be the big ambition to deliver a standard NoSQL API and engine, much like that developed for SQL. Microsoft has a lot of experience working in standards bodies, especially building and delivering the essential tests needed to make sure that any implementation of the resulting standard meets the necessary requirements.

We’ve seen Microsoft deliver extensive test suites for protocols and languages, and we can expect this level of tooling to be a key component of any future NoSQL standard. We need common APIs and engine features to help with application and data portability. A common standard will allow NoSQL stores to compete on performance and other business-essential features such as scalability and resilience.

DocumentDB’s layered approach to delivering basic functionality is perhaps the most important part of what Microsoft is doing here. The blog post announcing DocumentDB talks about “a protocol translation layer” on top of the BSON extension, bridging APIs to the document store in a way that makes it possible to have a single store that looks like MongoDB to one set of clients, Aerospike to another, or CouchDB, Couchbase, and more.

A reference for a NoSQL standard

For DocumentDB to be the foundation of a NoSQL standard, it has to be vendor-neutral. By allowing you to switch protocols on top of the same underlying store, you can use the APIs you’re familiar with, no matter their source. Query engine designers can focus on their area of expertise, while the PostgreSQL team can continue to deliver the resilient, high-performance database necessary for modern applications.

One example of this is the latest release of the open source FerretDB NoSQL database. The latest release, FerretDB 2.0, is built using DocumentDB and is getting a considerable performance increase. The FerretDB team can continue to work on its own features, taking advantage of the open source DocumentDB to provide the core BSON support necessary for a MongoDB-compatible NoSQL database. The FerretDB team claims up to 20x better performance. It will continue to use its own Apache 2.0 license in parallel with Microsoft’s MIT license.

Another interesting point shows how much Microsoft has changed in the past decade or so: The first product shipping on the standalone DocumentDB is coming from Ferret, an open source company that’s not Microsoft.

DocumentDB is a project to keep an eye on, especially when Microsoft starts the process of using it as a reference implementation for a new NoSQL standard. With community support, hopefully we’ll then see a rapid rollout of the MongoDB API features that are currently missing—adding them into both the middleware layer to map them to PostgreSQL operations and the API implementation.

Vue 3.5, an update to the popular “progressive” JavaScript framework, emphasizes improvements to the platform’s reactivity system, for better performance and improved memory usage.

Vue 3.5, described as a minor release with no breaking changes, was announced September 1. However, the release includes a major refactor of the reactivity system that boosts performance and significantly improves memory usage (-56%) with no behavior changes, Vue creator Evan You wrote in a blog post.

The Vue 3.5 release also resolves stale computed values and hanging memory issues caused by hanging computes during SSR (server-side rendering). Additionally, reactivity tracking has been optimized for large, deeply reactive arrays, making these operations as much as 10x faster in some cases. Reactive props destructure, meanwhile, has been stabilized and now is enabled by default. Variables destructured from a defineProps call in now are reactive. This simplifies declaring props with default values, You said.

For SSR in Vue 3.5, async components now can control when they should be hydrated, by specifying a strategy through the hydrate option of the defineAsyncComponent() API. Vue 3.5 also fixes longstanding issues pertaining to the defineCustomElement() API, adding new capabilities for authoring custom elements.

Other features in Vue 3.5 include a new way of obtaining Template Refs via the useTemplateRef() API  and the introduction of a defer prop for , which mounts it after the current render cycle. And Vue 3.5 introduces a globally imported API, onWatcherCleanup(), to register cleanup callbacks in watchers.

Vue 3.5 has been followed up this week with versions 3.5.1, with bug fixes, and 3.5.2, with a compiler-core feature to parse modifiers as an expression to provide location data.