DEV Community: Edoardo Dusi

Announcing Storyblok Svelte SDK v5: now fully compatible with Svelte 5

Edoardo Dusi — Mon, 28 Apr 2025 09:34:22 +0000

We're thrilled to announce the release of storyblok-svelte v5, a complete refactoring of our dedicated SDK built specifically for Svelte 5 and its runes system.

This new version takes full advantage of Svelte's latest innovations to provide you with the most powerful, developer-friendly tools to integrate your Storyblok content into your Svelte applications.

Embracing the future with Svelte 5

Svelte always stood out for its compiler-focused approach that delivers exceptional performance with minimal runtime overhead.

With the introduction of runes, the framework took another leap forward into simplicity and power.

As passionate supporters of the Svelte ecosystem, we've completely rebuilt our SDK to embrace these innovations, ensuring that Storyblok users can take full advantage of these new features, while maintaining compatibility with previous versions.

Let's see what's changed!

Cleaner component integration

Working with Storyblok components in Svelte 5 is now more elegant than ever:

<!-- Before (Svelte 4) -->
<script>
  export let blok;
</script>

<!-- After (Svelte 5) -->
<script>
 let { blok } = $props();
</script>

This simplified syntax makes your components more concise while fully leveraging Svelte 5's reactive system.

Enhanced Rich Text rendering

Our rich text renderer is now fully compatible with Svelte 5's reactivity system:

<script>
  import { renderRichText } from '@storyblok/svelte';
  let { blok } = $props();

  // Automatically updates when content changes
  let richTextContent = $derived(renderRichText(blok.content));
</script>

Rich text content now updates seamlessly when edited in the Visual Editor without any extra code.

Seamless Visual Editor experience

The integration with Storyblok's Visual Editor is smoother than ever with our improved storyblokEditable action.

<script>
  import { storyblokEditable } from '@storyblok/svelte';
  let { blok } = $props();
</script>

<div use:storyblokEditable={blok} class="feature">
  <h2>{blok.headline}</h2>
  <p>{blok.text}</p>
</div>

This ensures your components are properly highlighted while you edit your content.

Improved error messages

The new error messages will help you solve issues within your integration faster.

Component "feature" not found. Please register it in storyblokInit:
storyblokInit({
  accessToken: "<your-token>",
  components: {
    "feature": YourComponent
  }
})

Instead of generic messages, you'll now receive helpful guidance on how to fix problems.

Improved TypeScript support

For TypeScript users, we've enhanced our type definitions for better autocomplete and error checking.

import type { SbBlokData } from '@storyblok/svelte';

interface FeatureBlok extends SbBlokData {
  headline: string;
  text: string;
  image: {
    filename: string;
    alt: string;
  };
}

// Type-safe blok access
let { blok } = $props<{ blok: FeatureBlok }>();

Getting Started with v5

Ready to upgrade? Here's how to get started:

npm install @storyblok/svelte@latest

Then update your initialization code:

import { storyblokInit, apiPlugin } from '@storyblok/svelte';
import Feature from '$lib/Feature.svelte';
import Grid from '$lib/Grid.svelte';

storyblokInit({
  accessToken: 'YOUR_TOKEN',
  use: [apiPlugin],
  components: {
    feature: Feature,
    grid: Grid
  }
});

For components, update your scripts to use the new Svelte 5 syntax:

<script>
  import { storyblokEditable } from '@storyblok/svelte';
  let { blok } = $props();
</script>

<article use:storyblokEditable={blok}>
  <h2>{blok.headline}</h2>
  <div class="content">{blok.content}</div>
</article>

Learn by example

We've created a comprehensive SvelteKit playground that demonstrates all the new features in action.

Check out our GitHub repository to see the example code and learn best practices for building with Storyblok and SvelteKit.

Looking forward

This release reassures our commitment to provide first-class support for modern web frameworks.

We believe that Svelte's approach to building web applications aligns perfectly with Storyblok's mission to make content management more efficient and enjoyable.

We're excited to see what you build with this new version of our SDK, and we're already working on more features to improve your Storyblok + Svelte experience.

For more information, check out our official documentation or join our Discord community to share your feedback and questions.

Happy building!

Storyblok unveils new PHP packages in collaboration with SensioLabs

Edoardo Dusi — Thu, 27 Mar 2025 14:28:40 +0000

At Storyblok, we firmly believe in PHP and the power of open source software. Both have shaped the web as we know it today and continue to be crucial in its evolution.

That's why we're thrilled to announce that long with our partners SensioLabs, creators of Symfony, we've completely rebuilt our PHP packages from the ground up.

This collaboration represents more than just an update. It's a complete re-imagining on how PHP developers can interact with Storyblok. By working with SensioLabs, we've ensured these new packages adhere to modern practices, offer excellent Symfony support, and provide a significantly improved developer experience.

Today, we're announcing four brand-new PHP packages designed to make integrating Storyblok into your projects seamlessly.

Our previous PHP client and associated packages will be deprecated as we move forward with these improved solutions.

Let's explore each package and what it brings to the table.

Content Delivery API Client

The Content Delivery API Client is a type-safe PHP SDK designed to retrieve content from Storyblok. It provides an elegant way to interact with your Storyblok space, with built-in support for fetching stories, links, datasources, tags, and assets.

Use this client to easily fetch content for your project:

use Storyblok\Api\StoriesApi;
use Storyblok\Api\StoryblokClient;
use Storyblok\Api\Request\StoryRequest;

$client = new StoryblokClient(
    baseUri: '<https://api.storyblok.com>',
    token: 'your_storyblok_token'
);

$storiesApi = new StoriesApi($client);
$response = $storiesApi->bySlug('folder/slug', new StoryRequest(
    language: 'de',
));

More advanced features like filtering, pagination, and sorting, are also supported, giving you precise control over the data.

Symfony Bundle

The Storyblok Symfony Bundle takes integration to the next level for Symfony applications. Developed in direct collaboration with SensioLabs, it leverages the Content Delivery API Client while adding Symfony-specific features like automatic client configuration and Symfony Profiler integration.

Get started by adding these lines to your config/packages/storyblok.yaml file:

storyblok:
  base_uri: '%env(STORYBLOK_API_BASE_URI)%'
  token: '%env(STORYBLOK_API_TOKEN)%'

With this minimal setup, the bundle handles all the configuration, allowing you to immediately inject and use Storyblok's APIs within your controllers and services.

The bundle also handles environment-specific configuration, making it easy to switch between development and production environments.

Management API Client

The Management API Client allows you to programmatically manage your Storyblok content, providing you with a comprehensive set of tools for creating, updating, and organizing content within your spaces.

This client simplifies complex content management tasks with an intuitive API:

