Post News, a Twitter alternative that emerged in the wake of Elon Musk’s takeover, is shutting down. Noam Bardin, the platform’s founder and former CEO of Waze, writes that Post News “is not growing fast enough to become a real business or a significant platform.”

The Andreessen Horowitz-backed platform launched in a closed beta in November 2022, but now it’s set to shutter “within the next few weeks.” It serves as a social platform that also offers users ad-free access to paywalled content from publishers such as Fortune, Business Insider, Wired, The Boston Globe, and others. All users have to do is pay a “few cents” per article instead of signing up for a subscription to each publication.

Screenshot by Emma Roth / The...

Continue reading…

Linux creator Linus Torvalds sat down Wednesday for a “keynote interview” at the Linux Foundation‘s Open Source Summit North America in Seattle. Torvalds was interviewed by Dirk Hohndel, an early Linux contributor (and currently the head of Verizon’s Open Source program office) — in what was billed as a “fireside chat.”

But what came through clearly was Torvalds’ lifelong love of open source development — and how that’s been playing out in the real world filled with upstream security issues, overhyped AI, and other people’s hardware bugs.

Although their conversation started with a humorous exchange…

Hohndel: We all know kernel development does include a lot of drama and a lot of high-stakes discussions… For example, a really important topic that once again has reared its ugly head is tabs versus spaces.

Torvalds: Oh, Christ…

Problems Beyond Your Control

Hohndel said technology news sites covering Torvalds inserting tabs (to catch parsing tools that can’t properly convert them to whitespace) are a kind of triumph for the open source project — a “sign of the maturity and health of Linux, that a small comment could generate news articles.”

But then Hohndel segued to the topic of “problems that are outside of your control, that you end up dealing with anyway” — and specifically, “yet another round of hardware bugs.” Torvalds agreed things like the newly discovered Spectre v2 exploit were frustrating — but not for the obvious reason.

“I got into doing kernels because I’m interested in the hardware,” Torvalds pointed out. But he also loves Open Source development, and “The thing that is very, very frustrating is that you have these technically interesting problems, but then they are made to be a horrendous experience by all the secrecy…”

“My fear is that RISC-V will do all the same mistakes that everybody else did before them.” — Linus Torvalds

And Torvalds said it’s frustrating for fast-reacting software developers to then face the slower pace of hardware development. (“Oh, we have five generations of hardware that we can’t fix after the fact, and it will take another couple of years before the actual new hardware that can help you work around the problem comes out.”) “That ends up being very frustrating — with the whole added side of all the PR that goes along with any security issues.”

Hohndel asked if things would get better with Open Source hardware — especially after five years of RISC-V development. But Torvalds isn’t convinced. “My fear is that RISC-V will do all the same mistakes that everybody else did before them… When RISC-V becomes more of a big, widely-deployed platform, they’ll have all the same issues we had on the ARM side, and that x86 had before them. And it will take a few generations for them to say, ‘Oh, we didn’t think about that’ — because they have new people involved.”

But if hardware is developed out in the open, won’t that make it easier for software developers to warn them against repeating past mistakes?

“There’s a fairly big gulf between the Verilog [the standard hardware description language] and even the kernel,” Torvalds responded, “much less higher up the stack, where you’re working so far away from the hardware, that you really have no idea how the hardware works. So it’s really hard to work across this very wide gulf of things.”

Hohndel then made an interesting observation. Ten years ago it was hard even just to move from x86 to a new platform, but “Today most people don’t even know when they’re running on a [AWS] Graviton… or an AMD or an Intel chip. In the cloud, it all looks exactly the same, with the same software specs. Just the price point is different.”

And Torvalds says “That was one of the promises of open source. And people were saying that this was true 10 years ago.

“And it wasn’t true 10 years ago. But it’s certainly reaching that point now.”

Relying on Trust

But recently the open source community faced a stark reminder that security issues can come from the other direction too — from the community of maintainers. When asked about the recent xz Util exploit, Torvalds shared his own perspective — starting by emphasizing that even proprietary software has its own reliance on trust. “[Users] depend on the trust in the company. But also within the company you depend on trust — in your employees. And that trust can be violated.”

“And how to figure out when it’s being violated is an open problem.”

