DEV Community: Tim Benniks 🗼

The content Graph is the future

Tim Benniks 🗼 — Tue, 05 Dec 2023 10:40:00 +0000

Content management is as essential as it is complex, especially at scale. As brands grow, they often use a mix of different services to manage their domain content, such as PIM, DAM, Search, and legacy CMS. Unfortunately, this approach challenges developers who must connect all the data to make it presentable on websites or apps, resulting in technical debt. In this article, I will introduce an elegant solution to this problem in this article: the content graph.

The emergence of new buzzwords: best-of-breed and composable

Organizations worldwide are increasingly adopting a composable architecture that incorporates best-of-breed tools. Simply put, they use a combination of tools with a small scope that do exactly what they need. This approach enables developers to select and integrate smaller tools for each specific function, providing enhanced flexibility and scalability.

A best-of-breed product is a specialized service that is considered the best in its specific category. These products are chosen for their unique strengths and seamless integration with other tools or systems in a composable architecture. This allows organizations to create a customized and optimized solution that meets their specific needs.

Unlike monolithic DXPs (off-the-shelf products), which can be inflexible and restrict customization, composable architectures enable organizations to adapt to their specific requirements and take advantage of the latest technological advancements.

If you want to learn more details about industry buzzwords, check out this blog post.

It’s not all sunshine and rainbows

Composable architectures offer a lot of freedom but also introduce a significant amount of complexity. While it may feel liberating for developers to choose how they connect to services, when dealing with large-scale applications, combining data from different structures and using unfamiliar SDKs can quickly become disastrous.

Introducing the content graph

The content graph is a framework that is represented in the form of a graph, and enables developers to query multiple sources of information through a single unified hub.

The graph approach federates content, centralizes content strategy, and standardizes querying processes. This simplifies API interactions, ensures consistency, and eliminates siloed information, maximizing efficiency and scalability. It achieves all these tasks while avoiding data duplication and maintaining the autonomy of the sources.

In human words, this means that all content coming from best-of-breed sources is fed into an aggregation layer (the graph), which can be redistributed in a way that is easy to query. This layer standardizes the language used to query content and allows you to ask for only specific bits rather than receiving everything.

An essential part of this approach is that the content graph doesn’t store or duplicate any data; it merely creates a schema and allows developers to query the data via the graph’s endpoint. This allows the best-of-breed sources that connect to it to be fully autonomous and flexible.

To ensure everything performs well while asking the graph for data (imagine having a slow legacy system as a content source), the content graph stores query results on the CDN edge and offers specific TTL and webhook functionalities.

The benefits

Use these one-liners when you talk about this subject to your boss.

The content graph offers improved content discoverability and accessibility due to strongly typed GraphQL schemas.
With the content graph, you query only what you need from any source and in the same unified way.
The content graph offers efficient content updates and real-time synchronization due to TTL or webhook cache purging when sources update. No data duplication is happening at all.
The content graph facilitates seamless integration with various digital platforms and channels without creating technical debt on the implementation side. In human words, it keeps the front-end implementation simple.

Challenges and considerations

This article wouldn’t be complete without mentioning some of the challenges. Some implementation hurdles might be due to legacy API formats or highly complex data cleansing needs. Legacy APIs tend to be less strict and might change over time. If you need to clean up that data or add a lot of defensive code, you need to find a tool to do that first before pushing the content into the graph. This means your data governance and tooling must mature before using a content graph.

The tech behind the content graph

You might have guessed it: the content graph uses GraphQL as its query language. Using GraphQL enhances the experience for developers as it uses strongly typed data structures, allowing codebases to do introspection and learn instantly what type of data can be queried and in what format. The content graph framework absorbs any data structure and makes it into a GraphQL schema via a language called SDL.

An interesting use case is that of Hygraph, which is a GraphQL headless CMS first but with a content graph implementation on the side. This allows content editors to use external content federated into the graph in native CMS schemas without understanding where that data came from. Developers only need to query Hygraph to get all information from the CMS and whatever source was plugged into it.

A real-life use case for the content graph

An example of using a content graph is that of composable commerce. Imagine operating a large shop selling telecom-related products. As these types of products are complex to manage, companies use a PIM system to enrich product information and manage connections between bundles and brands.

Of course, end users have to be able to search, filter, and order the products when researching what they want to buy. For this, you will likely need another tool to index all products to prepare them for searching.

Each product has a media-rich and elaborate story that generally resides on the product page or a campaign page around a product range. To be able to make this happen, you need a CMS to compose the content and, most likely, a DAM system to store all the original formats of the media you might use.

Lastly, end users must be able to make an account, buy, add to their wishlist, and favorite the products. For that, you need a commerce engine.

The beauty is that all these systems output data that can be ingested by the content graph, allowing developers to query only the graph while using GraphQL. The specialists your brand hires can operate the external tools as usual. Want to add a wishlist or switch our PIM systems? Add it to the graph; the front-end implementation code must not change.

One more consideration: if you have a legacy system in place, it can be federated into the content graph while staying autonomous and operating normally. Developers on the implementation end do not need to query the system but ask the graph for its content instead. This gives you the ability to phase it out slowly.

Conclusion

The content graph might sound like a concept out of a sci-fi movie, but it’s already here and ready to use. In fact, I think this might be the technical solution for most composable architectures.

What type of content organization do you need?

Tim Benniks 🗼 — Sun, 12 Nov 2023 09:03:33 +0000

Different ways of working require different approaches to content design. In this post, I will outline a few content organization approaches based on how your brand operates digitally.

Every brand manages its digital organization differently. Some are incredibly decentralized, with each department having its own tech stakeholders, agency partners, implementation studios, and consultants. Others are highly centralized, with one person or department making decisions about the digital presence of every entity. Of course, there is also a large grey area in between.

One thing is clear: most brands are transitioning to a more flexible approach, composing their digital organization using specialty tools that handle their specific domain content. This is instead of relying on an off-the-shelf monolithic tool that attempts to do everything to some extent.

Brands that adopt a decentralized approach require more flexible tooling to accommodate the increased number of people involved who need autonomy. This necessitates the use of marketing-first systems for content management. On the other hand, the centralized approach requires less tooling and is more technologically focused, as it follows a fixed set of specifications for each experience. In this case, the main requirement is to obtain data and build the experience accordingly.

How to organize your content without going crazy

If your content flows between different systems, federation is one of the most effective ways to manage it.

Federation is a software process that enables multiple sets of content to operate as a unified whole. It creates a virtual view of the content by gathering data from various sources and transforming them into a standardized model. This ensures a single source of data for front-end applications.

Federation is a broad spectrum, and only some things written in this post may fit within the scope of technical purists. However, similar to agile and scrum, we observe various approaches associated with federation.

In today's landscape, as brands acquire domain content from multiple sources, it is essential to federate that content to a central location. The federation method can vary greatly, and the approach chosen will depend on the structure of your digital organization, technical capabilities, and specific requirements.

Forms of federation

There are many different types of federations for building brand websites. In this article, we will focus on a few major ones that fit the context of building commerce platforms and marketing campaigns.

Data stitching and custom middleware