use Storyblok\ManagementApi\ManagementApiClient;
use Storyblok\ManagementApi\Endpoints\StoryApi;
use Storyblok\ManagementApi\Data\Story;
use Storyblok\ManagementApi\Data\StoryComponent;

$client = new ManagementApiClient($accessToken);
$storyApi = new StoryApi($client, $spaceId);

$content = new StoryComponent("article-page");
$content->set("title", "New Article");
$content->set("body", "This is the content");

$story = new Story(
    "An Article",
    "an-article-slug",
    $content
);

$storyCreated = $storyApi->create($story)->data();
echo "Story created, ID: " . $storyCreated->id();

This package is especially valuable for content migration, bulk operations, and building custom editorial workflows.

PHP Tiptap Extension

The PHP Tiptap Extension provides an extension specifically designed for Storyblok's rich text fields processing.

This framework-agnostic package makes rendering rich text fields from Storyblok straightforward and flexible in any PHP project, whether you're using Symfony, Laravel, or any other PHP framework.

You can easily transform Storyblok's rich text content into HTML with customizable rendering:

use Tiptap\Editor;
use Storyblok\Tiptap\Extension\Storyblok;

$editor = new Editor([
    'extensions' => [
        new Storyblok(),
    ],
]);

$editor->setContent(...); // Content from your API

echo $editor->getHTML();

It also allows you to provide your own Block renderer, and it is included in our Symfony Bundle package.

With all these releases comes a renewed PHP Technology Hub in our official website, a starting point for all your future integrations between your PHP projects and Storyblok.

Important note about legacy packages

As part of this launch, the following PHP packages are now entering a deprecation phase:

storyblok/php-client (our original PHP Client)
storyblok/storyblok-php-richtext-renderer (for handling richtext fields)

If your current projects use these packages, don't worry, they will continue to work.

That said, we strongly encourage all users to move to these new solutions, which offer significant advantages including modern PHP 8+ features, better type safety, and extensive testing.

We'll be providing migration guides to help with the transition. Support for legacy packages will continue in the meantime, but all new features will exclusively target these new packages.

The future ahead

These packages represent a renewed commitment to the PHP ecosystem and the open source community, and we want to express our sincere gratitude to SensioLabs for their expertise and collaboration in this endeavor.

This release is just the beginning. We're actively working on expanding our PHP support and have exciting plans for the future (to our Laravel users: stay tuned!.

We invite our wonderful community to try these packages, provide feedback, and contribute to their ongoing development. Get involved at Storyblok Community!

SymfonyCon Vienna 2024: Recap of our Experience

Edoardo Dusi — Wed, 18 Dec 2024 08:37:30 +0000

My personal and professional journey with PHP spans many years, though I've spent recent times focusing on JavaScript frameworks. On the 5th of December, I had the privilege of attending SymfonyCon in Vienna with my manager Alex Jover Morales, courtesy of SensioLabs. This conference wasn't just a technical event for me, it was a heartwarming return to the PHP community that has evolved tremendously over the years.

Conference Highlights

The conference kicked off with an inspiring keynote by Fabien Potencier, the author of Symfony. His presentation focused on Twig, Symfony's powerful templating engine that allows developers to write clean, maintainable templates. The upcoming Twig release introduces exciting features that showcase the continuous innovation in the PHP ecosystem.