Torvalds spoke from decades of experience. Even a long-standing open source project like Linux has “seen this before,” Torvalds said, remembering a 2021 incident where University of Minnesota researchers tested how easy it would be to upstream bad kernel patches. (“That’s actually an interesting study. They just didn’t do it very well. They didn’t tell a third party about this, and they just sent us bad patches.”) But now the open source ecosystem has seen an actual malicious attempt to upstream bad code — and in a world where, as Torvalds puts it, “nobody really had any explicit gates in place to try to catch this.”

Yet Torvalds also sees a hopeful sign. Whether it’s xz or those bad patches that the students tried to upload for the kernel in 2021, “In both cases, they were actually really caught fairly quickly.” And that fact “does seem to imply a fairly strong amount of stability — and that these things do get caught.”

Even with that, Torvalds acknowledges that “Clearly it’s a wake-up call — there’s no question about that… I think we’re going to see a lot of work being put into some kind of trust model, where people see, ‘Oh, this is a new person’, or ‘This is a person that is acting differently from before.”

Hohndel pointed out that deep within the Linux developer community, signature requirements include a face-to-face meeting — and government-issued ID. And Torvalds agreed with Hohndel’s idea that the best defense is a healthy community.

Hohndel went on to note that “The Linux kernel has this incredibly big, but also incredibly deeply entwined and connected community, where there are multiyear, multidecade relationships at the core of all this.”

But this prompted a reminder from Torvalds — that Linux’s kernel is an atypical open source project. “A lot of open source projects, even very central ones, are basically run by one or two or three people… ”

AI for Open Source?

At one point, Hohndel introduced the topic of AI, noting dire predictions it will someday eliminate programmers, authors, movie creators, and jobs. “So you are going to be replaced by an AI model.”

“Finally!” Torvalds joked.

Responding more seriously, Torvalds added “No… I hate the hype… My personal opinion is, let’s wait 10 years and see where it actually goes before we make all these crazy announcements of ‘Your job will be gone in five years.”

But what about AI in coding tools? Torvalds admitted he was “optimistic” about AI, and “looking forward to the tools to actually find bugs.” With kernel developers (and other projects) already religiously using the tooling they have, “making the tools smarter is not a bad thing.”

He called smarter tools “just the next inevitable step… But I don’t think it’s necessarily the gloom and doom that some people say it is, and I definitely don’t think it’s the promised world that people who are having their hand out for cash say it is.”

There was a funny exchange when Torvalds warned his audience, “You need to be a bit cynical about this whole hype cycle in the tech industry… Before AI it was crypto, before crypto, it was whatever.”

“Cloud native,” suggested Hohndel. (Later adding that he’d heard “That’s not hype!” from a “loud voice in the front.”)

But Torvalds reiterated his call to judge the news carefully. “I mean, the hype? There’s always like a grain of reality behind it. But you need to be careful about all the BS around that grain.”

The Point of Open Source

Throughout the half-hour interview, there were glimpses of what motivates Torvalds personally, after more than 30 years of Linux kernel development. When Hohndel said Open Data was almost the more interesting question, Torvalds reflexively responded “No It’s not,” before adding “Not to me.” But the Linux Foundation has Open Data projects, and “to other people it’s more interesting. And that is, I think, the whole —  for me, the point of Open Source is that different people are interested in different things… I was always interested in the low-level nitty-gritty of how the CPU actually works. Which is why I’m working on the kernel still.”

Towards the end, Torvalds said he didn’t plan to start any new projects. “Linux for me solved all the problems I had, way back in ’92, maybe ’93. And if it wasn’t for the fact that others came around and said ‘Hey, I need this,’ I would not have continued.”

The things that keep is projects going are “the fact that ‘Hey, this is actually useful to other people’. Because if it’s only something for me, it’s not really interesting in the long run.”

The post Linus Torvalds on Security, AI, Open Source and Trust appeared first on The New Stack.

Did you know that just about every page on GitHub has a keyboard shortcut? In this blog post, we’ll uncover the world of GitHub keyboard shortcuts and how they can help you navigate and perform actions swiftly. ⌨️

After reading this post, you’ll be able to:

💡 Master the shortcuts. You might be asking, how can I access said shortcuts? Simply by typing “?” on any Github page!* These shortcuts will empower you to perform various actions across the site without relying on your mouse.

🔧 Customize your experience. You can tailor your shortcut experience by enabling or disabling character key shortcuts according to your preferences, all within your accessibility settings. For more information, see “Managing accessibility settings.”