Data stitching or a custom middleware are not exactly forms of federation, but you encounter them often in the wild. Tech teams query, clean up, and map data from the specific front end they are working on, which creates complexity and technical debt in the implementation. Initially, this approach may feel flexible and give developers autonomy, but as the scale increases, it becomes unsustainable. The entire process must be repeated when another channel is created (such as a website, mobile app, kiosk, etc.). To address this issue, people started creating custom middleware solutions at API level. While they still suffer from similar problems, at least they centralize the data query, clean up, and mapping in one place. However, creating proprietary code to attack problems that affordable products solve, is usually a waste of time.

Content Hub

A content hub is a centralized source of truth that collects and duplicates data from various sources. It organizes the data and performs cleanup and data remapping within the hub itself. This approach can be viable if the data sources do not need autonomy and you are not concerned about potential outdated content resulting from the content hub's data duplication.

Data Lake

A content lake is a repository where data of any type is stored without considering its structure. It remains in its raw form and can be accessed by anyone. This approach is highly beneficial for machine learning and reporting tools. Having a well-established data cleanup pipeline and being willing to accept potential technical debt make the content lake an excellent choice for your brand.

Content Federation

Content federation aggregates data by establishing a unified, simplified, standardized approach for querying it. This approach allows the connected sources to remain autonomous and flexible. Content federation effectively separates data from systems and provides the capability for precise cache purging. Unlike the content hub, there is no data duplication. Instead, the data is cached in the CDN edge with granular cache invalidation.

Content federation works well (and is typically combined) with a CMS that can ingest the data and use its APIs.

DXO (digital experience orchestration)

Digital Experience Orchestration focuses on API orchestration and decision-making to create and manage digital experiences. In every project, there is a hidden area where unclean data exists. DXO can address this issue by integrating data sources at runtime, cleaning them up, and offering clean API endpoints. Additionally, DXO can personalize endpoint data in real time, taking input from a front-end and combining content from various sources.

Beware, DXO is not a CMS, and its endpoints must be plugged into a Content Federation platform like Hygraph if you want to use it. If you do not need a CMS, DXO can be used standalone.

GraphQL Federation

GraphQL Federation is the idea of connecting two or more GraphQL APIs (subgraphs) to create a single unified GraphQL API known as a supergraph. Each backend team or domain can develop and manage their subgraphs independently. Federation is simpler in GraphQL than REST because the ability to link types is inherently built into GraphQL. GraphQL federation is highly technical, rigorous, and structured, making it ideal for large-scale data applications and technical teams that require seamless communication. GraphQL federation works great standalone and not combined with a CMS. It’s highly technical and focuses on API endpoints.

A few other techniques and companies are not precisely GraphQL federation but reach the same goal: a single API endpoint for tech teams: Apollo Federation, Open Federation, Grafbase, GraphQL Fusion, and Graph weaver.

Which federation is for you?

Choosing the preferred federation type depends on how your brand's digital organization was set up. Let's determine which federation type suits your company best by asking a few questions.

What is your digital organization direction: centralized or decentralized?

The more decentralized an organization is, the greater the need for additional CMS or visual editing tools. A perfect example is the L'Oréal group, which has numerous brands. Each brand independently decides which content is displayed for its various markets, resulting in a completely decentralized structure. With many content editors actively building pages, autonomy, and flexibility are essential. In this case, the best approach is to implement Content Federation with a CMS on top.

Federation type to choose: Content Federation

If we consider the opposite approach, let's take a brand like Louis Vuitton as an example. They have highly stylized pages and campaigns that are consistent worldwide. They maintain a unified brand, website, tone of voice, content design, and art direction. Due to the limited number of people creating the experience, the need for tooling is less significant. Editing content simply involves adding text in a form, and the front-end implementation determines how it is displayed. Since content changes infrequently, a content hub with CDN cache might suffice.

Federation type to choose: Content Hub

How much cleanup does your data need?

Many brands have a dark corner where various data exists, usually resulting from pragmatic technical decisions made over time. This data is structured, cleaned, and mapped through complex build processes by unhappy developers. Integrating this data into a front-end implementation is often challenging, requiring creating proprietary logic. If any part of this process fails, the entire system fails.

If your brand faces this issue and lacks the time or budget to address it, a DXO (Digital Experience Orchestration) may be a suitable solution. DXOs can serve as a new source for static or async data on legacy servers and provide cleaned content at runtime. These streamlined API endpoints can seamlessly fit into a Content Federation workflow and be utilized in a headless CMS like Hygraph.

Federation type to choose: DXO, Content Federation

How autonomous do your data sources need to be?

At scale, brands have dedicated individuals who specialize in enriching content in specific areas such as PIM, CRM, search, or DAM. These individuals should have the autonomy to work without being restricted by proprietary middleware or opinionated front-end implementations. The greater the need for autonomy, the less suitable a content hub, Content Lake, or DXO would be. Code stitching or proprietary middleware, in particular, should be avoided. Instead, consider using content federation. If you are dealing with big data or reporting, please continue reading below.

Federation type to choose: Content Federation

If you do not require autonomous sources or lack the resources to have specialized individuals enrich content, consider implementing a content hub. However, remember that your data may become outdated, so it is essential to establish a method for regularly refreshing the data.

Federation type to choose: Content Hub

Are you dealing with big data?

Cleaning up and mapping big data into specific models for channel presentation can be challenging. In such cases, a content lake is often the most suitable option. A content lake stores raw, unstructured, and structured data, which can be used to train machine learning models or generate reports. Additionally, a content lake can be beneficial if you have a highly skilled developer team that does not require a CMS.

Federation type to choose: Content Lake

Are you a SaaS with multiple tech silos?

If you are working with multiple tech teams and dealing with a lot of data from various sources but don't need a CMS for a marketing website, you can use GraphQL to organize all the data into a graph. This allows different teams to query the data without needing individual data contracts. GraphQL Federation is the perfect choice in this scenario. It provides a highly structured and precise approach, offering flexible APIs through GraphQL.

Federation type to choose: GraphQL Federation

Conclusion

As always, the answer is: "It depends". Ensure you have the right technical stakeholders on your team to analyze your brand's digital needs. Once you identify the issues, contact specialists at agencies or the enthusiastic team at Hygraph for assistance. At Hygraph, we envision the future of content as one big graph. Brand domain content and origin sources, where data is enriched, will contribute to this graph. Implementations on various channels such as websites, apps, or sales systems can query this graph and retrieve exactly what they need. Content Federation with an attached CMS is suitable for many use cases.

The real deal about content management buzzwords

Tim Benniks 🗼 — Thu, 28 Sep 2023 14:43:37 +0000

Buzzwords are labels that describe tech approaches that become so commonplace over time that the label disappears, and people do what works best. Remember Jamstack? Neither do I. The term became so widespread that it faded away. Netlify, the company that coined Jamstack, now uses Composable, which will likely disappear too.

First, let's define some current buzzwords. Afterwards, I'll explain why they don't actually matter.

Do you like watching more than reading? Watch this YouTube video instead.

MACH

MACH architecture comprises principles and practices for building and managing digital experiences. The acronym MACH stands for Microservices, API-first, Cloud-native, and Headless.

Essentially, MACH is a collection of tech approaches with specific tendencies put together. If you build something with all four items, you are MACH compliant. Otherwise, you are not. MACH provides a label you can put on your software as a vendor. This does not mean products lacking one of the four MACH features are flawed. However, it also means that companies like Adobe, Sitecore, and WordPress will never be MACH members.

