DEV Community: Bryan Robinson

Does our technology still work for us?

Bryan Robinson — Tue, 04 Feb 2025 14:35:48 +0000

“Google’s search algorithm is geared to find the best content and UX for their users. Write the best content that helps people accomplish their tasks, and you’ll succeed in an SEO race.” - Me, circa 2012

This was solid advice during that era. I gave it to many marketing and website clients.

Write for humans and the algorithm would reward you. Make your content useful, and the algorithm would reward you. Have the best UX, and the algorithm would reward you.

The tool worked for us.

It was a symbiotic relationship. Google’s nascent ad functionality benefited from being THE place to find information. Users benefited by quickly finding what they needed. Websites and content creators benefited with larger audiences, focused and happy users, and a clear-cut path toward success. We all got what we needed out of the relationship.

In other words: the incentives matched for everyone.

AI Leaders want humans to work for the tool
The symbiosis was always a delicate balance. If you study nature, you’ll know that any symbiotic network is always a delicate balance. Drift too far in one direction or another and risk toppling the entire structure.

Tech leaders no longer seem interested in the balance. They seem to want humans to work for the tools.

“It would be impossible to train today’s leading AI models without using copyrighted materials…” - Sam Altman CEO OpenAI.

“Platforms, tools or frameworks that are hard for large language models (LLMs) and agents to use will start feeling less powerful and require more manual intervention. In contrast, tools that are simple for agents to integrate with and well suited for the strengths and constraints of LLMs will quickly become vastly more capable, efficient and popular.” Mat Biilman, CEO Netlify

Let’s break down a few propositions from these quotes.

Altman’s meaning is relatively simple: “The tool I’m building won’t work without your content. All of your content.”

Biilman’s quote is a bit more nuanced, but no better. In its essence, it says the following:

Agents and LLMs need to be able to use your site or tool
Sites and tools should be made easier for bots to use to be “more powerful” to end users
If the tools are more powerful, they will be more popular

Those propositions are stated directly. But what logically follows from those propositions? Two quiet corollaries:

1st Corollary: If the AI tools are more powerful, users won't use your tool; their bot will. Users won’t read your content; their bot will summarize it
2nd Corollary: If users only use their AI tool, and it doesn’t send them to your site, app, or product, the AI tool user won’t be your audience or your user. That person will be captured in the AI company’s ecosystem (💰, 👀, 🕦)

Either way, the message is clear: Give AI your content. Give AI access to your tools. And, in the end, let the agent and AI company take credit for your work.

The incentives don’t match.

SEO worked for us… until it didn’t

I worked in newspapers for the first six years after I graduated college (2006-2012). To put this time period in context, Google’s search algorithm still ranked partially based on the keywords meta tag for half that time (what a time to be alive… a time when your article on technology would have keywords about Britney Spears just to get noticed…)

I grew very familiar with the nature of SEO while working on the web for an organization which made money off the discoverability of its content. We were being given millions of views across our news outlets each month via search (specifically Google search). Do you know what the takeaway from our executives (and other executives in the industry) was?

“Google is stealing our content!”

Young and idealistic about the internet, I couldn’t handle that. It was, honestly, ridiculous. We were literally generating revenue from the views we got. Google was bringing us an audience for each story we published.

My, how the times have changed me…

In today’s ecosystem, I’d be forced to agree with those executives. Forty-year old Bryan is mature enough to admit that, but it’s still painful.

Google at the time wanted to make information discoverable (or at least searchable… if you’ve watched my search vs. discovery video, you may know about the distinction). As time marched on, and Google ads became more important (and thus user engagement became more important), Google wanted fewer users leaving the search page.

It started as a boon for Google’s search users. Search for a local restaurant, get a widget in the sidebar (nice and out of the way) with important information like the phone number, address, and even a link to the website. Nice!

But then we got featured snippets… Now, when you search “What is an API?” you get an answer (pulled and quoted from a site) right in the results… with no real benefit to the original author.

Then, we got Google shopping results. I started writing this on a fresh legal pad acquired from a local Walgreens this morning. Walgreens was on my way to the library where I decided to write. I did a quick Google search to check stock. I wanted to quickly find the dedicated page on Walgreen’s site. Instead, I found this:

Yes, the page I was looking for is listed three times, but it’s listed in a confusing mess of six other products. Those other products are from their competitors! All of these posts (including the Walgreens grid results) are sponsored! It certainly doesn’t seem to be working for Walgreens. It seems to mostly be working for the company selling the ads…

It’s harder to get real views. It’s harder to transfer the engagement to the individual. There’s higher competition around products (even in branded search). And all of this before the advent of “AI Search Summaries,” which when launched had no attribution on answers and even now are unclear on a path to getting users to the original sources.

The algorithm once worked for us (both the creators and the users). Then, it became more important for Google to hold the attention to earn money. This made the incentive structure flip.

Our products, our content, our news exists to help Google’s product, not ours. Perhaps those news executives were right…

There’s no way around it: we have to talk about capitalism
In essence, the degradation of this symbiotic relationship can be laid at the feet of capitalism. The balance of power had shifted in the early 2000s, as small companies were able to make money on the web. Largely helped by early Google, but there’s always a tipping point. And that brings us to another issue with the quotes from earlier: in this game, who benefits the most?

The last section on search issues covers one of our capitalistic problem: when multi-billion dollar companies see a way to make more money, it’s hard for them to hold their original values. If we help agents and invest in making things easier for them, who are we helping? The agents are not benefitting. They’re not alive, sentient, or actually intelligent. So who? The multi-billion dollar companies and the venture capital (VC) firms behind them. They get user lock-in and, as we’ve seen with the devolution of Google search, that social contract can be renegotiated.

Let’s move, instead, back to Altman’s quote. We’ve got to give up all our copyrighted material to achieve a great and glorious GenAI world. A world where all the powers of creation are at the disposal of everyone!

Look. Creative work is hard. I get it. I’ve always wanted to be a cartoonist (and an actor… and a novelist… and a film maker), but I’ve never put in the work to get good (or even the effort to get mediocre). I get the allure of being able to type a prompt and get an artifact back: Comic art, landscape painting, cool background music, amazing video of an imaginary cityscape.

But here’s the thing about capitalism and creativity: businesses don’t want to pay for creative output. Ask anyone who has tried to make a living as a commercial artist. Pay is terrible, hours are long, and the work is constantly devalued.

Imagine the joy, then, when investors learned they could do away with those tiny payments to those pesky artists. That’s where the VC fervor and hype comes from. Not giving these tools to artists, but instead giving them to low-paid prompt engineers to lower the cost of creative output.

Oh, and let’s not even mention the software development side of the “Creatives” industry. We’ve been making too much money for too long. Wouldn’t it be better if a founder, investor, or product manager could just make “the next big thing” without a team of expensive engineers? $10 million dollars in seed funding right away!

But honestly, that’s not the worst of it. The worst is that creation is a core trait of humanity. We seek to create. As we learn and level up our creative skills, we often find bigger and better applications for them.

The AI scheme is to take the creative tasks away from humans so that we can be “more productive.” And while that may be an economic boon in the short term, it’s a real problem long term as the creative skills of humanity are slowly removed.

“That’s hyperbole!” I hear some of you cry (or at least, I hear the AI advocates cry).

Maybe.

Though, maybe not…

AI’s hidden cost on our brains

It’s perhaps too early in the current technology cycle for there to be definitive studies on AI’s affect on humanity. Even still, we can look at something very similar.

There have been many studies on “The google effect.”

At its essence, the google effect says that by offloading our data retention and recollection to the internet, our brains are worse at retaining and accessing information.