🎩 Make magic. With the GitHub Command Palette, you can effortlessly navigate, search, and execute commands on GitHub—all without the need to memorize multiple keyboard combinations. To open the command palette, type in this combination:

• Windows and Linux: “Ctrl+K” or “Ctrl+Alt+K”
• Mac: “Command+K” or “Command+Option+K”

Please note: not all shortcuts are available on every page. When you open the shortcut window (?), it will provide you with the available keyboard shortcuts.

Ready to give your mouse a break? Let’s dive into some top keyboard shortcuts to get you started.

🚀 Navigation

Tap these keys to navigate your way around our platform with ease:

T: Quick access to “File Finder.”

W: Close the currently open tab or pull request.

S: Focus on the site search bar.

G, P: Jump to your profile.

📂 Repository navigation

These shortcuts will guide you through your repositories:

G, I: Jump to your issues.

G, P: Navigate to your pull requests.

G, B: Head to your repository.

G, C: Visit your repository’s code.

📝 Issues and pull requests

Spin up issues and pull requests with one single keystroke:

C: Create a new issue.

Y: Close an issue or pull request.

R: Reopen a closed issue or pull request.

K: Move up the discussion timeline.

J: Move down the discussion timeline.

🔍 Search

Quickly spin up a search bar to find what you need right when you need it:

/: Start a quick search.

S: Focus on the site search bar.

F: Search within the code in a repository.

T: File finder for code search.

W: View code in a workspace.

📎 Notifications

Stay on top of your projects with a hop on over to your notifications:

G, N: Go to your notifications.

📤 Create and submit

Spin up a new repository or view your issues in a flash:

N: Create a new repository.

I: Go to your issues.

P: Navigate to your pull requests.

B: Visit your repository.

🔒 Security

Keep abreast of your security posture by navigating to your settings with ease:

G, S: Navigate to your security settings.

With these keyboard shortcuts under your belt, you’ll become a GitHub power user in no time. And remember, you don’t have to commit all of these to memory—the GitHub Command Palette has all that covered for you.

Want to know what other GitHub users’ favorite keyboard shortcuts are? Take a look through the comments on this video. And to further boost your productivity on GitHub, you can explore GitHub Actions—an integrated automation and CI/CD service within your repositories. GitHub Actions streamlines code-related tasks and development by defining event-triggered workflows; check it out today! Get started with GitHub Actions.

The post A short guide to mastering keyboard shortcuts on GitHub appeared first on The GitHub Blog.

How do I embed a Bluesky post?

For the post you'd like to embed, click the dropdown menu on desktop. Then, select Embed Post. Copy the code snippet.

Alternatively, you can visit embed.bsky.app and paste the post's URL there for the same code snippet.

The embedded post is clickable and can direct your readers to the original conversation on Bluesky. Here's an example of what an embedded post looks like:

logging on for my shift at the posting factory

— Emily 🦋 (@emilyliu.me) Jul 3, 2023 at 11:11 AM

Your Own Website

Directly paste the code snippet into your website's source code.

WordPress

Insert a HTML block by typing /html or pressing the + button.

Paste the code snippet. When you switch the toggle to "Preview," you'll see the Bluesky post embed.

Ghost

Insert a HTML block by typing /html or pressing the + button. Paste the code snippet.

Below is what the block will look like. Then, click Preview on your blog draft to see the Bluesky post embed formatted.

Substack

Currently, Substack does not support custom CSS or HTML in the post editor. We recommend taking a screenshot of Bluesky posts and linking the post URL instead.

Other Sites

For your site of interest, please refer to their help center or documentation to learn how to embed Bluesky posts.

Three years ago, I published “Making GraphQL Work In WordPress,” where I compared the two leading GraphQL servers available for WordPress at the time: WPGraphQL and Gato GraphQL. In the article, I aimed to delineate the scenarios best suited for each.

Full disclosure: I created Gato GraphQL, originally known as GraphQL API for WordPress, as referenced in the article.

A lot of new developments have happened in this space since my article was published, and it’s a good time to consider what’s changed and how it impacts the way we work with GraphQL data in WordPress today.

This time, though, let’s focus less on when to choose one of the two available servers and more on the developments that have taken place and how both plugins and headless WordPress, in general, have been affected.

Headless Is The Future Of WordPress (And Shall Always Be)