Microservices are small, independent services that are loosely coupled and communicate with each other through APIs. This makes microservices architecture more scalable and flexible than traditional monolithic architectures.
API-first means that all functionality is exposed through APIs. This makes it easy to integrate different services and build new applications.
Cloud-native means that the architecture is designed to take advantage of the cloud, such as scalability, elasticity, and pay-as-you-go pricing.
Headless means that the front-end presentation is decoupled from the back-end logic. This makes it possible to use different front-end technologies without changing the back-end.

Composable

Composable architecture refers to a modular approach built around reusable components that brands assemble themselves rather than buying an off-the-shelf product, with a key advantage being the flexibility to swap components to adapt to changing needs, avoiding significant rebuilds required by monolithic systems.

While solving problems of rigid all-in-one solutions, composable architecture can have complex development and workflows. Composable architecture and MACH architecture are both approaches to managing digital experiences, with composable architecture focusing on the API-first "A" in MACH by composing APIs into a cohesive architecture. There are different techniques for connecting APIs in a composable architecture, ranging from content hubs to content federation to proprietary middleware.

Overall, composable architecture represents an architectural philosophy of modularity and flexibility in contrast to traditional monolithic digital solutions.

DXP (Digital Experience Platform)

A digital experience platform (DXP) is an integrated set of core technologies that support the composition, management, delivery, and optimization of contextualized digital experiences.

Typically, a DXP is delivered as a monolithic piece of software by a single vendor. While modern DXPs may offer some composability, their components are usually proprietary to the vendor. This can limit flexibility and result in vendor lock-in, as brands cannot easily swap out or integrate other technologies.

DXC (Digital Experience Composition)

Digital experience composition refers to no-code/low-code tools and platforms that allow digital teams to build and manage digital experiences in a composable architecture easily. The collection of these tools includes three categories of software: a light front-end SDK or front-end as a service, a page builder, and API integrations to connect data.

DXC is essentially a modern version of the DXP but vendor-agnostic. DXC is leaning towards website channel-specific as it offers front-end SDKs and live previews. If the product doesn’t offer an iOS SDK, the customer is alone.

DXO (Digital Experience Orchestration)

Digital Experience Orchestration emphasizes API orchestration and decision-making to create and manage end-to-end digital experiences. DXO platforms provide visual tools to orchestrate digital experiences but do not include WYSIWYG editors for managing the front-end experience.

DXO is essentially DXC without the front-end components, focusing only on data stitching. It is pretty unique in the MACH space that we see analytics and a/b testing added to the orchestration solution in the back-end rather than at the CDN edge specific to the end user.

Why you don’t have to care about the buzzwords

Ultimately, it is up to you to decide how to build the digital experience for your brand, both internally and externally. There are many paths to success, and you need to understand your business needs, maturity, and technical skills to choose the best route. Nowadays, technical product owners need to be more knowledgeable about the technology landscape and internal business needs than ever before.

Company maturity

As companies grow, they gain a deeper understanding of the problems they solve as a business. The more they know about these issues, the more specific their choice of speciality software becomes. Less mature companies, or those that are large and indecisive, tend to gravitate towards monoliths that offer broad functionality, covering most bases.

However, as companies mature, they may struggle with the limitations of these monoliths. Any customization work on a monolith can be time-consuming, complex, and expensive. This is why re-platforming has become such a significant trend in our industry.

Connecting it all

Assuming you have chosen the perfect PIM, DAM, ERP, commerce engine, and search tool, the next step is to connect all these moving pieces into a cohesive architecture. This will enable you to create a platform application that both end-users and internal teams will love to use.

The architecture direction should be chosen based on the technical proficiency of your teams. Simply purchasing specialized software does not create a cohesive architecture.

Content federation

To avoid a MACH monolith or MACHlash, you need a system to “federate” all content sources into a unified view. This system should standardize and simplify the data for later querying while keeping the speciality sources autonomous. That way, the teams in charge of PIM or Search can work without influence from other systems.

Content federation is a very lightweight approach to unifying different data sources into a transparent and easy-to-use endpoint while keeping the complexities of your data sources where they need to stay. Your speciality products for PIM, DAM, eCommerce, and Search remain autonomous and safe while front-end implementations ask the Federation platform for information.

After Content federation is in place

Now that the content federation has been established, aligning the company's maturity, technical skill, and vision with the choice of products that follow this step is essential. If you have the necessary technical ability, add a headless CMS, query the federated data endpoints, and you’re done. You can add best-of-breed a/b testing, and localization services later.

If you need additional elements, such as personalization or visual editing, consider using a DXC like Uniform or a DXO like Conscia. Ultimately, these tools serve the same purpose but with different approaches to the problem. Some tools are more visually oriented and offer greater personalization, while others are more data-driven. Consider your company's maturity and technical skills before selecting a tool.

Concluding

Every modern architecture requires a combination of the appropriate specialty providers, based on company maturity and technical skills. After that, the next step is to use a tool that federates all of these content sources into a single unified endpoint. This helps to simplify and standardize the architecture, while still maintaining the autonomy of the specialty systems.

Once the basics are in place, look internally at the specific needs and choose between DXC, DXO, or anything in between.

The future of headless CMS: Content Federation with GraphQL

Tim Benniks 🗼 — Thu, 28 Sep 2023 14:39:16 +0000

Federation is a popular topic of conversation these days, and for good reason. With the ever-growing amount of fragmentation in tooling, it offers a way to decouple data and systems, giving organizations more flexibility and agility.

Despite the promise of headless architecture, data, and systems easily become tightly coupled. Whether through custom middleware or frontend stitching, one system can have ripple effects on all others. This can make it difficult to manage and update content and causes technical debt. In the past, I called this the MACH Monolith.

A federated architecture, on the other hand, truly decouples data and systems. Federation is a technique of using autonomous systems to work with the data and logic they’re best suited for. What differentiates that from the MACH Monolith is how the data comes back together. Federation takes these autonomous services and crafts a unified, standardized, and powerful API for use in any application.

While there are many patterns for accomplishing federation, one architecture is Content Federation. Content federation is the process of bringing together content from multiple sources into a single, unified view that can be accessed both at the API layer, as well as at the editor level.

In a federated architecture, the content federation layer brings together content from the different systems. This layer acts as a single point of access for data, making it easy for users to get the content they need, regardless of where it is stored.

A few benefits of a federated architecture include:

Increased flexibility and agility: Each system is responsible for its data and logic, which gives them more autonomy and flexibility. This makes it easier to manage and update systems and makes it easier to add new systems to the architecture.
Improved security: A federated architecture can reduce the attack surface. When data and systems are tightly coupled, a vulnerability in one system can compromise other systems. A federated architecture reduces the risk of this happening by decoupling data and systems.
Reduced complexity: A federated architecture can simplify how data is managed. In a traditional architecture, data is often stored in multiple systems, making it difficult to keep track of. A federated architecture brings together data from different systems into a single, unified view, which makes it easier to manage, inspect, and use data. The implementation layer has one standardized, unified way to ask for the content.

Overall, a federated architecture is a powerful way to decouple data and systems, giving organizations more flexibility, agility, and security.

The importance of autonomy in a federated architecture

While most federation articles focus on the benefits of unification, system autonomy is really the key benefit. This autonomy means that systems can be developed and managed independently without worrying about the other systems in the architecture. This can be a major advantage, as it allows organizations to be more agile and responsive to change while still maintaining standards.