“Moreover, when people search for information on the Internet while working on the Internet, they are more likely to use the Internet rather than their brain the next time they encounter that issue, and they retain pertinent information in an interesting way: they remember the Internet address where the pertinent information is stored (e.g., domain name, database, etc.). People who have searched the Internet for a solution to a problem, for example, will remember the website where they found the solution more vividly when they encounter the problem again (50), even if they have forgotten the precise essence of the problem for which they were searching.“ - NIH Research paper

“People are more likely to return to the Internet and repeat the search process when confronted with a similar issue if they remember the location where the information was saved. Moreover, people’s perceptions of findability roughly predict the amount of time it will take them to find the information they need on the Internet, which increases their reliance on it laterally (38). Moreover, when searching for solutions on the Internet, rapid responses (answers that are obtained more quickly) are more likely to be convincing. People feel more confident when working in an Internet-accessible environment, and “Google effect” is stronger for those who have previously used the Internet.” - NIH Research paper

That’s certainly not great. We’ve modified our neural pathways, and not for the better.

While not yet studied, it stands to reason that if we outsource our artistic, writing, music, and even coding skills, the parts of our brains that help in creation would slowly function worse and become dependent on those tools (in the same way they have with Google search).

Definitely great for the person who sells what we become dependent upon. Definitely bad for core elements of our human nature.

“In addition, by examining the potential costs and limitations of the Internet, individuals are in a better position to develop and modify the technology so that it is potentially more productive, less disruptive, and more consistent with the everyday goals and functions of human cognition.” - NIH Research paper

The study also says that the more people understand this, the more informed they are, the better the decisions they can make for themselves. Since learning this, I even attempt minutes of thought to remember information rather than do an immediate search. Better to start rebuilding those synapses, after all.

But those sorts of solutions assume people are able to come to that understanding. The companies working on this have billions invested… Kind of puts the use of “dependent” in perspective…

Conclusion

My point in all of this is that when people start telling you that you need to work for your tools instead of the other way around, you need to DEEPLY inspect that.

We have very recent examples of how this has worked. It always starts at “Democratizing” powerful things (creation, development, writing, videos) and, so far, ends with the most benefits in the hands of large companies. When that happens, we lose the democratization, but with AI, we run the very real risk of losing the skills that make culture, the skills the benefit us all, the skills at creation.

I hope we don’t let them take that from us, just to make us “more productive.”

Pay no mind to this, this is just a test

Bryan Robinson — Fri, 25 Oct 2024 18:02:34 +0000

Just a test, y'all. Nothing to see here.

Convert a Hygraph Next.js project to Next.js app directory

Bryan Robinson — Mon, 11 Sep 2023 04:00:00 +0000

In late 2022, the Next.js team launched their next stable version: Next.js 13. While this update came with a lot of improved functionality, one new feature is set to redefine the way you build with Next: the app directory beta.

The app beta is not used default. It needs to be enabled and can then be incrementally adopted. In this article, we're going to take a look at the new app structure and convert an existing Hygraph project to this new structure. We'll take this step by step and see how incremental adoption really works.

Required Knowledge

A basic understanding of Next.js
Basic knowledge of GraphQL
Basic knowledge of Hygraph

Why the app structure?

The new app directory structure isn’t just a reorganization of your project (though it is, and that reorganization feels powerful). This new methodology utilizes React Server Components to bring many new features and mental models. With Server components, a developer can do their business logic in a React component that doesn’t need to be sent to the client. This allows for a lot less JavaScript to be sent to the browser. If you have frontend needs, you can then use client components that get sent individually to the browser. This should reduce your bundle size down to a more manageable state. Just the code you need for interactivity.

The overall data fetching model has shifted, as well. Next has extended the native fetch() method from Node and the browser APIs and has added additional caching and deduplication functionality. This means you can create requests for data in various files, but the request will only fire to your API once. Fetching your blog posts to create a list on your homepage and to create the blog page list? Now that’s 1 API request, despite writing the code in multiple places. This gives a lot of developer convenience while creating better build and serve times.

There are even more new and improved features, but to use them, we need to be able to upgrade our project to use this new structure. It’s not as simple as moving your page files into the app directory, so let’s dig in and get things updated.

Setting up a Next.js 13 project to work with the app directory

To start, we need a Next.js project. While this process is possible with any Next project using data fetching, let’s start from our simple Next example from the hygraph-examples GitHub repository. Run the following commands:

npx degit hygraph/hygraph-examples/with-nextjs with-nextjs
cd with-nextjs

Before we install, we’ll need to update some dependencies in the package.json file. Let’s upgrade Next to ^13.0.0 and remove the react and react-doc dependencies.

Your package.json should now look like this:

{
  "name": "hygraph-with-nextjs",
  "private": true,
  "license": "MIT",
  "scripts": {
    "dev": "next",
    "build": "next build",
    "start": "next start"
  },
  "dependencies": {
    "graphql-request": "^1.8.2",
    "next": "^13.0.0"
  }
}

Now we can start the development server by running npm run dev. Immediately on loading the local version, we’re presented with the first update. Since this was previously not running Next 13, the Link component is structured wrong. In Next 13, we no longer need to have an anchor tag inside the Link component. This is a great update, but we need to change these references. The only location the Link component is used is the homepage in /src/pages/index.js. Open that file, and remove the <a></a> tags to get the site to run

// Old
    <Link key={slug} href={`/products/${slug}`}>
      <a>{name}</a>
    </Link>

// New
    <Link key={slug} href={`/products/${slug}`}>
       {name}
    </Link>

Now that the site runs, let’s update from the Pages directory to the new app directory.

Converting from /pages to /app

Before we can convert to the app directory, we need to let Next know that we’ll be using this experimental feature. To do that, we need a configuration file. In the root of our project, let’s create a next.config.js file. Inside that file, add the following basic configuration.

/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    appDir: true,
  },
};

module.exports = nextConfig;

From there, we can create our app directory. Inside the src directory, add an app directory. We’ll be moving each of our routes to this directory. The nice thing is that each of our older routes will continue to work as we make these changes, since both directories can work at the same time.

Creating the root layout component

One of the first big changes to the overall structure is the need of a “root layout.” This will be the scaffolding of Markup for all pages. This can start very simply, but have any global information that each route will need. The RootLayout function accepts a children object. That children object will contain the Server Components that we’ll add via each page we create.

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

With this layout, we can now add our first page.

Adding the homepage

Instead of the index.js convention of the /pages directory, each page in the app directory will be named page.js. In the root of the app directory, create a new page.js file. This will be our homepage.

Once you create this page, Next will thrown an error in the console. There is now a conflicting route: /src/pages/index.js is the same route as /src/app/page.jsx. For now, rename /src/pages/index.js to oldIndex.js. We’ll delete this file later, but this file is the blueprint for our new file.

Once we rename the file, we get a new error. The page.jsx file is not exporting a React component. In fact, it’s exporting anything, since it’s blank. Let’s fix that and export a simple React component with an h1 of Products.

export default async function Page () {
    return (
        <>
            <h1>Products</h1>
        </>
    )
}

Now the homepage should have the H1 instead of the product list from the old homepage. Let’s get the list of products back.

In the old index file, we export a function called getStaticProps to get and pass the data to our page component. In the new structure, we don’t need to export anything or name things in any specific ways. Instead, we can create a regular async function to fetch our data.

Before our Server Component in the new page.jsx file, create a new async function named getProducts. This run a fetch request to the Hygraph endpoint for the project and return the products array. We can then run that function in our Server Component to loop through the data and display a link to each page.

import Link from 'next/link';
const getProducts = async () => {
    const response = await fetch('https://api-eu-central-1.hygraph.com/v2/ck8sn5tnf01gc01z89dbc7s0o/master', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'Accept': 'application/json',
        },
        body: JSON.stringify({
            query: `{
                products {
                  slug
                  name
                  id
                }
              }`
        })

    })

    const {data} = await response.json()

    return data.products
}