There is no going around it: Headless is the future of WordPress! At least, that is what we have been reading in posts and tutorials for the last eight or so years. Being Argentinian, this reminds me of an old joke that goes, “Brazil is the country of the future and shall always be!” The future is both imminent and far away.

Truth is, WordPress sites that actually make use of headless capabilities — via GraphQL or the WP REST API — represent no more than a small sliver of the overall WordPress market. WPEngine may have the most extensive research into headless usage in its “The State of Headless” report. Still, it’s already a few years old and focused more on both the general headless movement (not just WordPress) and the context of enterprise organizations. But the future of WordPress, according to the report, is written in the clouds:

“Headless is emphatically here, and with the rapid rise in enterprise adoption from 2019 (53%) to 2021 (64%), it’s likely to become the industry standard for large-scale organizations focused on building and maintaining a powerful, connected digital footprint. […] Because it’s already the most popular CMS in the world, used by many of the world’s largest sites, and because it’s highly compatible as a headless CMS, bringing flexibility, extensibility, and tons of features that content creators love, WordPress is a natural fit for headless configurations.”

Just a year ago, a Reddit user informally polled people in r/WordPress, and while it’s far from scientific, the results are about as reliable as the conjecture before it:

Headless may very well be the future of WordPress, but the proof has yet to make its way into everyday developer stacks. It could very well be that general interest and curiosity are driving the future more than tangible works, as another of WPEngine’s articles from the same year as the bespoke report suggests when identifying “Headless WordPress” as a hot search term. This could just as well be a lot more smoke than fire.

That’s why I believe that “headless” is not yet a true alternative to a traditional WordPress stack that relies on the WordPress front-end architecture. I see it more as another approach, or flavor, to building websites in general and a niche one at that.

That was all true merely three years ago and is still true today.

WPEngine “Owns” Headless WordPress

It’s no coincidence that we’re referencing WPEngine when discussing headless WordPress because the hosting company is heavily betting on it becoming the de facto approach to WordPress development.

Take, for instance, WPEngine’s launch of Faust.js, a headless framework with WPGraphQL as its foundation. Faust.js is an opinionated framework that allows developers to use WordPress as the back-end content management system and Next.js to render the front-end side of things. Among other features, Faust.js replicates the WordPress template system for Next.js, making the configuration to render posts and pages from WordPress data a lot easier out of the box.

WPEngine is well-suited for this task, as it can offer hosting for both Node.js and WordPress as a single solution via its Atlas platform. WPEngine also bought the popular Advanced Custom Fields (ACF) plugin that helps define relationships among entities in the WordPress data model. Add to that the fact that WPEngine has taken over the Headless WordPress Discord server, with discussions centered around WPGraphQL, Faust, Atlas, and ACF. It could very well be named the WPEngine-Powered Headless WordPress server instead.

But WPEngine’s agenda and dominance in the space is not the point; it’s more that they have a lot of skin in the game as far as anticipating a headless WordPress future. Even more so now than three years ago.

GraphQL API for WordPress → Gato GraphQL

I created a plugin several years ago called GraphQL API for WordPress to help support headless WordPress development. It converts data pulled from the WordPress REST API into structured GraphQL data for more efficient and flexible queries based on the content managed and stored in WordPress.

More recently, I released a significantly updated version of the plugin, so updated that I chose to rename it to Gato GraphQL, and it is now freely available in the WordPress Plugin Directory. It’s a freemium offering like many WordPress plugin pricing models. The free, open-source version in the plugin directory provides the GraphQL server, maps the WordPress data model into the GraphQL schema, and provides several useful features, including custom endpoints and persisted queries. The paid commercial add-on extends the plugin by supporting multiple query executions, automation, and an HTTP client to interact with external services, among other advanced features.

I know this sounds a lot like a product pitch but stick with me because there’s a point to the decision I made to revamp my existing GraphQL plugin and introduce a slew of premium services as features. It fits with my belief that

WordPress is becoming more and more open to giving WordPress developers and site owners a lot more room for innovation to work collaboratively and manage content in new and exciting ways both in and out of WordPress.

JavaScript Frameworks & Headless WordPress

Gatsby was perhaps the most popular and leading JavaScript framework for creating headless WordPress sites at the time my first article was published in 2021. These days, though, Gatsby is in steep decline and its integration with WordPress is no longer maintained.

Next.js was also a leader back then and is still very popular today. The framework includes several starter templates designed specifically for headless WordPress instances.