This enforced autonomy increases the reach of standardization. In an e-commerce application, product information — pricing, description, categorization — should be standardized wherever it’s used. Without Content Federation, the product data would be re-entered in the systems that don’t house it. When an editor of the blog goes to create a post about a product, they introduce the human potential for error. If they merely select a product from the e-commerce system, they can rely on the owners of that data to keep their data standardized.

When the standards for a particular piece of data changes, the data is changed in the home system, and each other system is ready to receive that change. No additional work necessary.

Conclusion

A federated architecture is a powerful way to decouple data and systems, giving organizations more flexibility, agility, and security. Federation brings autonomy to the data layer while also giving rise to a unification layer Content Federation brings a deeper sense of standardization through systemic change instead of human change. Without autonomy, we have complexity; without unification and standardization, we have glue code. We need both in the modern stack.

New job alert!

Tim Benniks 🗼 — Wed, 16 Aug 2023 13:42:10 +0000

After an exciting journey at Uniform, it's time for a new adventure.

At Uniform, we thrived during the pandemic, hiring the best talent remotely and finding success in a new product category. I not only learnt a lot but also created value towards company perception and trust along the way.

Inspired by the startup life, I wanted a new challenge at a company further along their journey. Hygraph caught my attention with its product-led growth, open source SDKs, solid product-market fit, and strong fit for developer relations.

I'm excited to join Hygraph as the Developer Relations Lead for Outreach and Awareness. With 15 years of agency experience, deep knowledge of the developer space, and connections within the MACH alliance, I'm confident in bringing my skills to this product-led growth company.

Working alongside experienced professionals like Bryan Robinson (Orbit, Algolia, Sanity) and Lo Etheridge (Sanity, and many other dev gigs), I'll be part of Hygraph's developer relations team within the larger marketing organization led by Omer Gokce Tumer.

Hygraph is at the forefront of the composability and content federation space. They provide a solution to the challenges faced by scaled headless architectures, bringing stability and flexibility. Companies like Netlify, Conscia, and Octoo have embraced Hygraph's approach to content federation, validating the category.

If you're seeking content federation at scale, Hygraph has a remarkable head start and addresses the current code-first problems in the MACH architecture space.

I'm eager to get started and can't wait for what lies ahead. See you soon!

Cheers,
Tim

This is headless 2.0

Tim Benniks 🗼 — Tue, 11 Jul 2023 07:48:19 +0000

That’s a bold title, but it’s high time to change how we work with headless technology. I wrote about the MACH monolith before. Here, I’ll describe how to avoid ending up in a codebase full of technical debt, aka glue code—chores that overburden and frustrate developers.

The why

Headless technology has gained prominence in web development, offering benefits like higher performance, front-end freedom, DX features, and management through APIs—a thrill for techies. However, at scale, complexities arise due to an endless need for glue code for connecting content sources, let alone authoring issues caused by disconnects between content editors and front-end presentation.

In particular, separation of content authoring and presentation results in a steep learning curve for content editors, who would need help to preview their work and ensure a correct display. But how do you preview content that connects to multiple sources, all offering some form of preview capability? As a fix, people do either of the following:

Connect to the sources via CMS plugins and add data-modeling capabilities for page layouts unrelated to core CMS functionalities. For more details, read my article on the MACH monolith.
Hard-code all the connections in the front end, forcing content editors to file IT tickets for updates.

For web projects to succeed, since developers, marketers, and content editors boast different strengths, teams must be able to collaborate harmoniously and seamlessly. For all that headless promises freedom and excellent developer experience, it pushes the pain threshold of marketers.

Connecting lots of services creates glue code and technical debt.

The how

Two things are paramount as a fix:

Simple, easy-to-maintain front-end codebases that contain minimal glue code and technical debt.
Elimination of the need for content editors to tackle the abstractness of a composable architecture populated by a plethora of different tools. Content editors need a visual-editing capability across headless sources to ensure the display is exactly what they desire without giving up on a solid technical architecture.

In other words, content editors need a page-composition process similar in concept to that of GraphQL, i.e., one that returns only the needed properties and content of all page components. All the editors need to do is add the component props with data from external sources—with no need to know the data’s origin. The result is curated, page-specific JSON output that can be consumed by the front end, which need not connect to external data sources.

Connect services to design system components and compose a page. Curate your data a la GraphQL but visually.

What emerges is a transparent and simple platform on which to compose pages based on design components, whose props point to a field in an external API endpoint. That platform would not be a CMS or data-federation tool. All it needs to know is which component points to which data source for a specific page composition.

A visual workspace

Therefore, the job of the platform, which represents all the design components with linked data sources (CMS, PIM, DAM), is to connect them and store the result like a curated GraphQL query on a CDN edge. The only data this platform would potentially store are one-off content strings like “latest blog posts” or the fact that a particular component variant, e.g., the image on the left or right, is shown in a specific context.

That setup gives rise to a streamlined workflow:

To publish content, editors visually connect external data to components properties. That data can come from any source.
Editors compose their design-system components visually to represent the page design they want.
A curated JSON structure of the composition is saved to the CDN edge.
The front end connects to the API endpoint of the platform. An intuitive and light SDK connects to the CDN edge, keeping the front end code simple.

To make it all visual for content editors, match the naming of the design-system components in the codebase to the ones in the platform and have the SDK show the components in a preview window. Simultaneously, content editors can bind data from external sources to the props and design how the components should look and behave.

With solid cache purging for data sources, you can create dynamic pages that connect to any amount of data and deliver in less than 50ms from a CDN edge near you. In case of external data-source changes, the TTL on the field or a webhook purges the cache, resulting in fresh data.

If used in conjunction with the latest Next, NuxtJS, or Astro features, this approach leads to a robust yet no-frills front end with no need to connect to data sources in code or mapping their data to component props. Talk about happy developers!

Map design system component props to individual API response fields to create a visual editor that works across headless sources.

A recap

Connecting everything code-first at scale is painful for developers and content editors alike, the former having to maintain the connections and content mappings, and the latter getting lost in the abstract tools with no clues of what happens on a click to publish.

A composable architecture of headless sources must be a team buy, not just a developer choice. What’s needed is a visual workspace that’s—

Friendly to content editors but also feature-rich for developers while maintaining excellent technical architecture without compromises.
Agnostic and not a one-size-fits-all offering from a single CMS vendor.

In other words, we need a modern, composable form of the old-school DXPs like Adobe AEM. I believe what I described above resembles digital experience composition as coined by Gartner.

This is Headless 2.0

The lost promise of headless

Tim Benniks 🗼 — Mon, 26 Jun 2023 18:18:19 +0000

In recent years, headless technology, which boosts performance, developer experience, and best-of-breed headless systems, has gained significant traction in web development. At its core, headless streamlines and accelerates the process of building and delivering web experiences through APIs, which separates content creation and management from presentation.

However, despite the excitement and promise, headless technology has fallen short in living up to its potential in several key areas.

Technical complexity

The primary appeal of headless technology lies in decoupling content creation and presentation, as a result of which developers can work on the presentation layer with their preferred tools and frameworks while content editors can focus on building and managing content. However, that separation comes at a cost. Specifically:

To connect the multiple layers, a significant amount of code must be written, which leads to technical debt, a heavier workload, and inflexibility.
Adding data to content models to address design-driven choices for an output channel, e.g., checkboxes to enlarge an image, pollutes the data model. The more design-related and channel-specific data you add to content models, the more technical debt you create.
If you must connect a different data source to the same front-end component, but the content models do not align, issues arise.