export default async function Page () {
    const products = await getProducts()

    return (
        <>
            <h1>Products</h1>
            <ul>
                {products.map(product => (
                    <li key={product.id}>
                        <Link href={`/products/${product.slug}`}>{product.name}</Link>
                    </li>
                ))}
            </ul>
        </>
    )
}

A few things have changed between our old version and new.

Since we’re not using getStaticProps, we no longer need to structure our return in a specific way. Instead, we just return back the array of products
Using fetch instead of GraphQLRequest. By using fetch, we allow Next to cache the information and if we execute an identical fetch later, it won’t make a separate call, but instead use this data

Once you save this in, we have a functioning homepage. These links even take us to the pages associated with our old dynamic routes — since /app and /pages can work incrementally. That could be a fine stopping point, but let’s convert our dynamic route over, as well.

Converting the dynamic products route

Just like the homepage, we’ll start by setting up our structure. Instead of the dynamic route brackets happening on the file, hey happen on the directory. So the /pages/products[slug].js will change to be /app/products/[slug]/page.jsx. This allows for more flexibility and the ability to add custom, co-located features such as error pages, loading pages, and custom layouts.

Create the new file and add a simple component like we did for the homepage.

export default async function Page() {

    return (
        <>
            <h1>This is a product</h1>
        </>
    )
}

This time, the application won’t immediately error, since the static pages aren’t being rebuilt, but if you restart Next, it will throw the same error as before about conflicting files. Delete or rename the file and we’ll move forward.

The overall structure of this file is significantly different. Just like the homepage, we no longer need the getStaticProps function, but we also don’t need the getStaticPaths either. These are all files that render on the server, so we can move all that information into a single async function that can happen at request time.

The new Server Component gives us a params object that we can use to get the slug for the current route. We can pass that into a new getProduct() function and use that as a variable in our query to Hygraph. This will fetch the data for that specific product. We can then use that in the Markup generated by our component to display the title, description, and price.

async function getProduct(params) {
    const response = await fetch('https://api-eu-central-1.hygraph.com/v2/ck8sn5tnf01gc01z89dbc7s0o/master', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'Accept': 'application/json',
        },
        body: JSON.stringify({
            query: `{
                product(where: {slug: "${params.slug}"}) {
                    name
                    description
                    price
                }
            }`,
            variables: {
                slug: params.slug
            }
        })
    })
    const {data} = await response.json()
    return data.product
}


export default async function Page({params}) {
    const product = await getProduct(params)

    return (
        <>
            <h1>{product.name}</h1>
            <p>{product.description}</p>
            <p>{product.price}</p>
        </>
    )
}

We now have all the pages working together. Let’s take this one step further and add a custom 404 page for any products that aren’t found.

Setting up a custom 404 page

Because of the new app structure, we can colocate all of our relative files. In this case, if we want a custom 404 page, we can add a not-found.jsx template in the /products/[slug] directory.

The file will export a Server (or client) component, and for now, we’ll have a very simple message. In this case, since we’re looking for a product, let’s be specific and say “Product not found” instead of a simple “Page not found.”

export default function NotFound() {

    return (
        <>
            <h1>404</h1>
            <p>Product not found</p>
        </>
    )
}

Now, navigate to a route that doesn’t match any slug in Hygraph: try http://localhost:3000/products/sdlfkjl/

Instead of getting a 404 page, we receive an unhandled error. That’s because we need to tell Next when we know it’s not found. In this case, if our query to Hygraph returns no results, we need to throw a 404.

After calling the getProduct() function, we can check if product is defined and if not, run the notFound() function from next/navigation. This will do a few things for us. It will redirect the browser to the NotFound component and automatically add a "noindex" meta tag to these routes. This is good SEO practice and will keep your site’s 404 pages from being indexed by search engines.

export default async function Page({params}) {
    const product = await getProduct(params)

    if (!product) notFound()

    return (
        <>
            <h1>{product.name}</h1>
            <p>{product.description}</p>
            <p>{product.price}</p>
        </>
    )
}

Now, we have a fully-functioning 404 page!

From here, you can delete the /pages directory and move to working on your app. You’ll still use the pages directory for your API routes, as well as any static routes you want to use, but most things can be used to this new, more-powerful version of Next.

Next steps

With that, we have fully converted our simple Hygraph Next.js example from /pages to /app. At this point, I’d suggest taking look at all the different file types you can create in the colocated directories.

Add a head.jsx file to specify meta data such as title, description, and more for each product page
Add a loading.jsx file for loading page for longer queries.
Add an error.jsx file to handle other error types.

Boost your editorial experience with distributed content management

Bryan Robinson — Thu, 07 Sep 2023 18:09:56 +0000

Tools are only good if users want to use them. If your writers and editors don’t want to use a tool, your content velocity will halt, and your business will suffer.

While it’s easy to dictate a monolithic approach to building your CMS strategy, managing a diverse team with diverse needs in their content generation processes is not always easy. Rarely will one data entry process be the correct one for all those individuals.

It's important to note that while allowing your writers and editors to choose their tools can increase content velocity, it's also important to maintain some standardization of data structures and APIs. Without that standardization, your developer velocity will suffer.

What is distributed content management?

Distributed content management is a pattern where your content is spread amongst the systems that work with that content type the best. Your marketing copy lives in a headless CMS; your product information in your PIM; your inventory in your WMS; your customers in your CRM. Each system handles its own data type better than a monolithic approach could.

Each data type also has its own specific group of editors. These editors are most comfortable in the systems they’re trained to deal with. Forcing an eCommerce expert into a headless CMS or a marketing expert into a PIM just for the sake of having a singular tool doesn’t make sense and will often stifle the teams needed to continue refining and producing content.

The distributed CMS pattern means each editor type can use the system that works best for their data. The data is then all brought together via a federation pattern — here at Hygraph, we’re believers in Content Federation, but any data combination pattern will work depending on your needs.

Why should you care about content velocity?

Among many teams, content reigns supreme. Strong content published regularly is crucial for long-tail leads, thought leadership, and brand growth.

Regularly creating fresh, new content can help keep your audience engaged and growing. While a single strong piece of content can provide high value, each new content piece is a chance to find a bigger, more engaged audience.

Creating a steady stream of new content pieces also allows for a stronger sense of experimentation. In the realm of content, what works one week may not work the next. Trying new perspectives, content types, and tones is important. Experimentation increases the chance of hitting the right tone and perspective to generate high engagement. Not every piece will succeed, which is why it’s so important to be able to create and experiment at a high velocity.

The importance of content standardization

Content velocity might increase, but there are potential pitfalls to a distributed CMS approach that centers on the idea of standardization.

Unified Content Strategy

When you lose a centralized tool, it’s easy to let strategic concerns slip in favor of “getting the work done.” Any content plan needs a solid strategy as its base. While that can be covered up by a strong centralized tool, holes in internal workflows and strategies become more apparent when decentralized.

When crafting a decentralized solution, it’s important to start with a set of standards for how all aspects will be crafted. This goes from things like tags on blog posts and articles to how products are referenced. A strong plan for this content will align everyone in your organization around how these elements should be written, edited, and used regardless of the system they use. A strong plan will also help create a stronger sense of technological standardization.

Technological standardization

While allowing your writers and editors to choose their tools is important, it's equally important to maintain some standardization in your data structures and APIs. This will ensure that your developer velocity doesn't suffer and that your content can be easily integrated into your CMS.

Given three content teams with three separate CMSs, chances are good that your development team will struggle with creating consistent, efficient, and performant applications and sites. Each CMS brings its own data structures, its own API endpoints, and its own content strategy. Those can’t be standardized in their individual applications; a central system must standardize them. Without a standardization mechanism, site and application development will be more prone to bugs, developer frustrations, and blockers.

How a distributed system can help with standards

Each system may be separate, but each can help enforce the standards of the others.