SvelteKit and Nuxt are surging these days and are considered good choices for establishing headless WordPress, as was discussed during WordCamp Asia 2024.

Today, in 2024, we continue to see new JavaScript framework entrants in the space, notably Astro. Despite Gatsby’s recent troubles, the landscape of using JavaScript frameworks to create front-end experiences from the WordPress back-end is largely the same as it was a few years ago, if maybe a little easier, thanks to the availability of new templates that are integrated right out of the box.

GraphQL Transcends Headless WordPress

The biggest difference between the WPGraphQL and Gato GraphQL plugins is that, where WPGraphQL is designed to convert REST API data into GraphQL data in a single direction, Gato GraphQL uses GraphQL data in both directions in a way that can be used to manage non-headless WordPress sites as well. I say this not as a way to get you to use my plugin but to help describe how GraphQL has evolved to the point where it is useful for more cases than headless WordPress sites.

Managing a WordPress site via GraphQL is possible because GraphQL is an agnostic tool for interacting with data, whatever that interaction may be. GraphQL can fetch data from the server, modify it, store it back on the server, and invoke external services. These interactions can all be coded within a single query.

GraphQL can then be used to regex search and replace a string in all posts, which is practical when doing site migrations. We can also import a post from another WordPress site or even from an RSS feed or CSV source.

And thanks to the likes of WordPress hooks and WP-Cron, executing a GraphQL query can be an automated task. For instance, whenever the publish_post hook is triggered — i.e., a new post on the site is published — we can execute certain actions, like an email notification to the site admin, or generate a featured image with AI if the post lacks one.

In short, GraphQL works both ways and opens up new possibilities for better developer and author experiences!

GraphQL Becomes A “Core” Feature In WordPress 6.5

I have gone on record saying that GraphQL should not be a core part of WordPress. There’s a lot of reasoning behind my opinion, but what it boils down to is that the WP REST API is perfectly capable of satisfying our needs for passing data around, and adding GraphQL to the mix could be a security risk in some conditions.

My concerns aside, GraphQL officially became a first-class citizen of WordPress when it was baked into WordPress 6.5 with the introduction of Plugin Dependencies, a feature that allows plugins to identify other plugins as dependencies. We see this in the form of a new “Requires Plugins” comment in a plugin’s header:

/**
 * Plugin Name: My Ecommerce Payments for Gato GraphQL
 * Requires Plugins: gatographql
 */

WordPress sees which plugins are needed for the current plugin to function properly and installs everything together at the same time, assuming that the dependencies are readily available in the WordPress Plugin Directory.

So, check this out. Since WPGraphQL and Gato GraphQL are in the plugin directory, we can now create another plugin that internally uses GraphQL and distributes it via the plugin directory or, in general, without having to indicate how to install it. For instance, we can now use GraphQL to fetch data to render the plugin’s blocks.

In other words, plugins are now capable of more symbiotic relationships that open even more possibilities! Beyond that, every plugin in the WordPress Plugin Directory is now technically part of WordPress Core, including WPGraphQL and Gato GraphQL. So, yes, GraphQL is now technically a “core” feature that can be leveraged by other developers.

Helping WordPress Lead The CMS Market, Again

While delivering the keynote presentation during WordCamp Asia 2024, Human Made co-founder Noel Tock discussed the future of WordPress. He argues that WordPress growth has stagnated in recent years, thanks to a plethora of modern web services capable of interacting and resulting in composable content management systems tailored to certain developers in a way that WordPress simply isn’t.

Tock continues to explain how WordPress can once again become a growth engine by cleaning up the WordPress plugin ecosystem and providing first-class integrations with external services.

Do you see where I am going with this? GraphQL could play an instrumental role in WordPress’s future success. It very well could be the link between WordPress and all the different services it interacts with, positioning WordPress at the center of the web. The recent Plugin Dependencies feature we noted earlier is a peek at what WordPress could look like as it adopts more composable approaches to content management that support its position as a market leader.

Conclusion

“Headless” WordPress is still “the future” of WordPress. But as we’ve discussed, there’s very little actual movement towards that future as far as developers buying into it despite displaying deep interest in headless architectures, with WordPress purely playing the back-end role.

There are new and solid frameworks that rely on GraphQL for querying data, and those won’t go away anytime soon. And those frameworks are the ones that rely on existing WordPress plugins that consume data from the WordPress REST API and convert it to structured GraphQL data.