Content-editing challenges

Another major challenge with headless technology is the disconnect between content editors and the systems they work with. Due to the abstract nature of headless CMS, content editors often struggle to pinpoint how their content will be displayed on the front end, leading to confusion, frustration, and a steep learning curve for novices.

Moreover, the lack of a clear connection between content and presentation makes it difficult for content editors to preview their work and ensure that it looks and functions as intended. A suboptimal user experience results, let alone a time sink for revisions and troubleshooting.

The way forward: DXCP

Without question, despite the promise of headless technology for revolutionizing the way we build web experiences, serious hurdles remain. To overcome them, tools and processes that facilitate team collaboration and streamline the development process are necessary so that developers and content editors can work closely together to bridge the gap between content creation and presentation.

A proven solution is a digital experience composition platform (DXCP), which seamlessly integrates content and presentation. While on that platform, nondevelopers can visually create and manage digital experiences with content from multiple sources, delivering those experiences agnostically to a front-end of choice, significantly reducing technical debt, and gaining flexibility. Businesses can then adapt and innovate much faster, especially since the connection to all headless systems and APIs occurs in the DXCP, and the code remains clean.

What’s more, the incorporation of a DXCP into the development process affords content editors a clear view of how their content will be displayed and the ability to interact with the presentation layer. Plus, the absence of data silos means a more streamlined and efficient workflow as well as a more intuitive user experience for both content creators and developers.

Level up your collaboration game: Developer insights for winning with marketing pros

Tim Benniks 🗼 — Wed, 03 May 2023 15:49:29 +0000

Building outstanding user experiences takes, first and foremost, effective collaboration between marketing and development teams. Oftentimes, however, those teams’ different perspectives lead to misunderstandings and opacity, which could seriously impact progress and revenue. Over the last two years of interacting and working within a marketing department as a seasoned technical leader, I've developed strategies to enhance collaboration, boost cross-team communications, and promote project success.

Below are the steps to take.

Set clear objectives

Since both development and marketing play vital roles in implementing user experiences that drive business goals, the contributors in question must share clear, common objectives, e.g., projected sales, number of service signups, and brand messaging.

Reaching those goals sometimes requires both technical and marketing-driven activities, such as code refactoring, site-performance boosts, messaging-success measurements, and analytics gathering. Those work streams, whose specifics are highly contextual to the specific job marketers or developers do, could easily cause conflict.

To avoid miscommunication, do the following:

Invite participation from all team members. Involve them in planning sessions, explain the background of the strategies to be built, and ascertain that everyone is on the same page.
Set SMART goals. Create specific, measurable, attainable, relevant, and time-bound objectives.
Plan together. Align schedules based on the teams’ different workflows.

Understand how the other discipline works

A healthy dose of the qualities below is key:

Respect. To minimize friction, respect for each other's operating methods, styles, and process is essential. Besides acquiring an understanding of the various workflows, team members must be willing to compromise for alignment’s sake.
Patience. Be accommodating, thoughtful, and tolerant when explaining processes to the other team. A unified approach like Agile project management can forge collaboration by breaking projects into stages, constantly engaging with stakeholders, and enabling both teams to simultaneously track goals and meet objectives.

Remember, a world of difference exists in how developers and marketers think. Establishing a mechanism through which they can learn about one another's tasks and routines goes a long way in championing collaboration.

Leverage each other’s skills

Developers and marketers contribute unique, value-add skills:

Developers can offer product or technical insights by clarifying why certain code approaches and rendering modes help reach marketing goals.
Marketers can share user feedback, messaging learnings, and test data with developers as support for spiffing up the UI and product features.

Essentially, developers work in the context of the “how,” and marketers, of the ”why.” Both are equally valuable for successful projects.

Make data-based decisions

Data is crucial for measuring success. Developers and marketers play a different role vis-à-vis data:

Developers create technology for harnessing data that marketers need to optimize conversion.
Marketers collect data and strategize campaigns accordingly.

Using analytics tools and personalization engines is instrumental for fulfilling project goals. Ultimately, developers must find a way to integrate “hated tools” so that both teams are happy.

Use the tools that appeal to both teams

Tools that propel collaboration fall into different categories. For example, Jira and Linear are process systems, and Figma and Zeplin are design devices. Other tools are slated for website architecture.

Even though developers love the freedom to choose the tools they prefer to build websites, it comes at the price of abstract interfaces and many open tabs for marketers. As technology evolves, techies must keep up with industry trends without being bogged down by marketers’ tool choices. That’s where headless has failed us: The pendulum of architecture choices to build websites has swung too far. Developers love it, yet marketers hate it.

A digital experience composition platform (DXCP) affords both developers and marketers control of features, content, and the ever-ticking clock. Though technically agnostic, a DXCP—

Helps developers funnel data to a front-end channel of their choice without compromises.
Enables marketers to independently and visually edit content in a no-code environment without having to seek developer assistance.

Faithfully perform the paramount steps

By setting clear objectives, understanding each other's processes, leveraging each other’s unique skills, making data-driven decisions, and adopting tools that cater to both parties, marketing and development teams can cooperate smoothly, eliminate roadblocks, and deliver phenomenal projects. With the right strategies and mindset, the sky's the limit for the potential of those high-performing teams to achieve exceptional results.

Check out Uniform DXCP, on which developers and business teams can access all the tools they need to deliver well and fast.

How to get your webcam to look decent in a few simple steps

Tim Benniks 🗼 — Mon, 20 Mar 2023 13:01:35 +0000

If you have used a webcam before you know what it means to look like shit on camera. Even the most expensive consumer webcams produce a “meh” result. So why do webcams suck? It’s their design. The webcam form factor has a bunch physical challenges that limits them from producing a good looking picture.

Beware, the ideas outlined below are based on my experience and are by far not comprehensive or complete. That is not the idea of this post. Someone in the field of cameras will probably pick this apart on details. The global ideas stand, however.

Why webcams suck

Let’s get a bit technical. Almost all webcam image sensors are somewhere between 1/4" and 1/3" in size and they have a crop factor of around 7. Crop factor is a term that describes the difference between your camera’s sensor size and a traditional 35mm film frame. In the case of a webcam’s image sensor size and its crop factor a normal 18mm lens is the equivalent of a 126mm zoom lens. I might be a bit off here. The idea is that the crop factor plays a huge role.

A webcam tends to be positioned around 40cm (1.3 feet) from your face. Due to the high crop factor an extremely wide angle lens is needed to get a good visual at that distance. Think about it. If a 18mm lens is the equivalent of an 126mm lens it means that something we consider normal on a SLR camera is extremely zoomed in on a webcam. So, we need to zoom it out. BY A LOT. To do that, we use a wide angle lens.

The problem is, the wider you go, the less sharp the picture gets. If there wasn’t enough against the webcam form factor: the lenses in webcams are generally cheap and shitty. The webcam’s physical limitations make it terrible in low light situations. Even with studio lighting the image can appear grainy.

There are more issues. Yikes.

If you check out high quality content there is always a nice bokeh effect. The more light a lens can capture (aperture) and the bigger the image sensor, the more bokeh you can expect. Bokeh is awesome, everybody needs bokeh.