For example, Dr. Oetker, a global food and beverage wholesaler, has multiple systems that need to converge to make their various localized websites, customer data needs, product information, and recipe database.

While all of these systems could theoretically exist within one massive, monolithic structure, each system is better at maintaining the individual standards of its own content than could happen in a singular system.

Dr. Oetker’s product information lives within their PIM. The PIM provides product data for the recipe database and editorial CMS. Customer data is housed in Force.com. Page data and content structure are built in Hygraph, where editors also work. All this is bundled and built with Next.js for 40 localized websites.

A recipe editor won’t be editing the product information. Since that lives in the PIM, it’s completely safe and standardized. Same for building editorial content or pages. All the product information is usable and standardized without having to worry about the individual teams knowing exactly the right information.

We leave room for error or interpretation if we depend on an overall strategy and the humans implementing them in separate systems. However, if the information is pulled directly from the PIM or WMS systems for use in the others, then the standards set by the PIM or WMS team are automatically enforced for all other teams.

Reduced training time and costs

When you dictate the tools that your writers and editors use, you must provide training and support for those tools. This can be time-consuming and expensive, especially if you have a large team. Instead, if you work with your teams and allow them to collaborate and help craft the editing experience, including the tools, you can gain buy-in and drastically reduce training time and costs. When drafting a content architecture and strategy, involving your editors as early as possible can help save on inconsistencies later.

Since your team is already familiar with those tools, they won't require as much training, and you won't need to spend as much on support. This can free up more time and resources for other critical tasks, such as content strategy and distribution.

Setting up a distributed CMS

While a multi-CMS approach may feel like it adds a lot of overhead or orchestration, it’s possible to set this up in a real-world approach with relatively little effort.

In the past, this would have required custom orchestration layers. Whether those were hosted middleware functions, content hub approaches, or an incredibly bloated frontend, it often felt insurmountable. We can easily overcome these deficiencies with recent improvements in the federation world. While tools like Apollo made the development of orchestration layers easier, concepts like Content Federation allow for ease of use for developers and non-technical users to create orchestration layers.

With Content Federation, we can craft a system where multiple data sources come together in a low-code or no-code system and allow for data to be remixed in various ways.

An eCommerce experience

Let's look at an eCommerce store as an example of real-world distributed content management. To create an eCommerce experience, we need product information, blog posts, page content, user reviews, and more. No single CMS provides the ideal solution for all these types of data.

Product information is often best housed in your product information management (PIM) solution — Shopify, BigCommerce, Magento, etc. These PIMs are great for eCommerce data but are notoriously bad for marketing content and are often not fully featured enough for complex inventory management, where a warehouse management solution (WMS) would be a better tool.

When crafting marketing pages, you’ll want a CMS with a solid foundation of both data and content and the ability to combine those in some form of page-building system. We may be biased, but Hygraph is a great solution here.

Finally, your content team may already have a blog in a system like WordPress. Say what you will about WordPress, but it’s still a solid blogging experience. Its page-building experience is weak, as is its PIM experience.

Each of these platforms offers specific perks and deficiencies. Combining all of them together can create a great experience for all editors involved. Let’s make sure it’s also a great experience for developers by combining all of the necessary data into one API.

Using Hygraph’s Remote Sources functionality, we can pull all the data from our PIM for product details, inventory levels from our WMS, and all the blog posts from WordPress and combine them with marketing data and campaigns stored in Hygraph to create a full API of all the data needed to build experiences across multiple channels.

On top of that, any data can be augmented and constructed in new ways. Products can be added to campaign pages. Specific reviews and blog posts can be built into the homepage (and changed by editors). All of this is unlocked when you use a CMS as your middleware.

Recommended Reading
Case study: Biocentury uses Content Federation to bring live data points

Conclusion

Content velocity, content experimentation, standardized data, and flexible site building are cornerstones to crafting a strong brand image and a strong business. If any one of those pillars is weak, the entire system can crumble. You can gain standardized data by forcing your team into a monolithic approach, but content velocity and experimentation will suffer.

By allowing your team to work in the space they’re most comfortable or where the data is best served, you open up a higher level of velocity and experimentation. With the advent of Content Federation, you don’t suffer from bad data or problematic site-building. One standardized API from customized, efficient, flexible sources.

Jamstack is meaningless

Bryan Robinson — Fri, 11 Aug 2023 16:53:00 +0000

Right at the top, let’s say what’s in the title… The name Jamstack is meaningless… but then again, so is MACH … and composable… and headless… and Developer experience… and serverless…, but also, they’re all hugely important

Meaningless and hugely important seem to be almost diametrically opposed, so let me take a step back and explain

I’ll start where all good tech thought leadership should start: With the works of Ludwig Wittgenstein.

Who is Wittgenstein and why do I care?

Wittgenstein was an Austrian philosopher of the early 20th century. His primary focuses were logic and philosophies of language and the mind. He had only one book published during his life: Tractatus Logico-Philosophicus.

The Tractatus is a collection of 525 declarative statements that seems to try to solve both philosophy and language. needless to say, we’re not going to dive into all those, we’re going to focus on one interesting statement made near the end of the work.

Often referred to as “Wittgenstein’s ladder” proposition 6.54 says the following

“My propositions serve as elucidations in the following way: anyone who understands me eventually recognizes them as nonsensical, when he has used them—as steps—to climb beyond them. (He must, so to speak, throw away the ladder after he has climbed up it.)

He must transcend these propositions, and then he will see the world aright.”

In other words, as you read and understand the work of the Tractatus, you realize the words and propositions you’ve read are meaningless, despite allowing you to attain a new level of understanding: a ladder to be kicked away after you’ve climbed it

And that’s where we come back to our technologies.

I’ve been professionally working on the web since 2006 and building on the web since well before that. I’ve seen the eras of the web. They’re all marked by their own best practices and nomenclature. Marked by their own frameworks, both mental and code.

I started with pure HTML. I grew into proto-static site generators like movable type. I got HYPED for WordPress. Got Hyped again for Django. Full-stack frameworks, frontend frameworks, static sites, object-oriented programming, test-driven development, domain-driven development, LAMP stack, headless… JAMstack…no, i mean Jamstack.

All these terms. All this language. It’s representational of ideas of how to build sites or apps or software. They describe process. They give categorization. They build mental models. They all have common communication. They allow humans to understand technology, and humans to understand each other. And once a person (or industry) understands what the term is representing and transcends the terms to “see the world aright,” then those terms become meaningless. They have served their purpose and can be kicked away.

That’s maybe where we stand with the Jamstack.

The term and technologies caused a small revolution, but perhaps that term has served its purpose and now we all think of it as meaningless.

Let’s take a quick aside and exam the path the Jamstack has gone through as a term and trend.

Jamstack origins

We’ll start with something that, in hindsight is obvious: Jamstack is a marketing term cooked up by the folks at Netlify. Mat Biilman, co-founder of Netlify gave a talk at SmashingConf in 2016 (2016 was 7 years ago.. god I’m old…). Netlify was betting on the new architecture that was starting to spring up around the industry. What started as Static sites with generators like Jekyll, but went beyond “static”.

They had to find a way to make static sites cool. Make them seem more than what the term static implies. Mat goes so far in the presentation to say that the word static is a bad word since the experiences we created with these tools could be incredibly dynamic.

The term comes from an industry convention of naming our “technology stacks” using an acronym to describe each piece of the technology. The most famous of these at the time would have been the LAMP stack. This stood for Linux the OS, Apache, the web server, MySQL, the database, and PHP, the server-side language. There wasn’t a singular analog in the world of static sites.

You could host your HTML wherever. Your data could just be markdown or pulled from postgres… or mongo db or mysql. The underlying technologies mattered less. But how you added interactivity was JavaScript and APIs and the initial page load was just Markup. JavaScript, APIs, and Markup. JAM.