One particularly fascinating technical session dove deep into HTTP compression algorithms. The speaker compared different compression methods including Zstandard (a high-performance compression algorithm developed by Facebook), Brotli (Google's compression algorithm optimized for the web), and the widely-used gzip. Understanding these compression techniques is crucial for optimizing web application performance and reducing bandwidth usage.

The Symfony UX presentation revealed promising statistics and future directions for this frontend framework. For those unfamiliar, Symfony UX is a collection of JavaScript components that integrate seamlessly with Symfony applications, bringing reactive features to traditional server-rendered applications. The numbers shared during the talk suggest a bright future for this technology.

Platform.sh, a cloud hosting platform specialized in PHP applications, showcased their latest features, demonstrating how modern PHP deployment can be both powerful and developer-friendly.

A standout presentation came from Paul Dragoonis about Dagger, a programmable CI/CD engine created by the author of Docker, Solomon Hykes. The talk illustrated how PHP developers can leverage Dagger to define their CI/CD pipelines as code, creating and managing Docker containers programmatically, a significant step forward for PHP deployment automation.

The "Strict PHP" session resonated strongly with my own philosophy of writing code for humans, not machines. It emphasized the importance of clear, maintainable code that future developers (including ourselves) can easily understand and modify.

Rob Allen's comparative analysis of GraphQL (a query language for APIs), REST (Representational State Transfer), and RPC (Remote Procedure Call) provided valuable insights into choosing the right API architecture for different use cases.

This is just a quick overview of some of the talks at the conference to give you an idea of some of the most interesting topics that I found there. There were many more over the two days and across three tracks.

SensioLabs

I want to extend special thanks to Oskar Stark and Silas Joisten from SensioLabs for their incredible hospitality. Our discussions went beyond casual conference chat—we dove deep into technical conversations about PHP, Symfony, and some exciting collaborative projects in the works. SensioLabs has been using Storyblok for their website and recently published a wonderful piece about their experience. While I can't reveal details yet, we're working on something remarkable together that we're eager to share with the community soon!

Coming Full Circle

It was great to be back in the PHP community!

It felt like coming home. This experience, along with my role as MC at phpday in Italy this year, has reinforced my view that what makes the PHP ecosystem special is the passion and technical expertise of its community members. Physical events like SymfonyCon are priceless because they create chances to make meaningful connections and share knowledge that you just can't get online.

The PHP community is still growing and coming up with new ideas, guided by the PHP Foundation and supported by frameworks like Symfony. Being part of this growth, even for a short time, reminds me why PHP is still a key part of web development.

Announcing React SDK v4 with full support for React Server Components

Edoardo Dusi — Fri, 22 Nov 2024 11:38:42 +0000

The introduction of the App Router paradigm in Next.js brought significant changes to the way developers build and structure applications. While it opened the door to exciting features like React Server Components (RSC) and finer control over rendering, it also introduced complexity for packages that needed to seamlessly support both client-side and server-side environments.

With the release of @storyblok/react version 4.0.0, we are proud to offer full support for React Server Components in Next.js. This update simplifies implementation, enables live preview functionality in our Visual Editor, and ensures robust server rendering, all in a single, unified setup.

Start using it now with:

npm i @storyblok/react@4

If you are using @storyblok/react v3 with App Router, there are some breaking changes. Please continue reading this article to learn how to update your app.

What's new in @storyblok/react 4.0.0?

Here's a quick rundown of the major improvements in this release:

Unified RSC support
Previously, React Server Components in Next.js required two different implementations for compatibility. With version 4.0.0, we've streamlined this and consolidated everything into one consistent approach.
Live preview with Visual Editor
Developers using the App Router can now enjoy live preview capabilities directly in the Storyblok Visual Editor, enhancing the development and content editing experience.
Seamless Server Rendering
Leverage the full server rendering capabilities of Next.js for improved performance and scalability of your applications

How to use it

Step 1: Initialize the SDK

Start by creating a new file lib/storyblok.js to initialize the SDK. Make sure to export the getStoryblokApi() function.

// lib/storyblok.js
import Page from '@/components/Page';
import Teaser from '@/components/Teaser';
import { apiPlugin, storyblokInit } from '@storyblok/react/rsc';

export const getStoryblokApi = storyblokInit({
  accessToken: 'YOUR_ACCESS_TOKEN',
  use: [apiPlugin],
  components: {
    teaser: Teaser,
    page: Page,
  },
});

The getStoryblokApi() function returns a shared instance of the Storyblok client that works across server and client components.

Step 2: Wrap Your Application with StoryblokProvider

Next, create a StoryblokProvider component to enable live editing on the client side. Wrap your entire app with this provider in the app/layout.jsx file.

// app/layout.jsx
import StoryblokProvider from '@/components/StoryblokProvider';

export default function RootLayout({ children }) {
  return (
    <StoryblokProvider>
      <html lang="en">
        <body>{children}</body>
      </html>
    </StoryblokProvider>
  );
}

Now, create the StoryblokProvider component:

// components/StoryblokProvider.jsx
'use client';

import { getStoryblokApi } from '@/lib/storyblok';

export default function StoryblokProvider({ children }) {
  getStoryblokApi(); // Re-initialize on the client
  return children;
}

Note that the StoryblokProvider is a client component. This ensures that your client-side components can interact with Storyblok, including live editing in the Visual Editor.

Step 3: Fetch Content and Render Components

In server components, use the getStoryblokApi() function to fetch content from Storyblok. Here’s an example app/page.jsx file.

// app/page.jsx
import { getStoryblokApi } from '@/lib/storyblok';
import { StoryblokStory } from '@storyblok/react/rsc';

export default async function Home() {
  const { data } = await fetchData();

  return (
    <div>
      <StoryblokStory story={data.story} />
    </div>
  );
}

export async function fetchData() {
  const storyblokApi = getStoryblokApi();
  return storyblokApi.get('cdn/stories/home', { version: 'draft' });
}

Step 4: Use StoryblokServerComponent for server rendering

For rendering components dynamically, always use the StoryblokServerComponent from @storyblok/react/rsc.

import { storyblokEditable, StoryblokServerComponent } from '@storyblok/react/rsc';

const Page = ({ blok }) => (
  <main {...storyblokEditable(blok)}>
    {blok.body.map(nestedBlok => (
      <StoryblokServerComponent blok={nestedBlok} key={nestedBlok._uid} />
    ))}
  </main>
);

export default Page;

This ensures compatibility with server-side rendering, even if you declare the component as a client component.

What’s Next?

We’re preparing an updated official documentation to make adopting version 4 even smoother. In the meantime, all the essential steps are included in the README.

Your feedback and contributions are vital to improving @storyblok/react! If you have suggestions or issues, feel free to open an issue or contribute directly to the project.

How (and why) to contribute to open source

Edoardo Dusi — Thu, 01 Feb 2024 09:00:00 +0000

Introduction

In the previous post on our blog, Daniela shared her thoughts and experiences on how difficult it can be to contribute to open source. It was hard for me to review this post. I felt like I had failed as a senior developer, as a mentor, and as a long-time member of the open source community. Then I started thinking about the current state of open source, and what Daniela wrote made sense: to a newcomer, everything seems to be driven by the hype, the star count, the likes, the followers, we have tech influencers, we have tech rockstars giving keynotes at conferences, we have recruiters scanning GitHub profiles.

Contributing today is about being visible, not about being helpful. And I think my generation of developers is to blame.

In this post, I will try to respond to Daniela and all the people who struggle to contribute to open source, and most importantly, I will try to talk about the motivations that should drive our contributions.

Contributing to Open Source

First, definitions! Computer scientists have never been good at definitions. We call "artificial intelligence" something that is not intelligent, and we call "cloud" something that is on the ground and sometimes below sea level. We tried with Free Software and we had to specify what we meant by "free", and when we realised we needed a more specific definition we created the Open Source Initiative and we had to specify what we meant by "open".

If we cannot agree on what open source means, we cannot agree on what it means to contribute to open source.

If we stick to the OSI definition, which is derived from Debian's definition of Free Software, we are only talking about how the source code can be accessed, and how the license that governs the distribution of the software should be written.

But when we talk about open source, we're not just talking about code, or at least I thought we were. We are talking about a way of approaching software, of designing it, developing it, distributing it, spreading it, making it something that benefits everyone. So being a developer in this context means thinking of software as a common good, and then contributing means making it better, and if by better we mean more useful, more accessible, more secure, more powerful, more stable, easier to use, then it is clear that we are not just talking about writing code.

It would be pointless to list all the non-coding contributions, I just want to point out participation in groups that create guidelines, documentation and translations, those that try to spread best practices, or all the working groups that deal with standardization. But think about how much valuable discussion is generated in GitHub issues, discussion that leads to better software. None of these activities generate a green square in the contribution grid on your GitHub profile, but each one helps improve the entire ecosystem.

Once we agree on the definition of open source and what it means to contribute, we can move on to the second point in this reflection.

Why contribute

When I started university in Bologna in the early 2000s, the first community I came into contact with was a kind of Linux user group that organized, in a very informal way, so-called "installation parties", i.e. days when some more experienced users would guide us newbies through the first install of a Linux distribution.

In addition to guiding us through the process of installing Gentoo, which was not a random choice, they would suggest what to do when we encountered a problem or noticed something that could be improved. As you may have guessed, this included posting to our newsgroup, starting a discussion on the official Gentoo Forums, and even using the mailing list. This approach made it natural for me and my fellow travelers to think about communicating with senior members of the community whenever the opportunity arose, at first just as generators of trivial questions, then more refined, and finally as proposers of solutions or improvements. I never made a commit to the Gentoo codebase, but I felt useful to the community when I answered a colleague's question about how to fix a compile error by creating a symlink to a library that was in the wrong path.

A few years later I started working with Drupal, still one of the largest and most beautiful free software projects, and interacting with other users on issue trackers, suggesting patches, reporting bugs felt natural to me. Of course, getting the green light from automated tests on an uploaded patch was a good feeling, and when it was merged I felt like I could talk to Dennis Ritchie as an equal, and so I am no stranger to this reward mechanism.

What drove me to contribute, however, was not the reward. It became a necessity, as I was often a few bugs away from delivering a job to a client, and then I felt I had to at least give to others what I had received, so I found myself responding to those who encountered problems I knew how to overcome, or sometimes simply helping by providing my context that might help them understand how to reproduce the bug.

It was therefore, and still is, a business motivation. "Don't reinvent the wheel" has been a mantra, building on what others have already introduced and perfected and then making it better, participating in advocacy groups that shape the future of a technology, and many other aspects of the open source world codified and regulated by organizations such as the OSI, but also the Linux Foundation or the Drupal Association, are all aspects that directly impact our work and thus our business.

Reading Daniela's post presented me with a completely different experience. Talking to her, I realized first of all that she did not find the same conditions in the academic environment that I did, and later that she did not find the communities that I did.

So the social, utilitarian, and "belonging" motivation that drove me, and I think many others around me, was missing, and what was left was rewards. Of course, recognition had always helped to distinguish an active member of a community from others, but it had never generated such strong pressures as to drive someone to contribute for the sole purpose of being visible. I seem to see this problem in the desperate search for a project to contribute to, any project, as long as it is popular and publicly acknowledges contributions, and especially if it is on GitHub, which here becomes the social network where a developer's popularity is measured.
(This also removes Drupal from the list of trendy projects...)

Gamification, badges, likes, they're nice things and we all love them, let's not be hypocritical, but if they're the main reason people contribute today, then we have a problem, and we probably created it ourselves. We've created an environment where it's more important to be visible than to be helpful, and we've given that message to the new generation of developers, but we're telling them today that those motivations are wrong.

So I think it's important to reiterate what it means to do open source.
Let's start from that foundation and try to adjust the focus.

How to contribute - for real

Let's start with a basic concept: you don't have to contribute!

There are amazing programmers out there who have zero commits to public GitHub repos, yet they work with open source projects every day. Sometimes focusing on work or perhaps a busy personal life makes it difficult to find time to contribute, and that's not a problem, it shouldn't make us feel guilty.
Helping a colleague use a technology, making it more accessible by spreading it among your peers, are examples of activities that truly benefit the entire ecosystem but do not entitle you to a badge.

But if, after making all these points, the desire to appear in a project's CHANGELOG remains, because it makes us more desirable in the eyes of a recruiter, or because it makes us feel more important in our community, which are all things I completely understand, then I can try to give some advice on how to contribute.

Start with what you use: You work with libraries or frameworks every day, and by now you know them well; these are the perfect projects to start with. If you need to customize a certain feature to make it more useful for your project, or you find a bug, or you see that some of the documentation could be improved, that's your chance.
There is no such thing as a "stupid contribution": If you think you have a solution to a problem or an idea for improving something, don't be afraid to share it. If you're not sure, ask for feedback, but know that every contribution is valuable, and the worst thing that can happen is that it's rejected.
Don't be afraid to ask: If you don't understand something or aren't sure what to do, ask. There are many channels available, from the official documentation, to the issue tracker, to the community forum, to the chat, to the mailing list. Most (hopefully all) communities are welcoming and eager to help.
Don't overlook the non-code contributions: You can help with translations, documentation, testing (which by the way IS coding...), or even just by spreading the word about a project.
There is more than just GitHub: Many open source projects are not on GitHub, but they still need love. Just ask Drupal.
Join Discussions: Issues and Discussions on GitHub are the most popular, but not the only, way to get started. You can learn a lot about a project from these discussions, commenting increases your visibility and participation in the community, and code contributions can often result.

Conclusion

Open Source is not just code. It's a way of thinking about software, and contributing means making it better.
You don't have to contribute, and I hope that in the future we can create a more welcoming environment for new contributors, and that the reward mechanism will change to reflect effort and dedication, rather than just commits.

Thank you for reading this far, and if you have any questions or comments, please feel free to contact me at Mastodon or LinkedIn.

DruBOM: An SBOM for Drupal

Edoardo Dusi — Mon, 29 Jan 2024 09:00:00 +0000

Introduction

Securing the software supply chain is a hot topic for organizations globally. The recent SolarWinds hack demonstrated that even the most security-conscious organizations can be vulnerable, and as a result, government agencies and security experts worldwide agreed on the need for standards and best practices to achieve a more secure software ecosystem.

One fundamental element is the ability to identify all components of a software project, including dependencies, and their versions. This is called a Software Bill of Materials (SBOM). With this information, organizations can track the components and their versions, and be able to identify and mitigate vulnerabilities.\
There are several initiatives to create standard formats for SBOMs, including CycloneDX, SPDX, and others.

We are working on a Drupal-specific SBOM called DruBOM. In this post, we will explain what DruBOM is, how it works, and how you can use it.

What is DruBOM?

First of all, this is a Drupal module, it needs to be downloaded and installed using Composer, and requires Drupal 9.3 and above or Drupal 10.3 and above.

To generate the SBOM it integrates Anchore Syft, so this needs to be installed on the server. Syft is a CLI tool written in Go that analyzes the contents of a container image or directory on the file system and generates an SBOM in various formats, including CycloneDX and SPDX.

If these requirements are met, DruBOM will generate an SBOM for the Drupal project, including the Drupal core, modules, themes and libraries, as well as PHP and JavaScript dependencies. The default format is CycloneDX, but it can be configured to use other formats supported by Syft.

How does DruBOM work?

The initial version of the module is very simple. It detects the Syft binary and calls it passing the Drupal root directory and the output format as parameters, then saves the output to the key-value store with the drubom.sbom key and the current timestamp.

You can then download the SBOM, or better yet, use it with automated tools to detect vulnerabilities and/or licensing issues.

How to use DruBOM?

The first step is to add the DruBOM module to your Drupal project.\
Run composer require sparkfabrik/drubom and then enable the module with drush or via the Drupal administration interface.

After installing and enabling the module, navigate to Administration » Configuration » System » DruBOM settings and specify the path of the Syft binary. The binary must be executable by the PHP process.

Note: the PHP configuration must allow the use of proc_open(), which is equivalent to exec() in terms of security.

Once the configuration is saved, generate the SBOM by clicking the Generate SBOM button on the settings page or by visiting the /drubom/generate path with a user who has the necessary permissions. The generated list will be saved on the Drupal DB and can be downloaded by clicking the Download SBOM button.

Image: Screenshot of a DruBOM administration page

You can also use the drush drubom:generate command to generate the SBOM from the command line. To download it, use the drush drubom:download command.

What's next?

The scope of the module is very specific, so we don't expect it to grow much in terms of features. During the Drupal Contribution Weekend 2024 we improved the documentation and the administration interface, added an integration with the System Status page in Drupal administration, and started integrating with Grype to also detect vulnerabilities, which is a step forward in terms of security.

We consider this module to be fully stable and ready for production use, so we encourage you to try it out and give us feedback. If you find any problems, please report them to the issue queue.

Journey to the center of DevRel - Part 1

Edoardo Dusi — Thu, 11 Jan 2024 09:00:00 +0000

Introduction

Developer Relations, also known as DevRel, can be defined as the set of activities a company undertakes to build and maintain a relationship with the developer community, both internal and external. It is a relatively new role, and it might be a bit philosophical as a job description: you will see that it involves many company departments, from marketing to engineering, from sales to HR.

Last year we decided to start a DevRel program, and we'd like to share what we've learned. We want to talk about why we did it, the process we followed to get the role and the team up and running, the activities we carried out during the year, and the results we achieved. For those who are considering starting a similar program, and for those who are already doing it and want to compare their experience with ours, we hope this series of articles will be useful.

Let'start with a bit of history.

DevRel through the years

The role of DevRel has been around for a long time, but it is only in recent times that it has become a job title. In the past it was often associated with the role of evangelist, a term many believe was coined by Guy Kawasaki in 1983 when he was working at Apple. In his book The Macintosh Way he wrote about it in the context of a software company:

An evangelist. A good evangelism program has a champion running it. This person lives and breathes the program. He is the figurehead, guiding light, and godfather for developers. He must thoroughly understand the company's product and technology.

And added:

Constant contact. Evangelizing developers is like bonding with a child. You need constant contact with them — talking to them on the phone, seeing their products, and taking them to lunch. A good practice is monthly mailings of technical notes, tips, tricks, and examples. Not only do the developers get information, they also get vibes that the company is on top of things and cares about them.

Image: Guy Kawasaki

Apple sells hardware and software, so the goal of their evangelists was to convince developers to use their products by demonstrating that they were the best choice. Things change when we talk about a service company or a consultancy: we will come back to this later.

Apple's customers were not just developers, and the same was true for companies such as Microsoft or Adobe, but getting them to advocate for their product was a great way to reach a wider audience. "The dentist's favourite toothpaste" is a claim we are all familiar with, and this is more or less the same strategy.

In fact, it was popularised in the early 2010s by companies like Twilio and New Relic, which were among the first to hire developer advocates and create a developer relations team.

Image: A Twilio billboard in San Francisco, early 2010s

The marketing team at these companies understood that they needed to target developers, and when developers are your target audience, traditional marketing strategies don't work, as noted in the seminal book Developer Relations by Caroline Lewko and James Parton.

So they started creating content for developers, speaking at conferences, organising meetups, and generally connecting with developers where they were, using their language: our language. This quickly became a trend, and many other companies followed suit: today virtually every major tech company has a DevRel team, as do many startups and even some open source projects.

Now that the role of DevRel is well established, the competition is tough and even for a company that can invest a lot of resources in it, it is not easy to stand out from the crowd. As developers, we not only want to use the best quality tools, the hottest frameworks, the coolest technologies, but we also want to work with companies that share our values, that have a culture, that are inclusive, that make us feel part of a community.

When we started this journey at SparkFabrik, we had all of this in mind: Developer Relations is about building a community that includes our employees and every engineer that comes in contact with us, it is about sharing our principles and vision, and it is about sharing our knowledge and experience with the community, contributing to open source projects and creating content that is useful to others.

So, we had an understanding of the history of the role in our industry and a somewhat clear idea of what we thought it should be, but since we are a service company and we are not selling a product, even before starting to think about how to do it, we had to answer a fundamental question: why should we do it?

Why DevRel?

The first question we asked ourselves was: why should we do DevRel?

The fact that it is a trend in the industry is not a good enough reason to do it, and what works for other companies may not work for us, especially in the Italian market where we could find very few examples to follow.

Many projects and big decisions at SparkFabrik are the result of a collaborative process, and this was no exception: we started a workshop! We involved different departments, from marketing to engineering, from sales to HR, because we wanted to identify the impact of the figure in different areas of the company, and from the very beginning we recognised that we needed to divide it into two main categories: external and internal.

You can usually apply this to traditional marketing: you want to attract new customers and new talent, and you also want to retain existing customers and employees. So you need to build brand awareness, establish thought leadership in the industry, be a place where the best people want to work and customers want to work with.

Developers are involved in all these aspects, often including the decision-making process when a company seeks a partner for a new project. By engaging with the community and demonstrating expertise and values, a company's services are more likely to be chosen when solutions are sought.

In terms of talent acquisition, we agreed that developers tend to favour companies that engage with the community, contribute to open source projects, and offer resources for skill development. By participating in events, supporting hackathons, and maintaining a visible presence in the community, a company can attract potential customers and talented individuals.

Image: speaking at angularday 2023

All of this requires relations. The success of a services company is increasingly intertwined with the developer ecosystem. As technology becomes more complex and interconnected, developers play a key role in driving innovation, service adoption and influencing decisions: by establishing a dedicated DevRel team, we have recognised the importance of strong relationships with the developer community.

DevRel acts as a bridge between our company and the developer community, facilitating open communication, gathering feedback and creating a collaborative environment.

Investing in DevRel is becoming an integral part of staying ahead in the competitive technology landscape.

Starting with a question such as "Why do we need something?" is an effective way of articulating the purpose and rationale behind a particular initiative, it resonates with different stakeholders, leads to a critical thinking process of analysis, and sets the stage for continuous evaluation, because as circumstances change the answer may evolve, and periodically revisiting the question ensures that the initiative remains relevant and aligned with the company's objectives.

Having agreed on the fundamental "why" of implementing a Developer Relations program, we began to discuss more practical aspects of the team: defining goals and objectives, designing activities and strategies, and evaluating results and impact.

This will be the subject of the next article in this series, so if you are interested in learning more, stay tuned!

OSCM: The Open Source Consumption Manifesto

Edoardo Dusi — Mon, 04 Sep 2023 09:00:00 +0000

Introduction

In our previous blog post, we explained what an Open Source Program Office (OSPO) is and why it is essential for companies that use or produce open source software (OSS). We also provided some guidance on how to create and manage an OSPO, and some useful resources for further learning. If you haven’t read it yet, we recommend you to do so before continuing with this article.

Just a few days earlier, the Open Source Security Foundation (OpenSSF) published the Open Source Consumption Manifesto (OSCM), a set of core values and guiding principles for software organizations that consume OSS and include it in their software supply chain, and we were thrilled to see that it aligns with our vision.

The OpenSSF is a cross-industry collaboration that aims to improve the security of OSS, founded in 2020 as part of the Linux Foundation and including among its first members leading companies and organizations, such as Google, Microsoft, IBM, GitHub, and others. The authors of this Manifesto are members of the OpenSSF End Users Working Group, which focuses on addressing the needs and challenges of OSS consumers and is chaired by Jonathan Meadows, a senior security engineer, and it was published in August 2023 as a blog post on the OpenSSF website inspired by another famous manifesto, the Agile Manifesto.

We believe that after talking about OSPO, it is a good follow-up to talk about OSCM, because both topics are related to the challenges and opportunities of OSS for companies. While OSPO focuses on the organizational and strategic aspects of OSS, and helps companies to manage their relationship with the open source ecosystem, OSCM focuses on the technical and operational aspects, particularly on security.

Let's see what the OSCM is about.

The Open Source Consumption Manifesto

The OSCM is a set of fifteen guidelines for companies and organizations that use OSS (that means, almost all of them) to improve their security posture and reduce the associated risks, and it can be used as a reference to create a security strategy for OSS consumption.

The blog post that presents it starts reminding us that after the Log4Shell incident, everything changed. People were talking about it everywhere, measures were taken at political level, and the community was shaken: it was a wake-up call, and it showed that OSS is not immune to security issues, even if it is generally considered more secure than proprietary software.

But after the initial shock, did something really change? The authors of the Manifesto think that the answer is no, and that companies are not doing enough, using OSS without a clear strategy and without taking the necessary precautions to protect themselves and their customers.

In November of 2022, Tenable found 72% of organizations remain vulnerable to Log4Shell. In December of the same year, Wired magazine drew attention to the lack of response as well. And as we drift further from December 2021, it only gets worse. Last month, software developers consumed hundreds of thousands of vulnerable versions of Log4j.

That's where the OSCM could make the difference: it's a collection of fifteen principles, or best practices, the result of a long discussion with feedbacks coming from members of different companies and disciplines, and it can help those who decide to adopt it to change their approach to OSS consumption.

We can summarize it in four core values:

Responsibility: companies should take responsibility for the consumption of OSS, and security should be considered at every stage of the software development lifecycle (SDLC).
Awareness: companies should be aware of the risks and benefits of consuming OSS, and they should be able to make informed decisions.
Collaboration: companies should collaborate with the upstream developers of consumed components, and contribute to the improvement and sustainability of the OSS ecosystem.
Continuos improvement: companies should continuously monitor, measure and improve the security of the open source components they consume.

Please read the full text of the Manifesto for the complete list of principles and guidelines.

Following the open source philosophy, it is a collaborative effort, so the authors invite everyone to join the working group, adopt it, sign it, and share it with others.

OSCM vs security models and frameworks

Both OSPO and OSCM mention the importance of adopting a security strategy for the software supply chain, but they aren't frameworks or models and they don't provide a detailed plan to follow.

There are established security models, and the OSCM mentions two of them: SLSA and S2C2F. Let's see what they are about.

SLSA stands for Supply chain Levels for Software Artifacts, and it is a framework that aims to provide a set of best practices for the software supply chain, with a focus on OSS. It was created by Google, and it is now part of the OpenSSF. It consists of four levels of assurance, from Level 1 to Level 4, that correspond to different degrees of protection against supply chain attacks.
Our CTO Paolo Mainardi mentioned SLSA in a very good article on software supply chain security, and we also mentioned it in another article about securing OCI Artifacts on Kubernetes.

S2C2F stands for Secure Supply Chain Consumption Framework, and it is a framework developed by Microsoft and contributed to the OpenSSF2. S2C2F is a consumption-focused framework, and it defines a set of practices and a maturity model-based implementation guide to help organizaziont improve the security of their software supply chain.

These are technical details that are out of the scope of this article, but we think that it is important to mention them because the security strategy of a company should be based on a solid foundation, and these frameworks show that there are already some good starting points, companies don't have to start from scratch. If you want to know more about them or other ways to improve the security of your software supply chain, visit the OpenSSF website.

Conclusion

The OSCM carries an intention of inclusion. It has changed over the course of our discussions, and we invite your future changes as well. Most of all, we hope the values and principles contained in the OSCM prove helpful. And that it serves as a guide to better open source consumption in your organization.

We agree with the OpenSSF: time is running out. The security of the software supply chain is a critical issue, and every company should start to take it very seriously. We covered the OSPO topic in our previous article, and complemented it with the OSCM in this one, to show you that there are concrete and viable solutions that you can start exploring today. Of course this is not the complete picture, and you should always consider your specific context, but we hope that this article can help you to get started.

We would love to hear your thoughts, so please feel free to contact us via email or social media.

What is an OSPO and why is it important?

Edoardo Dusi — Mon, 28 Aug 2023 09:00:00 +0000

Introduction

Open Source has become a major force in the software industry, powering many of the most popular and innovative applications and platforms in the world. From Linux to Android, from Drupal to WordPress, from Kubernetes to TensorFlow, open source software (OSS) is everywhere. It's estimated that 96% of all codebases contain OSS, and that at least 85% of enterprise codebases are built with open source components.

In its Annual Report 2022, The Linux Foundation celebrates the growth of the global impact of open source, and its increasing adoption by companies and organizations of all sizes. The report also highlights its importance for the future of technology, and the need for companies to have a strategy for managing its use, particularly in the context of compliance, best practices, and security.

In the whitepaper Open Source:The Missing Data and Management Layer the LF states that leading tech companies such as Apple, Meta, Amazon and Google have detailed strategies in releasing, contributing and sponsoring OSS projects and conferences, and it's becoming a key part of the business strategy also for companies in other industries, such as Comcast, Bloomberg, and BMW.

That's why a growing number of companies are creating a team dedicated to managing this relationship, and this team is called Open Source Program Office (OSPO).

In this blog post, we will explain what an OSPO is and why it is essential for companies at any stage of OSS adoption.

What is an OSPO?

In The Evolution of the Open Source Program Office the TODO Group, an open community born in 2012 that promotes sustainable OSS adoption and governance within organizations, proposed a Five-Stage OSPO Maturity Model, which describes the evolution of the adoption in companies and can be summarized as follows:

Stage 0: Adopting Open Source Ad Hoc: the company uses OSS, but there is no formal process for managing it. Developers are free to use it to solve problems, but little attention is given to licence compliance or the long-term impact on the company's software supply chain.
Stage 1: Providing OSS Compliance, Inventory, and Developer Education: the company recognizes that OSS is a key part of the business, and that they need to manage the legal compliance, security practices, developer education, and software inventory. The company creates an OSPO team to manage these activities.
Stage 2: Evangelizing OSS Use and Ecosystem Participation: the company recognizes the importance of open source ecosystem for the business, and turn to the OSPOs to help them understand how to contribute to and participate to projects and events.
Stage 3: Hosting OSS Projects and Growing Communities: the company hosts or is a primary sponsor of open source projects, dedicating resources to the development of a project and the growth of its community. OSPOs manage the ecosystem, coach project leaders, nurture the community, and seek the assistance of major foundations.
Stage 4: Becoming a Strategic Decision-Making Partner: the OSPO is a strategic partner for the company, is involved in all major decisions related to OSS, becomes an internal technology consultant to the CTO and takes a leadership role in benchmarking what can be considered a good OSS project.

An OSPO serves as the center of competency for an organization's open source operations and structure. It is responsible for defining and implementing strategies and policies to guide these efforts. This can include setting policies around code use, distribution, selection, auditing, contributing, and other key areas; providing education and training to people (inside and outside the organization) involved in open source activities; supporting an organization's efficiency in developing software through encouraging sustainable usage of existing open source components and, where appropriate, contributing enhancements back to these project; when needed, guiding teams with open sourcing their software; ensuring engineering effectiveness; ensuring legal compliance; and promoting and building community engagement.

-- TODO Group

The OSPO is a unit within a company. It can be a whole team or a single person, depending on the size of the company, the level of OSS adoption, and the company's strategy. But why is it important to have an OSPO?

Why is an OSPO important?

OSS is a key part of the business strategy for many companies, but it also presents many challenges. Let's take a look at some of them.

License compliance

Open source software is governed by various licenses that specify the rights and obligations of the users and contributors. Some licenses are more permissive, such as MIT or Apache, while others are more restrictive, such as GPL or AGPL. It is important to understand and respect the terms and conditions of each license, as well as the compatibility and conflicts between different licenses. Failing to do so can result in legal risks, such as lawsuits, fines, or loss of intellectual property rights.

Security practices

Open source software is exposed to a large and diverse user base, which can increase the chances of discovering and exploiting vulnerabilities. Some open source projects may not have adequate security measures, such as code reviews, testing, encryption, or authentication. Moreover, some components may come from untrusted or unknown sources, which can pose a threat to the software supply chain. Therefore, it is essential to verify and validate the security of the OSS that is used or produced, as well as to monitor and update it regularly to address any security issues or vulnerabilities .

The Open Source Security Foundation (OpenSSF) is a cross-industry collaboration that brings together the industry's most important open source security initiatives and the companies that support them. The OpenSSF aims to improve the security of OSS by building a broader community, focused on security best practices, vulnerability disclosure, and security tooling, and it can be a valuable resource for companies that want to improve their security practices: it's essential for them to understand and manage the software supply chain, and to have a strategy for managing the use of OSS, and it may soon become a law requirement.

Developer education

Adopting OSS requires a different mindset and skillset than proprietary software. Developers need to be familiar with a new set of values and practices, such as collaboration, transparency, version control, issue tracking, and they need to be proficient in open source tools and platforms that enable communication, documentation, testing and deployment.

Developers need to understand how to write high-quality and maintainable code that can be easily reused by others, how to contribute to open source projects, and how to participate in open source events. OSS is about community, and developers need to learn how to be part of it.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

-- Martin Fowler

Software inventory

Open source software involves a large and complex network of dependencies and relationships between different components and projects. It can be challenging to keep track of all the open source software that is used or produced by a company, as well as their sources, versions, licenses, security status, and performance metrics. Having an accurate and up-to-date software inventory is crucial for managing the software lifecycle effectively and efficiently, and in some countries maintaining a Software Bill of Materials (SBOM) is a legal requirement.

Open source ecosystem

OSS depends on the active and healthy participation of the open source community. The community consists of various stakeholders, such as developers, users, maintainers, sponsors, foundations, advocates. It is important to engage with the community in a respectful and constructive manner, as well as to contribute back to the community in various ways, such as reporting bugs, providing feedback, submitting patches, donating funds, or hosting events.

This is not only a matter of good citizenship, but also a matter of business. Participating in the open source ecosystem can help to attract and retain talent, to build trust, reputation, influence, and value for the company.

By addressing these challenges, an OSPO can help companies reap the benefits of open source software, while mitigating the risks. An OSPO can also help companies evolve and improve their open source maturity over time. At this point it should be clear that since OSS is vital, companies need to establish a structured way to manage it, and that's why an OSPO is so important. But how do you create an OSPO?

How to create an OSPO

The TODO Group provides definitions, guides, and case studies of OSPOs already established in various companies. You can take a look at how the OSPO operates in Microsoft, for example.

Image: The OSPO Landscape

The starting point for any company that wants to create an OSPO should be the TODO guide.

As with many other strategic decisions, we think that the company needs to clarify why it wants to create an OSPO and what are its expected outcome and benefits. The OSPO should align with the company's vision and values, and be a natural extension of its culture, not an isolated unit. The company should also define the OSPO's mission, goals, and scope.

The company should also define the structure and the location of the OSPO. It can be centralized or decentralized, depending on the size and culture of the company. It can be a cross-functional team, with members from various departments such as engineering, legal, developer relations or marketing, or maybe it will be a single person reporting to the CTO and advising the other teams on open source matters.

The OSPO should be responsible for defining the policies and processes, engage with the internal and external community, foster collaboration, provide the tools and resources to participate in projects and events: this unit needs a good leader, with the right skills and experience and a deep understanding of the company's business and culture. A good reference for this role is the TODO Group's Template Job Posting for Open Source Office Lead.

The process of identifying the goals, the structure and the leader of the OSPO should be transparent, because it will have a central role in the company's strategy and business. It should involve everyone from the CTO to the developers, making sure every input and feedback is taken into account.

Once the OSPO is established, let's take a look at some of the first activities it should perform.

What does an OSPO do?

There is no one-size-fits-all approach to managing open source software, and the OSPO should adapt to the company's needs and culture. However, according to various sources, and examples from companies that have already established an OSPO, we can summarize some common activities that an OSPO should perform as first steps:

Assess the current open source situation: it should perform an audit of the company's OSS, to understand what is used and produced, and how it is used and produced. It should also assess the company's open source maturity, to understand what is the current level of adoption and what are the strengths and weaknesses. It could use frameworks such as the OSPO Maturity Model.
Get executive buy-in and support: it should engage with the CTO and the other executives, to make sure they understand the importance of OSS for the company's business, and to get their support and backing for the OSPO's activities. It needs to demonstrate the value proposition and business case of OSS, and the expected costs and benefits. It also needs to secure the necessary resources and budget.
Build a cross-functional team: even if the OSPO is a single person, this is not a one-persone job, it needs to collaborate with various teams and departments to handle various aspects of open source management. An OSPO would recruit or assign people who have experience and expertise in OSS development, and good communication and collaboration skills, and define a clear reporting structure and authority.
Define policies and processes: it should define the policies and processes for managing OSS, such as the selection, evaluation, and approval of components, the contribution to projects, the participation in events, the reporting of security vulnerabilities, the management of the software supply chain, the creation and maintenance of a software inventory, the creation and maintenance of a software bill of materials, the training of developers, and so on.

These are some of the activities that an OSPO should perform once it is established. Again, the OSPO is not a static or fixed entity, it is dynamic and evolving, because the open source landscape is constantly changing, and the company's strategy can change as well. So the best advice is to start small, and then iterate and improve over time.

Each company should find its own way, and the OSPO should fit its specific objectives and context.'

Resources

If you want to learn more about OSPOs, here are some useful resources:

We also wrote about software supply chain security in a previous blog post The point of no return for software dependencies, and understanding this topic is essential for OSPOs.

Conclusion

In this post, we saw that OSS is a valuable asset for companies, but also that using and producing OSS also come with some challenges. To address these challenges effectively and efficiently, a growing number of companies are creating a team dedicated to managing the use of open source software, and this team is called Open Source Program Office (OSPO).

An OSPO can help companies maximize their investment in OSS, and reduce the risks of using, contributing to, and releasing OSS. It can also help companies evolve and improve their open source maturity, strategy, governance, culture and operations.

We hope you have enjoyed reading this post and learned something new. If your company already has an OSPO, we would love to hear about your experience, and if you are planning to create an OSPO, we would love to hear about your plans. Feel free to contact SparkFabrik on any of our social channels!

Thank you for your time and attention. 😎

Introduction to Qwik and the Power of Loaders and Actions

Edoardo Dusi — Mon, 07 Aug 2023 09:00:00 +0000

Introduction

Qwik is a JavaScript framework for building web applications with a focus on speed. It's designed to be "the fastest possible first load experience" by prioritizing what's important and loading only what's needed. It achieves this by using a component-level code splitting and optimized server-side rendering. Qwik was created by Miško Hevery, the same mind that created the Angular framework at Google, as well as the original AngularJS.

The defining characteristic of Qwik is its instant-on interactivity. Unlike other frameworks, Qwik is resumable, meaning Qwik applications require zero hydration. This allows Qwik apps to be interactive instantly, regardless of the size of the application.

I recently used Qwik for a talk that I'm giving at Come to Code in Italy. I was impressed by how easy it was to get started with Qwik, how fast it was to build a simple application, and particularly in my brief experience I learned to use two of Qwik's server-side features, routeLoader$ and routeAction$, and I wanted to share my findings with you.

Understanding Loaders and Actions

One of the key features of Qwik is resumability, and this is achieved by serializing the state of the application into the HTML and sending it to the client. This means that data loading and state changes must happen on the server, and this is where our two functions come in.

Both are APIs included in Qwik City, a library that provides server focused features.

routeLoader$ is used to bind a route to a function that loads data. This is typically used for loading data when the application is bootstrapped or when the state of the application changes.
routeAction$ is used to handle form submissions, to change the state of the application, and to perform any side effect.

The power of these APIs is their ability to simplify the management of application state and data loading, and the encapsulation of the logic inside specific functions with a separation of concerns that makes the code easier to maintain and reason about. They also allow Qwik to optimize the loading of components and data, and make the application feel faster for the user.

Examples

Let's take a look at an example. Suppose we're building a web application that fetches and displays RSS feeds. We have a function fetchFeeds that fetches the feeds from a list of URLs, and a function sortAndLimitFeeds that sorts these feeds by date and limits the result to the latest 10 feeds.

async function fetchFeeds(feedUrls) {
  // Fetch and parse the feeds...
}

function sortAndLimitFeeds(feeds) {
  // Sort and limit the feeds...
}

We can use routeLoader$ to bind these functions to a URL. This means that when the application is bootstrapped or the state of the application changes, Qwik will automatically call these functions to load the data.

import { routeLoader$ } from '@builder.io/qwik-city';

export const useRssContentLoader = routeLoader$(async () => {
    const feedUrls = ['https://tech.sparkfabrik.com/en/index.xml', ...];
    const feeds = await fetchFeeds(feedUrls);
    return sortAndLimitFeeds(feeds);
});

We can then use this function in our component to load the data. routeLoader$ returns a Signal, so we can get the value simply by accessing the value property.

import { useRssContentLoader } from './rss-content-loader';

export default function RssContent() {
  const rssContent = useRssContentLoader();
  return (
    <div>
      {rssContent.value.map((feed) => (
        <div>{feed.title}</div>
      ))}
    </div>
  );
}

The $ at the end of the function is a boundary marker, and it tells the Qwik Optimizer where to break the code to create chunks, for lazy loading.

The logic inside the function is executed on the server, and the result is serialized and sent to the client. This means that the data is available immediately, and that's why the application is interactive instantly.

Now let's take a look at routeAction$. Suppose we want to add a button to our application that allows the user to add a link from a feed to his favorites. We can use routeAction$ to create a function that executes on the server when the user clicks the button.

import { user } from './user';
import { routeAction$ } from '@builder.io/qwik-city';

export const useAddToFavoriteAction = routeAction$((item) => {
  const link = item.url;
  user.favoriteLinks.push(link);
  return {
    success: true,
  }
});

Now we can add the special component Form to wrap our items list and add a button that calls the useAddToFavoriteAction function when clicked.

import { useAddToFavoriteAction } from './add-to-favorite-action';
import { Form } from '@builder.io/qwik-city';

export default component$(() => {
    const addToFavoriteAction = useAddToFavoriteAction();
    return (
        <Form action={addToFavoriteAction}>
            <div>
                {rssContent.value.map((feed) => (
                  <div>
                      <div>{feed.title}</div>
                      <button name="url" value={feed.link}>Add to favorite</button>
                  </div>
                ))}
            </div>
        </Form>
    );
});

So routeAction$ is exposing a URL that we can use to trigger an action on the server, via a form submission, and the logic executed on the server is the body of the function.

The item parameter that we pass to the function is an object representing the form data. In this case, it contains the property url with the value attribute of the button that was clicked, for example:

{
    url: 'https://tech.sparkfabrik.com/en/blog/qwik-and-the-power-of-route/',
}

And since under the hood the Form component uses the native HTML <form> element, all of these will work without JavaScript enabled in the browser!

Conclusion

There are many other features in Qwik that I haven't covered in this article, but I hope this gives you a good idea of what Qwik is and how it works. When I started working with Qwik to set up a demo, I was expecting a React-like framework optimized for SSR/SSG, and I knew about its resumability concept, but seeing it in action, after developing my simple application and playing with it, looking at its performance, network requests, and the simplicity of the code, I was really impressed. Not to mention the developer experience, which is also great with the qwik new and qwik add CLI tools and the debugging in the browser in development mode, the many integrations that already exist and others that are coming, the wonderful documentation, and the community that is growing around it.

Qwik is ready for production, and I think it's a great choice for building web applications. Maybe I will cover some of its other features in future articles, so stay tuned!