In webcams autofocus works from about 1cm until 60cm (2feet). After that everything is always sharp. Webcams have a shallow depth of field. No bokeh. Not even close.

Combine a small sensor, a crappy wide angle lens and a shallow depth of field and you have the average webcam. A 200 euro webcam isn’t that much better than a 50 euro webcam. Sad but true.

But why does my phone camera look so good?

A real camera or a phone have much more computational power. The camera on a phone is almost its main feature nowadays. It’s where all the advertisement dollars go. Phones have bigger sensors, better lenses and sometimes even a dedicated hardware chip just for image processing.

Most webcams also have some sort of processing power on board but it always kind of sucks. It mainly compresses the video feed so it’s streamable over the USB connection. Due to the compressed stream the PC hardly needs any processing to show the video. You have no access to aperture, shutter speed or ISO though.

You can only post process the signal. But the damage is usually already done at this stage.

But why aren’t there any amazing webcams out there?

It’s definitely possible and there are niche brands that build 1000 euro webcams. But if you have to spend that much, why not just buy a real camera? The actual market for webcams is likely just for conference calls, skype with family (if you don’t have a laptop or a phone) or content creators who are starting out. If webcams get too expensive, nobody will buy them.

You can make it work however

In this post I’ll outline some tips and tricks you can apply to make your webcam look better. All techniques described below are applicable to any sort of camera setup. If you have a proper camera it just works better. We will be covering two topics. Lighting and post processing settings.

Lighting

Lighting is by far the most important part of your setup if you want to make your webcam image look good. As mentioned before, webcams are not great in low light situations. To overcome this limitation you have to blast the filming subject (you) with light.

Light temperatures

There are different types of light that need different white balance settings. Generally light bulbs are yellow and sun light is blue. When combining both you can green a green overtone. White balancing your camera in software is very important in this case.

I’d suggest not to use sunlight as it is hard to control. Close your blinds and go for light bulbs or LED lights only. There are many cheap options out there. Most lights can deliver different color temperatures ranging from 2500 (sunset) to 10000 (blue sky). Generally 5500 is considered noon daylight.

Shadows & diffusion

Light can be cast in different ways. Harder shadows and lighting from the top is used to depict movie villains for example. If you want an dramatic look, use hard shadows and light yourself from one side. If you want to look more mainstream use softer shadows and light yourself from more angles.

To generate softer shadows you have to diffuse your light. The more focused a light source is, the harder the shadows. The more diffusion is added, the softer the shadows. I personally use a couple of cloths of white t-shirt fabric stretched over my lights. Obviously there are also more professional ways to diffuse light but these are not available to everyone.

Your light setup

Now that we have our color temperatures and diffusion out of the way, let’s talk about how to set up your lights so you are lit properly for the webcam. If you have very limited options, just put a big light behind your camera and blast your face with white light. This will give you a 100% quality boost over having no lights.

If you have a little bit more flexibility I suggest using a three point light setup. The three point light setup is considered industry standard and will generally give you great results.

The three point light setup assumes you have a “key light”, a “fill light” and a “hair light”.

Key light: This is the main light source. It shines directly on the subject, usually from the front right or front left. It establishes the overall look and feel of the shot.
Fill light: The fill light provides balance to the key light by “filling in” the rest of the subject’s face with softer light. It should be positioned to the side opposite side of the key light.
Hair light: Also called “back light” or “rim light”. This light creates a flattering rim of light around the subject, separating him or her from the background.

This is how to set up your lights. To start turn all lights off so you are in a dark room.

Turn on your key light. Your key light is the brightest light in the scene and the one that creates the overall feel of the shot. Adjust its brightness to your liking. You should position the key light in a relatively high spot to reduce shadows on the face.
Add your fill light. The fill light should be on the opposite side of the key light, but still in front of the subject. Don’t make the key and fill lights symmetrical. The fill should be at the subject’s face level, and should get rid of any remaining shadows. The intensity of the fill light should be about half that of the key light.
Bring in the hair light. The back light separates you from the background. It can be placed anywhere behind the subject. Make sure to keep it out of the shot. Angle it down from a high position to achieve a sharp outline on the edge of the subject.

If there are lights behind you, make sure these have a very low intensity so they do not distract from you, the subject of the shot. To make the shot more interesting you can add some fun colored lights behind you as long as they are not too distracting. This is obviously not needed but it’s a fun thing to add.

Application settings

We are almost there! Let’s tweak some settings to make the camera quality appear much higher.

Turn things off.

I have a Logitech webcam. This camera comes with a little control panel that allows for some post process tweaking of the camera feed. If you are well lit you can turn off a bunch of things in this interface. First of all, keep the settings for brightness, contrast, saturation and sharpness at the default. We will fix these at a later stage.

Set the white balance on a fixed setting and make sure it is not set to auto. For my setup a white balance at around 4000 works.
Make sure to turn off Backlight compensation and Gain. We do not need these as we are well lit.
In the next tab make sure exposure is set to “auto”. If you attempt to expose yourself manually with a Logitech webcam all hell brakes loose. The image either looks like crap or your framerate will drop significantly.
Make sure to turn off Low Light compensation. There is no need for this as you are well lit.

Color correction

I use OBS, which comes with a great plugin to color correct the video feed from your webcam. The smallest adjustments give a great result. Stay subtle with the changes and your video will look a lot better fast.

LUT

Instagram filters can make a simple picture of food look like a very fancy picture of food. You can use these same kinds of filters on webcams too! It’s amazing what a little cosmetic tweak can do to your video quality. The filters I’m talking about are called LUT. LUT’s are generally used in the professional film world to color grade a movie.

LUT’s are simple, easy-to-use filters that can be applied directly into OBS allowing your webcam presentation to become brighter or more cinematic. For a great free pack of LUT’s go here: https://gamingcareers.com/guides/30-free-webcam-filters-obs/

You can try one more thing

If you have a cheap camera with a shallow depth of field and your lights are set up well, you can use a program called xsplit vcam to create a software bokeh effect! Beware, you need a relatively strong graphics card and the lighting needs to be spot on. Also, the program is not free.

That's it

This is the result I got after a bit of research and tweaking settings.

Why I didn't run the 2016 marathon

Tim Benniks 🗼 — Sat, 18 Mar 2023 22:52:37 +0000

After four and a half months of full on training I’ve decided not to run the Amsterdam marathon on October 16th 2016. I’ve learnt a life lesson about the balance between the load and capacity of the body while training for a marathon.

tl;dr

No matter the dedication to training, a great food plan or sheer willpower, circumstances and external stressors will make your body say stop at a certain point. If the load is higher than the capacity for too long the body will get pushed too far and won't be able to cope with the added stress.

The Load-Capacity Model

The Load-Capacity model was created in 1990 by A.T.M Bernards and L.H.A Hagenaars, two Dutch physiotherapists. The MDBB (Dutch abbreviation) model is meant to be a conceptual model for physiotherapy. This is one of their publications from 1999. They created this model to add the biopsychosocial element to physiotherapy treatments.

I just want to caveat that even though there is some merit to the claims made in this post, the Load-Capacity model is generally taught at physiotherapy school, most of the conclusions I ended up with are anecdotal. I’ll be using the Load-Capacity model specifically for my personal experience so my writing will be somewhat one-sided.