Meanwhile, WordPress is making strides toward greater innovation as plugin developers are now able to leverage other plugins as dependencies for their plugins. Every plugin listed in the WordPress Plugin Directory is essentially a feature of WordPress Core, including WPGraphQL and Gato GraphQL. That means GraphQL is readily available for any plugin developer to tap into as of WordPress 6.5.

GraphQL can be used not only for headless but also to manage the WordPress site. Whenever data must be transformed, whether locally or by invoking an external service, GraphQL can be the tool to do it. That even means that data transforms can be triggered automatically to open up new and interesting ways to manage content, both inside and outside of WordPress. It works both ways!

So, yes, even though headless is the future of WordPress (and shall always be), GraphQL could indeed be a key component in making WordPress once again an innovative force that shapes the future of CMS.

Welcome to Part 9 of our Azure Cosmos DB Design Patterns series, focusing on Schema Versioning. This edition is particularly useful for those new to NoSQL databases or looking to understand Azure Cosmos DB’s unique capabilities. Here, we will explore how schema versioning can help manage and evolve your database schema efficiently, drawing on real-world applications and specific patterns. By the end of this post, you’ll have a clear roadmap for implementing schema versioning in your projects, ensuring your database keeps pace with application development without downtime or data corruption.

We have expanded the reach of our Azure Cosmos DB Design Patterns, once shared only on a case-by-case basis, by launching a dedicated GitHub repository. This repository highlights a variety of examples that demonstrate the implementation of specific design patterns, tailored to help you tackle design challenges in Azure Cosmos DB projects. Each entry in our blog series delves into one pattern, complete with a sample application featured in the repository. Our goal is to make these powerful insights more accessible, helping you enhance your projects efficiently. Enjoy exploring these patterns, and we hope you find the series both informative and useful.

Here is a list of the previous posts in this series:

• Part 1: Attribute Array
• Part 2: Data Binning
• Part 3: Distributed counter
• Part 4: Global distributed lock
• Part 5: Document versioning
• Part 6: Event sourcing
• Part 7: Materialized views
• Part 8: Preallocation

Azure Cosmos DB design pattern: Schema versioning

What is Schema Versioning?

Schema versioning is the process of tracking changes in the database schema over time. In the context of NoSQL databases like Azure Cosmos DB, schema versioning involves adding a field, typically named SchemaVersion, to each document. This field indicates the version of the schema that the document conforms to. If a document lacks this field, it is treated as conforming to the original schema version.

Schema versioning helps in:

• Minimizing Disruptions: Changes can be made incrementally without affecting existing operations.
• Preserving Data Integrity: Ensures that data conforms to expected schema definitions, preventing errors and inconsistencies.
• Facilitating Evolution: Allows the database to evolve alongside application changes smoothly.

Implementing Schema Versioning in Azure Cosmos DB

Step 1: Define Your Versioning Strategy

Before implementing schema versioning, decide on the versioning format and how granular the versions need to be. A simple numerical increment (1, 2, 3…) or semantic versioning (1.0, 1.1, 2.0…) could be used depending on the complexity of the changes.

Step 2: Modify Your Application Logic

Update your application logic to include the SchemaVersion field in each new document written to Cosmos DB. Ensure that every write operation either specifies the current schema version or relies on default values defined in your database model.

var document = new {
    id = "unique-id",
    SchemaVersion = "1.0",
    data = // your data here
};

await container.CreateItemAsync(document);

Step 3: Handling Data Reads

When reading data, your application should check the SchemaVersion of each document and process it accordingly. Implement logic to handle documents according to their schema version or convert them to the latest version format as needed.

if (document.SchemaVersion == "1.0") {
    // Handle version 1.0 specific logic
} else if (document.SchemaVersion == "2.0") {
    // Handle version 2.0 specific logic
}

Step 4: Data Migration

For documents that are in older versions, you might need to perform migrations to update them to the latest schema. This can be done lazily (on access) or as a batch process, depending on your application needs and the volume of data.

// Example of a lazy migration approach
if (document.SchemaVersion == "1.0") {
    document = MigrateToVersion2(document);
    document.SchemaVersion = "2.0";
    await container.UpsertItemAsync(document);
}

private static dynamic MigrateToVersion2(dynamic doc) {
    // Migration logic here
    return doc;
}