This sort of work was already in the zeitgeist. React and Vue had hit their first real stride. People saw how interactive the web could be and how the tools made that easier. This was already happening, but naming the movement made things catch faster and helped rally more folks to the cause.

In many ways, this was an instance where culture changed the language, but then language helped change the culture. We had our ladder to help people climb to this new level of architecture.

But because the JAM of the Jamstack could be nearly anything, the freeform nature of the name meant people brought their own understandings

Language games: Definitions matter

Permit me another philosophical moment. Wittgenstein’s second published work (published after his death) dealt again with language. In the book, Philosophical Investigations, he explores the idea of language as a game and how the context of language is as important as syntax and vocabulary.

Imagine, he argues, you hear the utterance “Water!” what this means is dependent on the context. It could be an order, as in “Fetch me water,” an answer to a question, “Yes, that is a cup of water,” or perhaps an exclamation of relief to a parched person. We can’t know without a common context.

In the same way, we need comprehensive definitions to avoid miscommunications.

For over two years, I ran a podcast called That’s My Jamstack. on the podcast, we talked about various technologies, and I would ask people what their entry point was into the ecosystem and their favorite parts (what was their jam in the jamstack). This always elicited interesting conversations, but I noticed (especially through the first year of hosting) that the Jamstack typically fell into two different camps… both thinking of what they were doing as the Jamstack, often with little thought to the other methodology.

One camp pre-rendered their HTML via generators like Jekyll, Hugo and 11ty. The other camp took the JavaScript of the JAM stack to whole new levels and rendered everything via client-side JS with the top framework of the time: Gatsby. Sending a simple HTML wrapper over the wire and hydrating the rest via the client JS. Now, near what is being considered the end of the Jamstack era, we’ve got new technologies that have been grouped in: server-rendered (maybe more precisely “serverless-rendered) pages. Next.js, with their adoption of React Server Components, is at the forefront of this. It’s definitely a fun way of developing, but in the waning moments of the Jamstack movement, it has ALSO been considered Jamstack.

Can you believe it? This is often a server-rendered application (albeit with great caching and some really great affordances to prerender when possible), and it’s considered Jamstack. In fact, beyond that, in 2022’s Jamstack survey, there are data points for RedwoodJS and Remix. Both amazing tools. Neither would be what I would consider “Jamstack” personally. Except… there they both are.

And that’s because… well the definition has never really been set in stone (even with a definition listed on jamstack.org), and it’s been ever changing (did you know the definition on jamstack.org changed?).

In this way, Jamstack has often been “Water!” from our earlier language game. It changes based on context, the people involved, the use case… and much much more.

The Discourse: The Jamstack is dead

With recent developments coming from Netlify (such as the shutting down of the Jamstack Discord community) and companies like Vercel doubling down on Next’s next iteration, the discourse has of course turned back to the term Jamstack. Is it helpful? Will it continue to exist? Is it dead? Is it toast?

The general consensus has been that it doesn’t matter. Whether that’s been in thevein of “it’s served its purpose” or “did it ever really matter?” what we see is that these terms are incredibly fluid.

I’d add to the discourse that while the Jamstack may be dead (and I truly mourn for that), these concepts must remain.

The problem is that without a word or a flag or a rallying cry, these systems and setups will drift further apart. We’ve already seen that as “Composability” becomes the next big rallying cry. When you’re more interested in the systems that tie things together, the implementation details can become more varied. We’ll get more server-side rendering; we’ll get more static site generation; we’ll get more islands architecture. As we get all those, the overall naming convention for “modern web practices” will slip away, and the community that was found may also.

I still might argue that the term Jamstack should have a place in our nomenclature, but maybe that place should be closer to its roots: static sites with interactivity brought in via small amounts of serverless functions and small amounts of front-end JavaScript.

That won’t happen, of course. The Jamstack term was coined by Netlify, and as Netlify shifts toward its next horizon of composability and enterprise, the term will set over the horizon behind them.

But it certainly would be nice.

Additional reading

In the time since I started writing this, there have been a lot of great articles near this subject. Here are a few of my favorites:

😱 Book Release: Eleventy by Example – Learn 11ty with 5 in-depth projects

Bryan Robinson — Thu, 04 May 2023 13:06:00 +0000

Oh hi, everyone! Listen, I've got some really exciting news. I'm honestly kind of shocked. I wrote a book. For a publisher. That comes out tomorrow.

Amazing right?

Well, listen, it's a book that talks about my absolute favorite development topic: 11ty.

Let's not go any farther without a link to buy... that seems appropriate, right? It's available in paperback and eBook.

What's covered?

Well... a lot. We build five distinct projects to cover all the basics, intermediate, and some advanced topics. Let's do a quick rundown of projects and skills.

Project 1: Basic Marketing website

The first project is super basic. We take some simple HTML and we build out a website with 11ty. To do this, we tackle a few topics:

Basic project setup
Running with no configuration
Best practice directory structure and configuration
Page templates, layouts, and includes
The data cascade and data in templates
- Global data, template data, JavaScript data, you name it, we got it
Deployment to Netlify and CloudFlare

Not bad for a simple marketing site tutorial!

Project 2: Simple blog

Who doesn't need a blog example, am I right? In this project, we create a blog with 11ty including dealing with dreaded off-by-one date issues. The solution I wrote for the book is now one of the recommended solutions in 11ty's docs. We also make our blogs more interesting with custom media types.

Skills learned:

Collections
Custom page templates
Pagination (powerful, but confusing to new devs)
Custom shortcodes (embed YouTube, CodePen, and blockquotes)

Project 3: Photography site

We use what we learned in the blog project and create a custom photography site to play with the Image plugin. Honestly, this was the project that took me the most work. The Image plugin is great, but I'd never used it, and dealing with responsive images in the browser takes some getting used to.

Skills learned:

Installing and configuring a plugin
Using the 11ty Image plugin
Responsive images
Custom data based on the file system (another really clever code snippet that I'm quite proud of to get a list of images as data for each post)

Project 4: Podcast website

While not everyone has a podcast, most people know about podcasts. In this project, we tackle some of the interesting requirements for dealing with podcasts. We then use this project as a base to talk about integrating with 3rd parties: Hygraph (headless CMS) and Algolia (Search).

Skills learned:

Custom filters
Custom file types (exporting JSON and RSS instead of HTML)
Using plugins
11ty Serverless for search and indexing
JavaScript data files to fetch data from a headless CMS

Project 5: A custom plugin

Finally, we use everything we've learned to put together a custom plugin to have all our shortcodes, filters and more readily available for any new project.

Skills Learned:

Plugin setup
Plugin testing

Ready to learn?

I'm really proud of the book and everything it teaches. If you're interested in picking up 11ty, I think it's a great resource.

You can order it today as an ebook or print book.

11ty Second 11ty: Creating Template Filters

Bryan Robinson — Mon, 15 Aug 2022 13:30:00 +0000

11ty Template filters are ways of manipulating data in a variable tag in your template language of choice. Each template language brings it’s own set and 11ty adds a few defaults, as well.

Using a built-in filter

To use a built-in filter, write a variable or expression in your language of choice, here’s a liquid template that will display the string “hi there” on the page.

<body>
    <h1>11ty Second 11ty: Filter Example</h1>
    <h2>{{ "hi there" }}</h2>
</body>

Once you have that, add the pipe character and the filter’s name. In this case, the built-in slugify filter will convert the string to a url-appropriate string.

<body>
    <h1>11ty Second 11ty: Filter Example</h1>
    <h2>{{ "hi there" | slugify }}</h2>
</body>

<!-- Outputs: <h2>hi-there</h2>

Making custom filters

Next to make a custom filter, we need to have a configuration file. We’ll create .eleventy.js in our project root.

From there, we’ll export out a function that has the eleventyConfig object and use the addFilter method on that object.

The method takes two properties, a name for the filter for use in the template, and a function that will be used to mutate the data.

In this case, we’ll make an uppercase filter to convert our string to all uppercase. The function we’ll make takes the first argument of the string the filter is applied to. In this case, we’ll use string.toUpperCase() in Javascript to return the mutated string.

module.exports = function(eleventyConfig) {
  eleventyConfig.addFilter("uppercase", function(string) {
    return string.toUpperCase();
  })
}

Then we can use this in the template:

 <h1>11ty Second 11ty: Filter Example</h1>
 <h2>{{ "hi there" | uppercase }}</h2>

You can also adjust markup around your string, as well. In this case, we’ll take the bad idea of adjusting the string’s color in our filter. Any argument after the first in our filter will be the options that can be passed to the filter. In this case a color string. We can wrap the string in a span and set the color inline.

module.exports = function(eleventyConfig) {
  eleventyConfig.addFilter("uppercase", function(string) {
    return string.toUpperCase();
  })

  eleventyConfig.addFilter("color", function(string, color) {
    return `<span style="color: ${color}">${string}</span>`;
  })
}

Then we can use this in the template:

 <h1>11ty Second 11ty: Filter Example</h1>
 <h2>{{ "hi there" | color: "red" }}</h2>

And more!

Filters can be a super powerful piece of your 11ty builds. They allow you to mutate data on the fly no matter the source. Anything you can do in Javascript, you can do in a filter, so play around with things like creating a date string filter for Nunjucks (only available in Liquid) or reordering array or creating a strong set of HTML templates for common use cases in your markup or markdown.

11ty Second 11ty: Global Data files (JS and JSON)

Bryan Robinson — Mon, 08 Aug 2022 17:22:00 +0000

In these two videos, we take 110 seconds each to discuss how to use 11ty's Global Data files to pull static data with JSON and dynamic (at build time) data with JavaScript.

11ty JSON Data Files

In this episode, we’re going to talk about Global data files. Specifically JSON data files. So, 110 seconds on the clock, Let’s go!

11ty has a concept of the data cascade, and while we won’t go into details on that in this video, we do need to mention that global data files are the lowest priority, so if you set something in a global data file and change it using the configuration API, the API will overwrite that data

To get started, we have a barebones 11ty site. All we have is an index file. In order to add global data, we need a directory for our files to live. The default is an _data directory.

We’ll create that and a json data file. The name of the file will be the key we’ll use to access the data in our templates. In this case, we'll name it siteSetting.json.

We’ll make a super simple site settings data file. Global information we may want in multiple templates later on.

Then, we’ll put a JSON object here with a few pieces of data. We’re using an object here, but any valid JSON will work including an array.

{
  “name”: “Data Example”,
  “description”: “A data example site for 11ty second 11ty”
}

Once this is saved in, we can access it from our index template (or any other template... it's global, right?).

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
<body>
    <h1>11ty Second 11ty: Data Example</h1>
    {{ siteSetting.name }}
    {{ siteSetting.description }}
</body>
</html>

Dynamic Content at Build time with 11ty JS Data Files

Now this works for static content, but what if we want to add some dynamic content per build… say a date for the copyright in our footer.

We can do that with a Javascript Data file

Let’s copy the siteSetting.json file and move it to a settings.js file.

From here, we’ll reformat to use module.exports and export this object

Now, we’ll add a simple copyright property using JavaScript’s built in Date method. We’ll generate the full date time and format it in our template.

module.exports = {
  "name": "settings",
  "description": "Settings for the bot",
  "date": new Date(),
}

Then, we add this to our index.html file

<body>
  <h1>11ty Second 11ty: Data Example</h1>
  {{ siteSetting.name }}
  {{ siteSetting.description }}

  {{ settings.date | date: "%Y" }}

</body>

The date is fine, but what if you want to hit another API and get content? JS data files work well for simple cases of this, as well.

First, we’ll make a new data file: pokemon.js

In here, we’ll make an API call to the PokeAPI which is a great simple API for learning purposes. In this case, we’ll use Axios (make sure it’s installed), but node-fetch or the latest node built-in fetch would work as well.

We export a function this time and return an array of items we wish to access. In this case. The response has a data object with a results array

const axios = require('axios');

module.exports = async function () {
    // pokemon api call
    const response = await axios.get('https://pokeapi.co/api/v2/pokemon/?limit=151');
    const pokemon = response.data.results;

    return pokemon
}

<ol>
  {% for pokemon in pokemon %}
      <li>{{ pokemon.name }}</li>
  {% endfor %}
</ol>

These are just the basics of using data files. Anything you can do in JSON or javascript, you can do in these files, including arrays, nesting, making calls to external APIs, transforming data and more.

11ty second 11ty: The Render Plugin Part 1

Bryan Robinson — Mon, 20 Jun 2022 14:30:00 +0000

The Render plugin is comprised of two shortcodes for use in your Nunjucks, Liquid or JS templates. It’s a plugin that is bundled with the main 11ty NPM package and ready to use as soon as you nom install 11ty.

To get started with the plugin, you need to install it in your .eleventy.js config file by requiring the plugin and then initializing it

const { EleventyRenderPlugin } = require("@11ty/eleventy");

module.exports = function(eleventyConfig) { 
  eleventyConfig.addPlugin(EleventyRenderPlugin);
}

The two shortcodes it adds to your project are renderTemplate and renderFile.

In this part, we’ll tackle renderTemplate.

renderTemplate allows you to put a string between two matching shortcodes and render that string in a templating language different from that of the current template

Using the `renderTemplate` tag

<!-- ...head, etc. -->
<body> 
  <p>The date is: {{ today | date: "%B %d, %y" }}</p>
</body>

Here we have a Nunjucks index page. In this page, we have a date time. It’s not great to read for a human. I want to reformat that in the template with a filter, but uh-oh, Nunjucks doesn’t have a date filter! Now that my project has the renderTemplate paired shortcode, I can get to work.

{% renderTemplate "liquid", settings %} 
  <p>The date is: {{ today | date: "%B %d, %y" }}</p>
{% endrenderTemplate %}

The renderTemplate tag accepts two arguments: the templating language we wish to use (any template string that eleventyConfig accepts will work such as html,liquid,ejs,md,hbs,mustache,haml,pug,njk,11ty.js) and an optional set of data.

In this case, I want to render the string with Liquid and I want to get a variable off the settings global JavaScript data file that is generating the current date.

Anything between the renderTemplate and the endRenderTemplate will be rendered in Liquid instead of Nunjucks.

This allows me to use the powerful date filter in liquid to format the date time string create by a JS data file (named settings.js).

Or for a simpler use case, sometimes writing Markdown is more ergonomic than writing HTML, so why not embed a little Markdown in your HTML

{% renderTemplate "liquid,md" %}
# I am a title

* I am a list
* I am a list

1. I am an ordered list
1. i'm actually second in an ordered list test
{% endrenderTemplate %}

Template engines all the way down!

This plugin opens the door to a lot of new possibilities. Any templating language can be embedded in any page or template! 11ty: It's templates all the way down!

Just want the code? Check the 11ty Second 11ty repo for this and others!

11ty Second 11ty: Basics of Collections

Bryan Robinson — Mon, 13 Jun 2022 20:52:45 +0000

Collections are the workhorse of most 11ty projects. They provide a way of grouping content or data in meaningful ways. By default, this is done by providing a tag property to a piece of content (such as in the front matter of your markdown)

Creating a better date-picking experience with the DateRangePicker component

Bryan Robinson — Thu, 13 Jan 2022 22:15:11 +0000

When crafting a search interface, it's often enough to use what comes prepackaged with Algolia's InstantSearch libraries. Each library comes in a different flavor of JavaScript for your ease of use. Each one has all the main pieces you need to craft a strong UI.

Sometimes you want to go beyond what's available.

At that point, you're presented with two options: craft your own with our connector APIs or find a pre-built custom widget.

It should come as no surprise to anyone that knows me that when presented with wanting a React date picker for December's coding challenge, I wanted to write as little code as possible to make it work, but I also wanted the best UI possible for Santa. When it came to bonus challenge number 5, I needed something extra. My first stop? The Algolia Code Exchange!

After a quick search around date components, I found exactly what I needed: the aptly-named @algolia/react-instantsearch-widget-date-range-picker!

Setting up the project

If you'd like to follow along, you'll need to install a new React InstantSearch project. The easiest way to do that is to run the following command:

 npx create-instantsearch-app concert-search \
 --app-id latency \
 --api-key 059c79ddd276568e990286944276464a \
 --index-name concert_events_instantsearchjs \
 --template "React InstantSearch"

This monster command will set up a React InstantSearch project and connect it to Algolia's hosted concert Index. Change directory into the created folder and run yarn start for a solid starting point.

At this point, you've got a full search experience for a set of concerts.

If you want to filter by date, you could set up a <RefinementList> component and set its attribute prop to date, but those dates are Unix timestamps (for easiest comparisons). This isn't ideal for the user experience. Let's make that better.

Installing and configuring the widget

To get the date range picker up and running, we need to install a couple of dependencies.

npm install @algolia/react-instantsearch-widget-date-range-picker @duetds/date-picker

This will install the official Algolia React Date picker widget and its dependency the Duet Date picker.

From here, we need to import the packages into our src/App.js file and initialize the Duet Date Picker for use.


// Add right after the imports included in the create-instantsearch-app code

import { DateRangePicker } from '@algolia/react-instantsearch-widget-date-range-picker';  
import { defineCustomElements } from "@duetds/date-picker/dist/loader";

// Defines the custom elements from the date picker for use on the window object  
defineCustomElements(window);

Now that these packages are imported, we're ready to get this on the page.

Adding the date range picker

To add the picker to the page, we need to select a spot within the <InstantSearch> component. The base of the app is a search-panel. By default, all we have inside this is the results, but we can add a filter panel, as well.


<InstantSearch _searchClient_={searchClient} indexName="concert_events_instantsearchjs">  
  <div className="search-panel">  
    <div className="search-panel__filters">  
      <DateRangePicker attribute="date" />  
    </div>  

    <div _className_="search-panel__results">

      //... Results code

    </div>
  </div>
</InstantSearch>

The DateRangePicker accepts an attribute prop. This prop accepts a date-based attribute from the hits in our Index.

Quick note: The DateRangePicker accepts a Unix timestamp with milliseconds since the Epoch, not seconds. Depending on your data structure, you may need to create a secondary timestamp in your data.

When you view the rendered page, you should now have a date picker. There are a few small UI snags to clean up.

The Duet Date picker uses a slew of CSS Custom Properties for much of its styling. At the start of our src/App.css file, we need to paste those in and configure for our app (as appropriate).


:root {  
  --duet-color-primary: #3c4ee0;  
  --duet-color-text: #333;  
  --duet-color-text-active: #fff;  
  --duet-color-placeholder: #666;  
  --duet-color-button: #f5f5f5;  
  --duet-color-surface: #fff;  
  --duet-color-overlay: rgba(0, 0, 0, 0.8);  
  --duet-color-border: #d6d6e7;  

  --duet-font: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Helvetica,  
  Arial, sans-serif;  
  --duet-font-normal: 400;  
  --duet-font-bold: 600;  

  --duet-radius: 3px;  
  --duet-z-index: 600;  
}

The two picker areas are a little close together still, so let's fix that with a little CSS, as well. This can go in src/App.css but should be closer to the bottom. There are many ways to get the space between the two items, the quick and easy solution is to use CSS Grid and the gap property.


.date-range-picker {  
  display: grid;  
  gap: 1rem;  
}

And with that, we have a functioning, user-friendly date picker. No more dealing with Unix timestamps and conversions.

Take this further

This works great in the small sample dataset, but can also be brought into any Algolia InstantSearch application. If you're looking to take this example further, create a better UI around each Hit by editing the hit component in src/App.js. You could also show the current filters applied with the CurrentRefinements component.

Building a GitHub Issue Recommendation Bot with Algolia

Bryan Robinson — Thu, 02 Dec 2021 18:21:18 +0000

GitHub Issues are static content. What if they didn't have to be?

When we (DevRels Chuck Meyer and Bryan Robinson) discovered that Dev.to was hosting a GitHub Actions hackathon, we knew we needed to give it a try.

We knew we wanted to figure out a useful tool to integrate Algolia into an Action. There were obvious thoughts on what sort of project to undertake. We thought through the usual takes on indexing content, products, or markdown. They all would have been helpful for web creators. Would they have been helpful to open source maintainers, though? Probably?

How could we make their overall workflow better?

Then it struck us: What if we could give recommended Issues for frequently asked questions? Could we lessen the burden of maintainers answering similar questions? How many Issues get closed as "duplicate" in large repositories? Could Algolia provide Issue creators a list of related, helpful Issues?

Spoiler alert: Yeah, totally!

The Workflow structure

When a developer adds an Issue to a repository, we need to execute three steps.

First, we need to search an Algolia Index for related Issues. Then, we bundle those results into Markdown and pass it to an Action to create a comment on the initial Issue. Finally, we need to put the Issue into our Index for future searches.

Each of these steps requires an Action. The Algolia-specific Actions, we needed to create from scratch. The comment-writing Action, we decided to use the amazing Peter Evan's create-or-update-comment Action – which, as it turns out, GitHub uses in many of their docs about Actions.

Let's dive into the new Actions.

Performing a search query

The first step of our Workflow is a search query sent to Algolia. We created a custom Action for this (Get Algolia Issue Records).

To use the Action, we need to send it four required inputs (and an optional fifth).

app_id: the ID of the application in your Algolia account. This is best stored as a Secret in your repository
api_key: An API key with search permissions to the Index in your Algolia App. This is best stored in a Secret in your repository.
index_name: The name of the Algolia Index to search. For consistency, we recommend the github.event.repository.name variable.
issue_title: The title of the inciting Issue found with github.event.issue.title.
max_results: (OPTIONAL) A number of results to return to the comment (defaults to 3)

We take these variables and perform a similarQuery search based on the inciting Issue's title. We then create a comment body and a list of items in Markdown (the format needed for GitHub comments). This outputs are passed to Peter Evans' create-or-update-comment Action.

const { inspect } = require('util');
const core = require('@actions/core');
const algoliasearch = require('algoliasearch');

async function run() {
  try {
    const inputs = {
      appId: core.getInput('app_id'),
      apiKey: core.getInput('api_key'),
      indexName: core.getInput('index_name'),
      issueTitle: core.getInput('issue_title'),
      maxResults: core.getInput('max_results'),
    };
    core.info(`Inputs: ${inspect(inputs)}`);

    if (!inputs.appId && !inputs.apiKey && !inputs.indexName) {
      core.setFailed('Missing one or more of Algolia app id, API key, or index name.');
      return;
    }

    inputs.maxResults = inputs.maxResults || 3;

    const client = algoliasearch(inputs.appId, inputs.apiKey);
    const index = client.initIndex(inputs.indexName);

    index.search('', { 
        similarQuery: inputs.issueTitle,
        hitsPerPage: inputs.maxResults
      }).then(({hits}) => {
      core.info(`Searching for record`);
      core.info(`Hits: ${inspect(hits)}`);
      const message = `## Other issues similar to this one:\n${hits.map(hit => `* [${hit.title}](${hit.url})`).join('\n')}`
      const listItems = `${hits.map(hit => `* [${hit.title}](${hit.url})`).join('\n')}\n`
      core.info(message)
      core.info(listItems)
      core.setOutput('comment_body', message);
      core.setOutput('issues_list', listItems);
    })
      .catch(err => {
        core.setFailed(err.message);
      }
    );
  } catch (error) {
    core.debug(inspect(error));
    core.setFailed(error.message);
    if (error.message == 'Resource not accessible by integration') {
      core.error(`See this action's readme for details about this error`);
    }
  }
}

run();

Adding the issue to your Algolia index

For the final step of our workflow, we add this new issue to the Algolia index for future searches. We created another GitHub Action for this purpose: Create or Update Algolia Index Record. This action atomically adds/updates a record directly to an index rather than writing/reading from a JSON file. This makes sense in situations where we are acting on metadata about the repo (issues, pull requests, comments) as opposed to building an index for the application itself.

To use this action, we'll need to create an Algolia API key with permissions to add/update records in our index. Additionally, we will need permission to create a new index for the repo. Otherwise, we must create it ahead of time and hard code the index name in our configuration.

Along with the new API key we'll need a few other inputs to use the action:

app_id: You should already have this as a Secret in your repository from the action above
api_key: This is the new key with permission to save records to your index. This is best stored in a Secret in your repository.
index_name: The name of the Algolia index to add/update this record. For consistency, we recommend the github.event.repository.name variable.
record: A string represneting the JSON record to add to the index.

If the API key has permission, the action creates an index for the repository. We'll add the issue title and URL (to link back) as the record. It's a multi-line string in our workflow, but must_ be valid JSON for the action to work (see https://www.algolia.com/doc/guides/sending-and-managing-data/prepare-your-data/#algolia-records for details).

We take all of these inputs and execute a saveObject call via the Algolia API. We use the issue ID as the objectID in the index. This makes it easy to tie the record back to this issue if we add workflows for update or delete events later.

const { inspect } = require('util');
const core = require('@actions/core');
const algoliasearch = require('algoliasearch');

async function run() {
  try {
    const inputs = {
      appId: core.getInput('app_id'),
      apiKey: core.getInput('api_key'),
      indexName: core.getInput('index_name'),
      record: core.getInput('record'),
    };
    core.debug(`Inputs: ${inspect(inputs)}`);

    if (!inputs.appId && !inputs.apiKey && !inputs.indexName) {
      core.setFailed('Missing one or more of Algolia app id, API key, or index name.');
      return;
    }

    core.info(`Writing record to index ${inputs.indexName}`)
    const client = algoliasearch(inputs.appId, inputs.apiKey);
    const index = client.initIndex(inputs.indexName);

    index.saveObject(JSON.parse(inputs.record), {'autoGenerateObjectIDIfNotExist': true})
      .then(({ objectID }) => {
        core.setOutput('object_id', objectID);
        core.info(
          `Created record in index ${inputs.indexName} with objectID ${objectID}.`
        );
      })
      .catch((err) => {
        core.setFailed(`Failed to save object: ${err}`);
      });

  } catch (error) {
    core.debug(inspect(error));
    core.setFailed(error.message);
    if (error.message == 'Resource not accessible by integration') {
      core.error(`See this action's readme for details about this error`);
    }
  }
}

run();

Next, we piece the two new Actions together with the existing comment creation action to build our workflow.

The full workflow file

To make this work, we need one job with three steps. Each step will use one of these Actions.

name: related-issues
on:
  # Triggers the workflow on push or pull request events but only for the main branch
  issues:
    types: 
      - opened

jobs:
  get-related-issues:
    permissions: 
      # Gives the workflow write permissions only in issues
      issues: write
    runs-on: ubuntu-latest
    steps:
      # Performs a search in an Algolia Index based on Issue Title
      # The Index should have historical Issues
      # Returns two outputs:
      # issues_list: a markdown list of issues
      # comment_body: a generic comment body with the list of issues
      - id: search
        name: Search based on issue title
        uses: brob/algolia-issue-search@v1.0
        with: 
          # Requires an Algolia account with an App ID and write key
          app_id: ${{ secrets.ALGOLIA_APP_ID }}
          api_key: ${{ secrets.ALGOLIA_API_KEY }}
          index_name: ${{ github.event.repository.name }}
          issue_title: ${{ github.event.issue.title }}
      - name: Create or Update Comment
        uses: peter-evans/create-or-update-comment@v1.4.5
        with:
          # GITHUB_TOKEN or a repo scoped PAT.
          token: ${{ github.token }}
          # The number of the issue or pull request in which to create a comment.
          issue-number: ${{ github.event.issue.number }}
          # The comment body. Can use either issues_list or comment_body
          body: |
            # While you wait, here are related issues:
            ${{ steps.search.outputs.issues_list }}
            Thank you so much! We'll be with you shortly!
      # An Action to create a record in an Algolia Index
      # This is a generic Action and can be used outside of this workflow
      - name: Add Algolia Record
        id: ingest
        uses: chuckmeyer/add-algolia-record@v1
        with:
          app_id: ${{ secrets.ALGOLIA_APP_ID }}
          api_key: ${{ secrets.ALGOLIA_API_KEY }}
          index_name: ${{ github.event.repository.name }}
          # Record needs to be a string of JSON
          record: |
            {
              "title": "${{ github.event.issue.title }}", 
              "url": "${{ github.event.issue.html_url }}", 
              "labels": "${{ github.event.issue.labels }}",
              "objectID": "${{ github.event.issue.number }}"
            }

Next steps

We hope that this is helpful to maintainers, but we also hope it inspires others to find better and better ways to suggest content in static areas like GitHub Issues.

If you want to play around with the full workflow, you can check it out in this repository. Both the search and ingest Actions are available in the GitHub marketplace.

Search and discovery can become an interesting part of your automated workflow in GitHub and beyond.

Post and Bot by:

Chuck MeyerFollow

API driven. DevRel 🥑 at Algolia.

Bryan RobinsonFollow

I'm a designer, developer, lover of static sites and CSS

DEV Community: Bryan Robinson

Does our technology still work for us?

SEO worked for us… until it didn’t

AI’s hidden cost on our brains

Conclusion

Pay no mind to this, this is just a test

Convert a Hygraph Next.js project to Next.js app directory

Required Knowledge

Why the app structure?

Setting up a Next.js 13 project to work with the app directory

Converting from /pages to /app

Creating the root layout component

Adding the homepage

Converting the dynamic products route

Setting up a custom 404 page

Next steps

Boost your editorial experience with distributed content management

What is distributed content management?

Why should you care about content velocity?

The importance of content standardization

Unified Content Strategy

Technological standardization

How a distributed system can help with standards

Reduced training time and costs

Setting up a distributed CMS

An eCommerce experience

Conclusion

Jamstack is meaningless

Who is Wittgenstein and why do I care?

Jamstack origins

Language games: Definitions matter

The Discourse: The Jamstack is dead

Additional reading

😱 Book Release: Eleventy by Example – Learn 11ty with 5 in-depth projects

What's covered?

Project 1: Basic Marketing website

Project 2: Simple blog

Project 3: Photography site

Project 4: Podcast website

Project 5: A custom plugin

Ready to learn?

11ty Second 11ty: Creating Template Filters

Using a built-in filter

Making custom filters

And more!

11ty Second 11ty: Global Data files (JS and JSON)

11ty JSON Data Files

Dynamic Content at Build time with 11ty JS Data Files

11ty second 11ty: The Render Plugin Part 1

Using the renderTemplate tag

Template engines all the way down!

11ty Second 11ty: Basics of Collections

Creating a better date-picking experience with the DateRangePicker component

Setting up the project

Installing and configuring the widget

Adding the date range picker

Take this further

Building a GitHub Issue Recommendation Bot with Algolia

The Workflow structure

Performing a search query

Adding the issue to your Algolia index

The full workflow file

Next steps

Chuck MeyerFollow

Bryan RobinsonFollow

Using the `renderTemplate` tag