On the physical side, the Load-Capacity model is a key concept in preventing and managing running injuries. It is all about understanding the balance between training load and the body’s capacity to handle that load. In a nutshell it’s a case of working within your limits and not pushing the training beyond what the body can cope with.

Then there is the mental side. External stressors will also impact the balance between capacity and load. If you keep the load the same but your capacity goes down due to grief or work stress, the body will be pushed over the edge of what the it would normally tolerate.

The load-capacity balance is different for everybody and could also change over time. As it did for me. I upped the load in a steady way by training for the marathon but my body’s capacity went down due to external stressors which I wasn’t able to identify. For one, I have a thick skull but I also wasn’t used to the fact that my body would tell me to stop. I could do whatever I wanted to it without stretching or any kind of warm up. If I twisted my ankle the pain would go away in a day.

This year I was always stiff and I had to concentrate way harder to stick to proper form. Suddenly I got little pains like plantar fasciitis and an inflamed Achilles tendon. Even after stretching out my hips and calves it felt like I was running on stilts. The pains and stiffness started two months into training. Four months in, I started to get extremely tired, I developed a rash and I my IBS started to play up way more often. I also got sick after doing longer runs at marathon pace.

The things I just described start to happen when the load is surpassing the capacity of the body for a length of time. I slowly got overtrained. As my body could normally handle anything I threw at it, I was a bit oblivious towards the symptoms of over training.

My sweet wife is a physiotherapist and saw me coming from a mile away. Classic. I needed my wife and many of my peers to tell me that I was over trained. The cause was a combination of training and external circumstances.

This is what happened

I started off well and I was determined to make less mistakes in the preparation this time around. I had plans to have my diet in check from day one. I would go to the gym as well. Next to this I kept a record of everything. Training sessions with Strava, sleep analysis and heart rate with Sleepcycle and food and weight with MyFitnessPal.

This year I decided to go for a training plan which let me train five times per week. Of these five sessions only three where running. The other two were either biking or a gym session. Running only three times per week meant that I could be flexible with the days as I sometimes work nights or have social events to attend. The plan had me running more miles each run but at a slow pace.

The first couple of months everything went well. I actually beat my personal bests on the 5km and 10km quite easily.

Check out this Strava run and this one.

And I also found back my love for cycling. I bought the cheapest bike with the best reviews. It has a Microshift group set which isn’t as precise but works very well if maintained properly.

Two and a half months in, things started to feel a bit painful, especially after running. I realise now that the stress I experienced outside of training impacted my capacity to handle the increased training load.

A couple of things happened at the same time. We had a cancer scare in the family for which I went to Amsterdam for a while. Things are better now but I’ve had a lot to worry about. Right after I came back to Paris my wife miscarried. We’ve been trying to have a baby for a long time and each time it fails it’s like getting hit in the face.

On top of these two things I found out that I have IBS. I’ve probably had it for a long time but it started to flare up around March this year. I’ve been trying to find the right diet and it’s not easy.

It seems that the absorption of nutrients isn’t working well due to the inflammation in my gut. I had to try to eat less foods that contains FODMAPs so that my insides would relax a bit. Having a constant belly ache and bad sleep as a result does not help the capacity of the body to deal with an increased training load. I made a little tool to see which foods are allowed on the low FODMAP diet.

Funnily enough I felt quite good during runs. Well, except when it was hot. I hate warm humid weather and have I trouble training in it. It was usually after the runs that I would suddenly feel the pain my body was in. Willpower is an amazing thing. I think I could actually run the marathon on sheer brain juice tomorrow. It would do horrible things to my body though.

The run below seems to have gone very well but I got sick after and couldn’t train for a week. My whole body ached and I slept all weekend.

Check out this Strava run.

What I have learnt

It took 20 years to start enjoying sports. I lost a lot of weight and got hooked. I could throw anything at my body and it would bounce back. Now it doesn’t and I have to accept that. This summer of training thought me to be humble and to listen both my peers (my wife mainly, as she is always right) and my body.

Not running this race was a hard decision for me as I always stick to the challenges I set for myself. I’ve decided that feeling good is more important than running a marathon. I’ve done it once before and have proven that I can do it. My body can deal with running but it’s not comfortable doing it. I have my build against me. I’m going to focus on being flexible and strong. I’ll be running shorter distances and I’ll be cycling way more. Also, I’m going back to the gym to do what my body was build to do. Lift iron. I might even try yoga…

Some Numbers

I ran 483.4km over 51 runs with an average pace of 05:40
My average distance was 9.5km per run
I went from 96.1 to 92.9 kilos
I slept 8h 20m a night on average
I ate 2258kcal a day on average
I took 9565 steps a day on average
I had an average resting HR of 63.5bpm
My average food macro balance was 62.2% carbs, 16,2% fat, 21,5% protein.

The 2015 Paris marathon

Tim Benniks 🗼 — Sat, 18 Mar 2023 22:45:48 +0000

Exactly one year ago, when we had just moved to Paris, the marathon passed by our apartment in Rue Saint-Antoine. Seeing all these people swooshing by impressed me so much that I signed-up for the 2015 marathon on the spot. The goal was set, the easy part was over.

I gave myself five months to conquer the beast. 42.195 kilometres. After running on and off for a couple of years it was time to get serious. As I work for AKQA I naturally chose to train with the Nike+ app and all the related products.

Nike’s marathon training program was brutal. Even at the rookie level it made me run five times a week from the get-go. After living the good life for eight months in Paris both my endurance and cardio vascular strength were shit. It’s safe to say I was happy that the distances were short for the first couple of weeks.

I didn’t have any specific goals in mind, just general stuff like: “I want to get a bit lighter so the running gets easier” or “I’d love to set a new half marathon personal best at one point”. I trusted the rigorous training schedule would get me there eventually.

It didn’t. The training was so intense that I had skip workouts and I had to start experimenting with food to figure out how I could get my legs ready for the next run. My body could just not cope with the sheer amount of kilometres I had to run each week.

January

After two months of pain I had finally found a balance. Turns out that eating super low fat and high carb was the best for my recovery. I was basically eating according to the 80/10/10 principle. 80% carbs, 10% fats, 10% protein. I’m not preaching this way of eating, it was just great for me.

To achieve eating this macro ratio I had to cut out all animal products. If I ate too much fat on a rest day, like when you go out to dinner and you don’t want to be the asshole who can’t eat anything, I would have heavy legs the next day.

I started eating copious amounts of fruit, rice, pasta, quinoa and veggies. My brain started functioning ten times better and I didn’t even think about coffee anymore. January was awesome. I ran pain free and the long distances started to become enjoyable. Good times. I ran 147km that month. This might not seem a lot to seasoned runners but I came from ~50km a month. I started a new chapter in my running career.

February

We went on a ski trip in the beginning of February. I was an amazing holiday with loads of skiing, good food and laughs. I did some workouts in the gym and a proper mountain walk. I really hoped I hadn’t lost my running gains.

The first Monday back I had a nasty cough but decided to at least try my fast 8km run I had planned for that day. Bad decision. Over the course of the week I developed a bronchitis and both the doctor and my wife (the boss and a bad ass physiotherapist) forbade me to run the following two weeks.

I slept a lot and kept on eating well and as soon as the illness lifted I started running short distances again. I cursed my way through the first week. Even though the running hurt, my pace was still fast.