These C# examples demonstrate how to manage schema versioning within an Azure Cosmos DB application using the .NET SDK. Be sure to replace placeholders and types as appropriate for your specific application context.

The Scenario:

As organizations grow and adapt, so do their data structures. In this section, we will discuss how schema versioning plays a crucial role in managing these changes efficiently, particularly using Azure Cosmos DB.

The Need for Schema Versioning

Consider a data-intensive application that must evolve to include more detailed user data, transaction histories, and interaction logs. As new features are introduced, the document schema in the database must be updated to reflect these new data types and relationships.

Implementing Schema Versioning

With Azure Cosmos DB, implementing schema versioning involves adding a SchemaVersion field to each document, which denotes the version of the schema it adheres to. This approach allows applications to handle documents differently based on their version, facilitating a smooth transition as schemas evolve.

Structuring Schema Changes

1. Initial Schema (Version 1.0):
   • Contains essential fields such as userID, transactionDate, amount.
2. Revised Schema (Version 2.0):
   • Adds new fields like transactionHistory, userInteractionLogs.
   • Modifications to userID to support new authentication methods.

Each schema change is well-documented, and the transition between them is managed through version checks in the application logic.

Documentation and Release Notes

For every schema update, detailed release notes are maintained. These notes typically include:

• Changes Made: Description of new fields added or modified.
• Rationale: Reasons behind these changes, such as accommodating new features or improving performance.
• Impact Analysis: How the changes affect existing operations and data, and any necessary actions to adapt to the new schema.

Sample Release Note Entry

## Version 2.0 Release Notes - March 20XX

### Changes Made:
- New fields: `transactionHistory`, `userInteractionLogs` added.
- Updated `userID` to support multiple authentication types.

### Rationale:
- To provide a more comprehensive view of user activities and enhance security measures.

### Impact:
- Documents created with the new schema will utilize these fields. Older documents remain compatible but will operate under Version 1.0.

Sample Implementation:

Case Study:

Wide World Importers operates an online store with its data stored in Azure Cosmos DB for NoSQL. Initially, their cart object was structured simply to accommodate straightforward product orders. Below is an example of the initial Cart and CartItem class definitions and how they were represented in Azure Cosmos DB:

Initial Cart Class:

public class Cart
{
    [JsonProperty("id")]
    public string Id { get; set; } = Guid.NewGuid().ToString();
    public string SessionId { get; set; } = Guid.NewGuid().ToString();
    public int CustomerId { get; set; }
    public List<CartItem>? Items { get; set;}
}

public class CartItem {
    public string ProductName { get; set; } = "";
    public int Quantity { get; set; }
}

Corresponding JSON Document in Azure Cosmos DB:

{
  "id": "194d7453-d9db-496b-834b-7b2db408e4be",
  "SessionId": "98f5621e-b1af-44f1-815c-f4aac728c4d4",
  "CustomerId": 741,
  "Items": [
    {"ProductName": "Product 23", "Quantity": 4},
    {"ProductName": "Product 16", "Quantity": 3}
  ]
}

Updating the Schema

Feedback indicated a need to track special order details for products. To avoid updating all cart items unnecessarily, a SchemaVersion field was added to the cart object to manage changes efficiently.

Updated CartWithVersion Class:

public class CartWithVersion
{
    [JsonProperty("id")]
    public string Id { get; set; } = Guid.NewGuid().ToString();
    public string SessionId { get; set; } = Guid.NewGuid().ToString();
    public long CustomerId { get; set; }
    public List<CartItemWithSpecialOrder>? Items { get; set;}
    public int SchemaVersion = 2;
}

public class CartItemWithSpecialOrder : CartItem {
    public bool IsSpecialOrder { get; set; } = false;
    public string? SpecialOrderNotes { get; set; }
}

Updated JSON Document in Cosmos DB:

{
  "SchemaVersion": 2,
  "id": "9baf08d2-e119-46a1-92d7-d94ee59d7270",
  "SessionId": "39306d1b-d8d8-424a-aa8b-800df123cb3c",
  "CustomerId": 827,
  "Items": [
    {
      "ProductName": "Product 4",
      "Quantity": 2,
      "IsSpecialOrder": false,
      "SpecialOrderNotes": null
    },
    {
      "ProductName": "Product 22",
      "Quantity": 2,
      "IsSpecialOrder": true,
      "SpecialOrderNotes": "Special Order Details for Product 22"
    },
    {
      "ProductName": "Product 15",
      "Quantity": 3,
      "IsSpecialOrder": true,
      "SpecialOrderNotes": "Special Order Details for Product 15"
    }
  ]
}

Managing Schema Versions

It is beneficial to document schema updates comprehensively. Here is a hypothetical schema.md document to track these changes:

Filename: schema.md

## Schema Updates:

| Version | Notes                                         |
|---------|-----------------------------------------------|
| 2       | Added special order details to cart items     |
| 1       | Original release                              |

Implementing in the Application

On the application side, handling the schema version allows developers to render UI components conditionally based on whether the cart includes special orders:

Snippet from the Application Code:

public class Cart
{
    [JsonProperty("id")]
    public string Id { get; set; } = Guid.NewGuid().ToString();
    public string SessionId { get; set; } = Guid.NewGuid().ToString();
    public long CustomerId { get; set; }
    public List<CartItemWithSpecialOrder>? Items { get; set;}
    public int? SchemaVersion { get; set; }

    public bool HasSpecialOrders() {
        return this.Items.Any(x => x.IsSpecialOrder);
    }
}

Rendering Conditional UI Based on Schema Version:

@foreach (Cart cart in Model.Carts){
    <section data-id="@cart.Id">
        <p><strong>Customer: </strong>@cart.CustomerId</p>
        <table>
            <thead>
                <tr>
                    @if(cart.SchemaVersion != null){
                        <th>Schema Version</th>
                    }
                    <th>Product Name</th>
                    <th>Quantity</th>
                    @if (cart.HasSpecialOrders()){
                        <th>Special Order Notes</th>
                    }
                </tr>
            </thead>
            <tbody>
            @foreach (var item in cart.Items)
            {
                <tr>
                    @if(cart.SchemaVersion != null){
                        <td>@cart.SchemaVersion</td>
                    }
                    <td>@item.ProductName</td>
                    <td>@item.Quantity</td>
                    @if (cart.HasSpecialOrders() && item.IsSpecialOrder){
                        <td>@item.SpecialOrderNotes</td>
                    } else {
                        <td></td>
                    }
                </tr>
            }
            </tbody>
        </table>
    </section>
}

By adopting a schema versioning pattern is essential for effectively managing database schema changes. By embedding a SchemaVersion field within each document, applications can support multiple schema versions seamlessly, ensuring smooth transitions and minimizing disruptions during schema evolution. This approach not only maintains backward compatibility and simplifies maintenance but also enhances data integrity and facilitates easier debugging. Implementing structured versioning rules, maintaining detailed documentation for each schema iteration, and adapting application logic to accommodate these changes are crucial strategies for achieving robust and scalable database architecture.

Getting Started with Azure Cosmos DB Design Patterns

You can review the sample code by visiting the Schema validation design pattern on GitHub. You can also try this out for yourself by visiting the Azure Cosmos DB Design Patterns GitHub repo and cloning or forking it. Then run locally or from Codespaces in GitHub. If you are new to Azure Cosmos DB, we have you covered with a free Azure Cosmos DB account for 30 days, no credit card needed. If you want more time, you can extend the free period. You can even upgrade too.

Sign up for your free Azure Cosmos DB account at aka.ms/trycosmosdb.

Explore this and the other design patterns and see how Azure Cosmos DB can enhance your application development and data modeling efforts. Whether you are an experienced developer or just getting started, the free trial allows you to discover the benefits firsthand.

To get started with Azure Cosmos DB Design Patterns, follow these steps:

1. Visit the GitHub repository and explore the various design patterns and best practices provided.
2. Clone or download the repository to access the sample code and documentation.
3. Review the README files and documentation for each design pattern to understand when and how to apply them to your Azure Cosmos DB projects.
4. Experiment with the sample code and adapt it to your specific use cases.

About Azure Cosmos DB

Azure Cosmos DB is a fully managed and serverless distributed database for modern app development, with SLA-backed speed and availability, automatic and instant scalability, and support for open-source PostgreSQL, MongoDB, and Apache Cassandra. Try Azure Cosmos DB for free here. To stay in the loop on Azure Cosmos DB updates, follow us on X, YouTube, and LinkedIn.

The post Azure Cosmos DB design patterns – Part 9: Schema versioning appeared first on Azure Cosmos DB Blog.