In February I ran the awesome amount of 37.98km over five runs. The last of the five was the most painful 15km run of my life. We’d strolled around “Le Salon d’Agriculture” for three hours before. We tasted wines and tried cheeses. I had forgotten to drink any water. Rookie mistake. Lactic acid legs for days!

March

Back to awesome. I ran 181km in 4 weeks. An absolute record month in my book. I had an amazing run in Amsterdam on which my whole family followed me by bike. I also ran personal bests on the 5km, 10km, 15km and 21km. I decided to drop the Nike+ program as I had missed too much the month before. This was a smart move. The Nike+ program would have burnt me out.

I had been in training for 4 months by now and I had been sick the month before. The exhaustion was setting in a bit. I didn’t particularly feel it in my legs, but I started having problems staying focused on evening runs. One time I had to jump aside while a policeman was arresting someone. I flipped my ankle and had to walk home for an hour.

I felt stupid for being distracted. Even though I had super light shoes without much cushioning I stopped being in touch with the ground I was running on. Sounds like I’m a hippy aye? It’s a runners thing.

April

Only two weeks left. I did a 27km run in a very busy, rainy and hilly Paris. After that I was so exhausted that I decided to start my tapering period a week early. I thought I’d hurt my feet too much and suddenly got very nervous. My marathon veteran colleagues told me this is normal and I should just chill out.

I only ran a handful of runs up until the big day. The thing I liked most about the tapering period was the carbo-loading. My food intake doubled in the week before the big race. #CTFU. I felt amazing and started dropping weight. I should have eaten much more the past four months.

D-DAY

I was so nervous I hardly even looked at the enormous amount of runners around me. I was standing on the Champs-Elysees with 50.000 other athletes. This was going to be the most epic challenge of my life.

The first bit felt like heaven. Especially because my mate Chris had just given me an amazing pep-talk over the phone. The Champs Elysees was mine and mine alone. Turns out I clocked the first kilometre at a 6:12 pace. Slow as fuck but a nice start to a long day. After that I slowly picked up the pace to a nice average between 5:25 and 5:35.

Around the 7km point my awesome friend Henrike spotted me from the sidelines and joined me for about 1.5km. We picked up the pace and race had properly started.

It was super warm so I drank water every chance I got. My training had been during winter time so I was used to running with a maximum temperature of 10 degrees celcius. Even though it was warm I ran a great half marathon (for me at least, 01:52:34).

The heat had silently sneaked up on me and at kilometre 22 the wall hit me like a hammer.

The Wall

The wall is really the biatch people say she is. I could not even put one foot in front of the other anymore. It took me half an hour to stumble to the next food station. It took 35 minutes to run 3km. I had some water, a sugar cube, a GU gel and a slice of mandarin. Obviously this was way too much so I felt sick for the next 5km. My brain was telling me to stop but I just couldn’t let go.

In the following kilometres it didn’t get any better. I managed to find a happy medium in between running and walking. My nike+ app was all over the place and wasn’t accurate at all anymore. At one point I just turned it off and upped my Spotify volume. The next song was by Motörhead and I felt my heart skip a beat. The race was back on.For 2km.After that I went back to my previous state.

During the five months I trained my wife had always been there for me. She gave me tips and picked me back up when I had hit a low point. When I saw her at kilometre 30 I couldn’t be happier. I gave her a quick kiss and a smile and I was on my way again.

Just before hitting the Bois de Boulogne I became captain slow. I was having a real rough patch when I heard people shout my name. These people were Marie and her son Adrian. It’s great to have the support of your friends. It made me start running again. As it turns out, my wife had been sending loads of photo’s to my family back in Amsterdam. They had been following my every move.

Bois de Boulogne

Bois de Boulogne was truly intense. They call it “the march of the death” and rightfully so. It starts at kilometre 35, there are hardly any supporters and it’s mostly uphill.

I did the “pain shuffle” for the last 7km. The pain shuffle means that you can’t really bent your legs anymore but you still run. In my case, stumbling without falling. I ran from km sign to km sign without even hearing my music.

When I saw the 40km sign I decided to not walk anymore and I did whatever it took to make that happen. At kilometre 41 I noticed that a lot of the faster runners were coming back to show us their medals and cheer us on. There was an amazing feeling of companionship in the pack of runners.

At kilometre 42 I saw the finish AND my wife at the same time. It was finally over. I didn’t even bother to sprint.

It took me four hours and forty six minutes. A total pain train. While riding home on the metro I felt a little shit because I walked so much. Should I have gone deeper? But while writing this piece, pride is taking over. I actually did this. My first marathon in the heat in under five hours. #putain.

Some Numbers

I ran 615.14km over 67 runs with an average pace of 05:42
My average distance was 9.18km per run
I went from 95 to 86.7 kilos (and lost all gains)
I slept 7h 50m a night on average
I ate 1840kcal a day on average (probably not enough)
I took 12609 steps a day on average

My Fitness Story

Tim Benniks 🗼 — Sat, 18 Mar 2023 22:39:46 +0000

From fat and sick to slim and happy

Aside from a short period in high school I have always been a chubby kid. When I lived at home my mom made sure I didn’t go overboard with food. She stopped me here and there when needed and always made sure we had healthy food on the table.

After highschool I started living on my own and became a lot more active as a musician. I got used to a very burgundian lifestyle and started eating all kinds of junk. The free drinks for musicians also didn’t help.

I have always been interested in muscles and posture but never had the discipline to change myself into something I liked. I quickly turned into a lazy musician. Beer and fast food, either before or after a gig, were the norm. I didn’t know any better and ate highly refined foods containing a shitload of ingredients with long and incomprehensible names. Looking back it’s unbelievable how little I knew about stuff I put in my body.

Being fat was always in the back of my mind and it nagged at me. When I reached 120kg I felt horrible and knew change was needed. I was always sweating, tired and out of breath. I had high blood pressure and was often feeling ill. Diabetes type 2 was creeping up on me.

Even after this turning point I was still completely inadequate at sports and I didn’t have any discipline. I didn’t even know how to properly contract my muscles to lift something. I had no body sense at all.

I asked my mate Chris to help me out. He was (is) a complete legend and instantly jumped at the chance to help a friend. We started doing his “half hour of power”, lifted weights and ran as often as possible.

Well, I tried.

I had excuses. Many of them. “But I had a gig last night” or “I’m still too sore from last week”. I was a complete pussy and it must have frustrated Chris. But he was strong and pulled me through.

As I finally saw some results I overcame my disciplinary problems step by step. I changed my diet and the fat started coming of quickly. I even gained some muscle.

I started researching and a whole world of bro-science opened up to me. I did programs like P90X, 5x5, and 4-hour body.

The thing that helped me most was my Facebook activity. I posted my weight daily. People would respond if it went up or down and it kept me motivated. This was the first time in my life peer pressure actually had a positive influence on my state of mind.

In April 2014 my wife and I moved to Paris. At that point I was vegan for half a year and I was at my lightest weight since I started training. We had to deal with different stress factors when we arrived and I let go of the strict livestyle a little and gained some weight again. The cheese, wine and French baguettes are too awesome not to enjoy. In January 2014 I got up to ~95kg and Paris had officially turned me into a croissant.

But I wasn’t a croissant for long. I started lifting some weights again and slowely started to get back into it. When the marathon passed by our apartment in Rue Saint-Antoine in April 2014 I signed up on the spot. I became a long distance runner over night. New goals were set, and crushed over the proceeding six months.