— — — In this post I talk about the app I built. 🔗 Here is the GitHub repo

Back in April, I organized the first ever Nx Summit in the EU. It took place in Amsterdam, and it involved quite a lot of planning.

Here are the main things I handled:

• Venue selection
• Date and format planning
• Budget management: I had to keep everything under a specific budget
• Attendee targeting: We wanted 100 European customers and prospects, so I reached out individually to invite them
• Hotel arrangements: I picked a conference hotel right next to the venue and secured a group price and discount codes (which, to be honest, didn’t work great)
• Registration system: Just a Google Form
• Schedule development: A full agenda with meals, presentations, roundtables, and space for networking
• Speaker coordination: Worked with our team and invited external speakers
• Swag: Actually useful stuff : rain ponchos (luckily unused), inkless pens (aka pencils?), and scrunchies
• Gift bags: Paper bags for each attendee with goodies and a handwritten thank-you postcard
• Badges: Amsterdam-themed name tags for attendees and the Nx team
• Team travel coordination: Took note of arrivals, booked rooms, and planned social activities
• Social activities: Planned a group outing to Keukenhof in full bloom the day after the event
• Attendee tracking
• Cost tracking: We wrapped things up using just 80% of the budget
• Market research: Avoided date conflicts with other conferences and arranged for us to sponsor one that took place the day before
• Partner coordination: Talked to partners about inviting their customers

All that wasn’t enough for me.

I decided we needed a virtual ticketing and check-in system. There are a million solutions for this, but none were good enough for me. So naturally, I reinvented the wheel and built an app.

At first, I just wanted a ticket and check-in app. But with a blank slate, I thought why not make it fun?

I asked myself: What’s the point of this event? The answer: for our team to talk to as many attendees as possible, gather feedback, and collect stories.

So I gamified it.

The Idea: Collect Points

• Scan someone’s QR code, earn points
• Trade points for a prize

But I didn’t want just one winner who talked to the most people — not everyone has the same time or comfort levels. So I made it a weighted raffle:

The more points you have, the more chances you get.

How It Worked

• Every attendee had a personal QR code (UUID-based, no emails)
• Scan another attendee: +1 point
• Scan an Nx team member: +4 points
• Check in at the event: +1 point

Bonus points:

• Participate in a round table: +5 points
• Ask a question during Q&A: +5 points
• Get interviewed: +8 points
• Show me a picture of your cat: +3 points (UUID-based, no emails)

Admin Mode

Admins could:

• View and manage the attendee list
• Scan attendees to check them in
• Sign people in/out manually
• Track points and participation
• Run the raffle (with a spinning wheel animation, naturally)
• View schedule and game rules

I spec’d everything out with GPT, then pasted the prompt into bolt.new, and tada! Website.

Of course, I made it harder for myself by overengineering it.

Challenges

• Getting the QR scanner to behave and not go into infinite scan mode
• Deciding what controls admins should have
• Setting up role-based access (attendee, staff, super_admin)
• Ensuring anonymity (UUIDs instead of emails)
• Printing QR code stickers for team members — bonus points if they had their Calendly links too

Authentication was handled by an Edge Function. All staff shared a password. Was it Fort Knox? No. Was it enough? Yes.

RLS was enforced for access control, while game-related reads (like scanning) were available under public-read constraints that respected RLS.

Using GPT

Before I even opened a code editor, I pitched my idea to GPT. We talked it through a bit — what I wanted the app to do, how it might work, what the edge cases were. Then I asked GPT to spec it out in detail, so I could feed it directly into bolt.

We went back and forth tweaking the spec until it left no room for ambiguity. I wanted something clean and executable — no guessing. Once we nailed it, I dropped it into bolt and the app was ready.

I like GPT, it’s good for pitching and discussing ideas.

Using Bolt.new

I used bolt.new to build the entire app, and it made everything faster and smoother. The UI that bolt created was clean, mobile-friendly, and, honestly, fresh and fun.

What really stood out was the Supabase integration: I could connect my project, run migrations, deploy Edge Functions, and query data — all from the same place. It worked like a charm.

Bolt let me take an idea from a GPT-generated spec to a live working app in no time. And then I had plenty of time left over to overengineer it, of course.

And once everything was ready, I 1-click-deployed it to Netlify straight from bolt. It just worked.

Using Supabase

Supabase made things surprisingly easy. I used it for the entire backend — the database, serverless functions, role-based access, and real-time updates were all handled in one place.

Before anything could work, I uploaded the list of registered attendees to the Supabase attendees table. Each record had a name and email — this allowed the system to verify identities when someone “signed in” with their email, and to generate their unique QR code.

Here’s how it worked:

• Attendees didn’t need to sign in. They simply entered their email. If their email existed in the attendees table, they were in. No account creation, no password, no magic link — just a soft lookup. If the email didn’t exist in the database, the Edge Function returned a failure response, and the frontend blocked them from proceeding. So while the app felt lightweight with no login, identity verification was still enforced securely on the backend.
• QR codes were anonymized. Each attendee’s QR code used a UUID from the database — not their email or any personal info. That way, if someone scanned you, they couldn’t see who you were or get access to your data — they just got points.
• Game functionality (like scanning or checking a leaderboard) was available without authentication. Public reads were allowed via Supabase’s anon key, thanks to carefully scoped RLS (Row-Level Security) policies. This meant the app could run smoothly client-side, with no login required — but still respect access controls.
• Mutations (like awarding points, checking in attendees, or running raffles) were locked behind Supabase Edge Functions. These functions used the service_role key, which gave them full privileges. I wrote RLS policies so that only the service_role could perform updates. So even if someone tried to call the same APIs from their browser, nothing would work unless it was coming from the server.
• Role-based logic was layered in. Attendees had the default attendee role. Staff (and me, the super_admin) had elevated roles stored in the same attendees table. Edge Functions validated roles before running sensitive actions, like toggling the game state or drawing raffle winners. Staff authenticated with a shared password (via an Edge Function), and once verified, they had access to the admin panel.

In short, Supabase let me build something fast, fun, and secure — without needing a separate auth system, backend framework, or deployment flow. It was all right there. Just enough abstraction to move quickly, and just enough control to make it feel solid.

Measuring Engagement

At most conferences, you talk to a dozen people, have great conversations and then later realize you don’t remember their name, or never got their email. That’s a problem.

For our team, it was critical to track who we interacted with, who had questions, who shared feedback . Not just for follow-up, but to understand our impact.

Instead of asking the team to manually jot down names or hand out stickers, I gamified it.

Every time someone scanned a badge, it left a digital footprint of that interaction. Attendees were incentivized to scan team members (worth more points), which in turn meant we could easily tell who had talked to whom.

It made it easier for attendees to start conversations, and for us to track real, valuable engagement automatically.

The game wasn’t just fun. It helped us track real engagement in a lightweight and meaningful way.

Because each interaction (like scanning someone or participating in a session) generated a point and left a record, we could:

• See who connected with whom — every scan was a touchpoint
• Understand which attendees were most active and involved
• Identify the most talked-to team members
• Spot high-interest moments, like Q&A spikes or interview participation

This gave us a unique way to measure the impact of the event beyond just attendance. We didn’t need forms or follow-up surveys — the game was the engagement tracker.

Data Insights

After the conference, we downloaded all the interaction data as a CSV. This gave us a clean record of who showed up, who scanned whom, and how points were distributed.

We could import everything into a Google Sheet, track metrics, visualize participation, and segment attendees based on engagement — without needing extra tooling.

• Downloaded attendee list to see who showed up, who scanned who
• Retroactive conversation tracking: if someone scanned your badge, you spoke to them
• Vanity stats! We knew who was most engaged, who participated in Q&A, who got interviewed

Raffle Time

I customized the raffle logic. Bolt generated the page, but I wanted the chances to be more fair. I weighted heavily based on points and added a spinning animation. It was slightly off visually, but still fun.

Why I Loved Building This

I love building things, especially games. (Come to one of my birthday parties. My last one had a murder mystery game for 75 people.)

Using tools like GPT and Bolt made the process so much smoother. I wasn’t stuck Googling how to make QR scanners work. I could just build, tweak, and keep going.

Did I spend 5 days perfecting it? Yes. Am I picky? Yes. Did I enjoy every second? Absolutely.

We live in a time where it’s easier than ever to build something cool, useful, and delightful. You just have to start.

🔗 Here is the GitHub repo

Fork it, clone it, and use it at your next event.

🎮 Nx Summit Game Rules

Overview This is a gamified check-in and networking app for the Nx Summit that encourages attendee interaction through QR code scanning and point collection.

How to Play

1. Getting Started

• Check-in is required before playing
• Each attendee gets a unique, private QR code (UUID-based)
• Everyone starts with 0 points

2. Earning Points

QR Code Scanning:

• Regular Attendees: +1 point
• Nx Team Members: +4 points
• You can only scan each person once

Engagement Rewards:

• Participate in roundtables or Q&A: bonus points
• Staff can manually award points

Hidden Bonuses:

• Show Katerina a cat photo: +3 points

3. Privacy & Security

• Only name and invite email are stored
• No emails exposed during scanning
• No tracking or third-party data sharing

4. Winning Prizes

Weighted Raffle:

• Your chances = your points / total points
• Everyone has a shot, but activity helps!

Game Strategy Tips

• Prioritize scanning Nx team (they’re worth more!)
• Engage in sessions and Q&A
• Scan lots of unique attendees
• Stay involved and earn those bonus points

Technical Highlights

• Real-time updates and leaderboard
• Admin panel with controls and raffle logic
• Mobile-friendly
• Resilient to network hiccups

The game made networking more fun, interactive, and rewarding — without sacrificing privacy or creating friction.

Make it yours and add it to your next event!

I’d love to hear what you ended up doing. Feel free to tag me or reach out!

Reach out

GitHub repo: https://github.com/mandarini/nxsummit-game

Find me: https://psyber.city

Follow me:

• https://x.com/psybercity
• https://bsky.app/profile/psyber.city

In the ever-evolving landscape of software development, efficiency and speed are vital. As projects grow in complexity, developers and teams need tools that can keep up without sacrificing quality or performance.

Nx is a suite of powerful tools designed to optimize your development workflow, which sets the building blocks for a fast CI. Nx is always innovating in many ways to make developers’ lives easier, but this post is exclusively focused on the things Nx has done in the past year to make development faster and faster.

Why speed matters

The ability to iterate quickly and efficiently is vital for any software project. Speed in the development process offers several critical advantages:

• Faster feedback loops: Quick iterations mean immediate feedback, allowing teams to adapt, learn, and improve their work on the fly.
• Reduced time to market: Accelerating the development process can significantly cut down the overall time to market, providing a competitive edge which reclaims revenue that would have otherwise been lost.
• Decreased developer frustration: No more waiting for builds and tests to complete. A streamlined workflow keeps morale high and productivity higher.

If you’re using Nx already, you’re already familiar with

• Affected - identifying and running tasks only on projects impacted by code changes,
• Nx Replay -our powerful cache and
• Nx Agents — the concept of Parallelization and Distribution.

But let’s see all the extra things we did this past year to make everything faster.

Speed at the core

Rustifying Nx

The Nx daemon has seen significant enhancements, notably through the use of Rust to calculate file hashes behind the scenes. This improvement not only speeds up the start-up times but also optimizes performance even without the daemon, especially on CI environments where the daemon isn’t used. The benchmark results at this repo showcase the remarkable speed improvements, making Nx competitive with native code solutions while maintaining the accessibility and flexibility of Node.js. Nx is still Node-first, so contributions are easier and only the most performance-critical parts of Nx are native code.

Task Hasher and archive file innovations

The introduction of a task hasher written in Rust, alongside the use of an archive file to store workspace file hashes (.nx/cache), has significantly reduced the need for repetitive file system accesses. This innovation means that running multiple Nx commands in CI is much faster, as file hashing becomes unnecessary after the initial run.

The Archive file

The archive file is a binary file that contains the workspace file hashes with their last modified time. Every time Nx starts (ie, running nx run project:target) it gets all the files with their last modified time, and compares it to the archive. If the file exists in the archive, then Nx does not access the file system to read the file to hash (reading individual files is slower than just getting a list of files from a directory). So running multiple nx commands in CI is quick to start because Nx does not need to constantly hash files.

Nx Replay

Nx Replay enables caching and reusing of task results. It’s our well known Nx remote cache! It allows developers to avoid re-running expensive tasks by retrieving the cached results from a remote cache. This significantly improves build and test performance, as well as developer productivity. Nx Replay is also critical to the functioning of Nx Agents, which rely on the remote cache to ensure that the results of a task will be shared with every agent that needs them. By using Nx Replay, developers can optimize their workflows and reduce the time spent waiting for tasks to complete.

With Nx Replay, you can see significant speed improvements in your CI pipelines for modified PRs. What’s also important is that if a task has been executed in CI, a developer running that same task locally can reuse the task result instead of actually running the task. So you will also see improvements locally.

Nx Agents

Nx Agents represent the pinnacle of task distribution optimization, ensuring that tasks are executed as efficiently as possible based on the specific requirements of each change. Some features that make up this effort are:

• Easy integration with existing providers: Distribution is handled on the Nx Cloud infrastructure and all you need is a single line. What’s more, all results are played back to your original CI provider script which triggers the Nx Cloud distribution, so that you can make use of the resulting artifacts
• Efficient task distribution: Save compute resources and reduce costs, minimizing idle time and compute waste. Also, Nx offers dynamic sizing based on PR size
• Tusky — our AI solution (coming soon): You set your desired cost/speed ratio, and you forget about any more configuration. We ensure maximum speed up to limits you set yourself.

You can read more about Nx Agents here.

TaskAtomizer

The TaskAtomizer splits your Cypress or Playwright e2e tests by file. This significantly enhances granularity for caching, parallel execution, and flaky test identification. This granular approach ensures that individual test results can be cached and only the necessary tests rerun, greatly reducing CI pipeline times and facilitating more accurate flaky test detection.

Addressing flaky tests with test deflaking

Flaky tests can be a significant bottleneck in the CI process. Nx tackles this issue head-on by intelligently re-running only the flaky tasks, rather than the entire pipeline. This approach not only saves time but also provides developers with more confidence in their CI pipeline’s reliability.

Nx creates a hash of all the inputs for a task whenever it is run. If it encounters a task that fails with a particular set of inputs and then succeeds with those same inputs, Nx knows for a fact that the task is flaky.

New Nx features that tie in with our core speed improvements

Module Federation

With the help of Nx and the Module Federation setup that Nx offers, you can split up large Angular apps into smaller “vertical slices”. This can significantly speed up your builds and app startup time. Nx has revolutionized the use of Module Federation, especially in how static remotes are built and served. We make use of Nx’s task orchestration, allowing users to fine tune the number of builds happening in parallel to improve local startup time, manage machine resources better, allow for scaling.

First-Class Playwright support

With first-class support for Playwright through @nx/playwright, Nx offers out-of-the-box generators to run Playwright tests efficiently. This integration is especially powerful with features like TaskAtomizer, enhancing the testing process's speed and reliability.

Conclusion

Nx provides an unparalleled toolkit for developers and teams looking to optimize their development workflows, and we keep making it faster. By intelligently leveraging modern technologies and innovative optimizations, Nx delivers speed, efficiency, and reliability, allowing teams to focus on what matters most: building great software.

Learn more

Check out the example repo used in this blog post or one of the links below to learn more:

- 🧠 Nx Docs
- 👩‍💻 Nx GitHub
- 💬 Nx Community
- 📹 Nx Youtube Channel
- 🚀 Speed up your CI

Also, if you liked this, click the 👏and make sure to follow Katerina and Nx on Twitter for more!

Monorepos — Why Speed Matters was originally published in Nx Devtools on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’re excited to introduce a new way to enhance your Nuxt development workflow! After the Vue plugin, we’re introducing our new Nx plugin for Nuxt, @nx/nuxt. Designed for Nuxt developers and existing Nx users alike, this integration brings the best of both worlds into your development ecosystem, enabling you to leverage Nx’s powerful capabilities seamlessly within your Nuxt projects.

Why Consider Nx for Your Nuxt Projects?

Using Nx with your Nuxt.js projects presents the following advantages:

• Monorepo Management: Simplify the management of multiple projects within a single repository, facilitating code sharing and reducing overhead.
• Modular Development: Break down your Nuxt app into manageable, independent modules that can be developed, tested, and deployed in isolation.
• Enhanced Caching: Accelerate your development with Nx’s intelligent caching, automatically configured for your Nuxt projects.
• Nx generators: Nx provides generators for scaffolding new Nuxt applications, with support for Jest, Storybook, and e2e test generation with Cypress or Playwright.
• Automated upgrades: Nx offers a set of migrators that help you upgrade your projects.

Getting Started with Nx and Nuxt.js

Whether you’re initiating a new project or integrating into an existing one, @nx/nuxt offers a straightforward setup process:

Starting a New Nx Workspace with Nuxt

Creating a new Nx workspace optimized for Nuxt is as simple as running:

npx create-nx-workspace@latest --preset=nuxt

Our setup wizard will guide you through the initial configuration, ensuring your workspace is tailored to your needs:

npx create-nx-workspace@latest
> NX Let's create a new workspace [https://nx.dev/getting-started/intro]
✔ Where would you like to create your workspace? · my-org
✔ Which stack do you want to use? · vue
✔ What framework would you like to use? · nuxt
✔ Integrated monorepo, or standalone project? · integrated
✔ Application name · my-app
✔ Test runner to use for end to end (E2E) tests · playwright (also cypress)
✔ Default stylesheet format · scss (also css, less)
✔ Set up CI with caching, distribution and test deflaking · github

This command will create a new Nx workspace with a single Nuxt application, complete with essential features and ready for development.

Enhancing an Existing Nuxt Project with Nx

Integrating Nx into an existing Nuxt.js project has never been easier, with the help of the `nx init` command. This command will add Nx to your project without the need to disrupt your current setup.

How It Works

When you run `nx init` in your existing Nuxt.js project, Nx does the following:

• Installs @nx/nuxt: Adds the necessary Nx and @nx/nuxt dependencies to your project, enabling Nx’s features while keeping your existing setup intact.
• Understands Existing Configurations: Nx automatically recognizes your nuxt.config.js or nuxt.config.ts file, ensuring that all your custom configurations, scripts, and commands are preserved and utilized.
• Minimal Configuration: Only a minimal `nx.json` file is added to your project. This file is used to configure the `@nx/nuxt` plugin if needed, but in most cases, your existing Nuxt.js configurations will suffice.

To begin the integration process, simply navigate to the root of your existing Nuxt.js project and run:

npx nx init

This approach offers several key benefits for teams looking to adopt Nx:

• Zero Disruption: Your project will continue to use its existing configurations, and the existing configuration entrypoint files. There’s no need to learn new configuration syntaxes or reconfigure your project to start using Nx.
• Immediate Value: Instantly gain access to Nx’s powerful developer tools and build system, without significant changes to your project.
• Future Flexibility: As your project grows, Nx is ready to scale with you. You can gradually adopt more Nx features and plugins over time, at a pace that suits your team.

Using Nx to run your Nuxt app

Nx scans your workspace to look for Nuxt configuration files (eg. `nuxt.config.ts`). It uses these files to understand where your Nuxt projects live, and uses them to set up tasks that can be invoked through Nx, like `serve` and `build`. So, in your Nx workspace, you can then run:

nx serve my-nuxt-app

nx build my-nuxt-app

and these commands will call the `nuxt` CLI under the hood, enhanced with Nx’s features.

You can see a visual representation of your task dependencies by running

nx graph

You can also see how Nx configures your tasks, by running:

nx show project my-nuxt-app — web

Using Nx Console

You get access to all these features through our VSCode and WebStorm Nx Console extension.

You can use Nx Console to visualise tasks, and understand where each inferred task (like `build` and `serve` in Nuxt’s case) is coming from, with our codelens-like feature, as an alternative to the ` — web` flag on the `nx show project` command.

Nx Console is also very convenient for generating code and running tasks, since it offers a graphical user interface for all the amazing features of the Nx CLI.

What Does Nx Bring to Your Nuxt Development?

With `@nx/nuxt`, your Nuxt projects gain automatic recognition of `build` and `serve` processes. There’s no need to deal with unfamiliar configurations; Nx intuitively understands your Nuxt project structure and optimizes accordingly.

Modularize and Scale with Ease

One of the most compelling aspects of using Nx with Nuxt.js is the ability to modularize large applications into manageable libraries or components. This not only makes your codebase more organized and maintainable but also significantly enhances your development workflow and CI processes.

Breaking Down a Monolithic Nuxt App

Large Nuxt applications can become challenging to maintain and scale over time. By adopting Nx, you can structure your Nuxt app as a collection of smaller, focused libraries. Each library can encapsulate specific functionalities or features, such as UI components, utilities, or business logic.

Independent Development and Testing

This modular structure allows teams to work on different aspects of the application in parallel, reducing bottlenecks and improving collaboration. Furthermore, you can run tests, linters, and other checks independently for each library, making your development process more efficient and targeted.

For instance, if you want to create a new Vue UI library, you can use the following command:

nx generate @nx/vue:lib my-shared-ui

This command creates a my-shared-ui library within your workspace, which can then be used across your Nuxt app and potentially other applications within the same workspace.

Enhancing CI with Modular Builds

On the CI front, Nx’s modular approach makes things much faster. You can configure your CI pipeline to build, test, and deploy only the affected libraries and applications, thanks to Nx’s advanced dependency graph analysis. This results in faster CI runs and more efficient resource utilization.

Sharing Code Between Applications

Nx’s workspace model facilitates code sharing between projects, which is particularly useful in monorepos containing multiple front-end projects. With Nx, sharing UI components, utilities, or services between these applications becomes straightforward.
To share code, simply import the library into your Nuxt and Vue applications as needed. Nx takes care of the rest, ensuring that dependencies are correctly managed and that your applications remain buildable and testable.

Imagine a scenario where your workspace contains a Nuxt application for your public-facing website and a Vue application for an internal tool. You can create a shared library for common UI components, such as buttons, inputs, and modals, and use these components in both applications. This not only reduces duplication but also ensures consistency across your projects.

// Importing a shared UI component in your Nuxt app
import { MyButton } from ‘@my-org/my-shared-ui’;

// Importing the same component in your Vue app
import { MyButton } from ‘@my-org/my-shared-ui’;

Visualizing Your Project Structure

Nx provides a clear overview of your project’s structure and dependencies, making it easier to manage complex applications. The Nx Console extension for VSCode, for instance, offers a graphical interface to visualize and run tasks, enhancing your development experience.

In your workspace, you can run

nx graph

and see the structure of your projects:

Embracing Nx in Your Nuxt Journey

Whether you’re starting a new Nuxt project or looking to enhance an existing one, Nx offers a compelling set of tools and features to streamline your development process. From modularization to caching, the integration of Nx into your Nuxt projects promises a more efficient, scalable, and enjoyable development experience. By embracing Nx’s capabilities in your Nuxt development, you’re not just optimizing your current workflow; you’re future-proofing your development process. As your projects grow and evolve, Nx’s modular architecture and powerful tooling will continue to provide value, making your development experience more enjoyable and productive.

Nx Live With Nuxt Maintainer Daniel Roe

Don’t miss Nx team members Zack and Katerina with Nuxt’s maintainer, Daniel Roe — live!

Learn more

Check out the example repo used in this blog post or one of the links below to learn more:

- 🧠 Nx Docs
- 👩‍💻 Nx GitHub
- 💬 Nx Community
- 📹 Nx Youtube Channel
- 🚀 Speed up your CI

Also, if you liked this, click the 👏and make sure to follow Katerina and Nx on Twitter for more!

Introducing @nx/nuxt: Enhanced Nuxt.js Support in Nx was originally published in Nx Devtools on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

The Nx Docs AI Assistant is a tool designed to provide users with answers straight from the Nx documentation. In this article I will explain how it is built, and how we ensure accuracy and relevance.

In the end of this document I have added a “glossary” of terms that are used throughout this document.

Why have an AI assistant for documentation?

First of all, let’s answer this simple question: why do you need an AI assistant for a documentation site in the first place? Using an AI assistant for documentation search and retrieval can offer a number of benefits for both users and authors. For users, the challenges of navigating through a large volume and density of documentation are alleviated. Unlike static keyword matching, AI enables more personalized and contextual search, allowing for more complex or sophisticated queries beyond simple keywords. This creates a dynamic feedback loop where users can ask follow-up questions, mix and combine documents, and ultimately enjoy an enhanced user experience that goes beyond basic documentation retrieval.

For authors, a docs AI assistant provides valuable insights into user behavior. It can identify the questions users are frequently asking, pointing to areas where more documentation may be needed. Additionally, if the AI consistently provides unsatisfactory or incorrect responses to certain queries, it could highlight unclear or lacking portions of the documentation. This not only allows for targeted improvements but also makes more parts of the documentation easily accessible to users through intelligent linking. Overall, it can enrich user interaction and help with future content strategy.

The Nx Docs AI Assistant Workflow

Overview

In a nutshell, the Nx Docs AI Assistant works in the following way:

1. Split our docs into smaller chunks
2. Create an embedding for each chunk
3. Save all these embeddings in Postgres using pgvector (Supabase!)
4. Get question from the user
5. Create embedding for user’s question
6. Perform a vector similarity search on your database — bring back all the chunks of your documentation that are similar to the user’s question
7. Use the GPT chat completion function. Pass a prompt, the user’s question and the retrieved chunks from the docs. GPT will then try to extract the relevant facts from these chunks, in order to formulate a coherent answer.

This is based on the Web Q&A Tutorial from OpenAI (https://platform.openai.com/docs/tutorials/web-qa-embeddings) and Supabase’s Vector Search example (https://supabase.com/docs/guides/ai/examples/nextjs-vector-search).

It’s important to note here that we are not “training the model on our docs”. The model is pretrained. We are just giving the model parts of our docs which are relevant to the user’s question, and the model creates a coherent answer to the question. It’s basically like pasting in ChatGPT a docs page and asking it “how do I do that?”. Except in this case, we’re first searching our documentation and giving GPT only the relevant parts (more about how we do that later in this article), which it can “read” and extract information from.

Step 1: Preprocessing our docs

Every few days, we run an automated script that will generate embeddings (numeric/vector representations of words and phrases) for our documentation, and store these embeddings in Supabase. As mentioned above, this step has 3 parts:

Split our docs into smaller chunks

Most of this code follows the example from Supabase’s Clippy. It breaks the markdown tree into chunks, it keeps the heading and it also creates a checksum, to keep track of changes.

Ref in the code: https://github.com/nrwl/nx/blob/0197444df5ea906f38f06913b2bc366e04b0acc2/tools/documentation/create-embeddings/src/main.mts#L66

This part is copied from: https://github.com/supabase-community/nextjs-openai-doc-search/blob/main/lib/generate-embeddings.ts

export function processMdxForSearch(content: string) {
  // …
  const mdTree = fromMarkdown(content, {});
  const sectionTrees = splitTreeBy(mdTree, (node) => node.type === 'heading');
  // …
  const sections = sectionTrees.map((tree: any) => {
    const [firstNode] = tree.children;
    const heading =
      firstNode.type === 'heading' ? toString(firstNode) : undefined;
    return {
      content: toMarkdown(tree),
      heading,
      slug,
    };
  });
  return {
    checksum,
    sections,
  };
}

Create an embedding for each chunk

Using `openai.embeddings.create` function with the model “text-embedding-ada-002” we are creating an embedding for each chunk.

Ref in the code:

https://github.com/nrwl/nx/blob/76306f0bedc1297b64da6e58b4f7b9c39711cd82/tools/documentation/create-embeddings/src/main.mts#L314

const embeddingResponse = await openai.embeddings.create({
  model: 'text-embedding-ada-002',
  input,
});

Save all these embeddings in Postgres using pgvector, on Supabase.

Store this embedding in Supabase, in a database that has already been created, following the steps mentioned here:

https://supabase.com/docs/guides/ai/examples/nextjs-vector-search?database-method=dashboard#prepare-the-database

Essentially, we are setting up two PostgreSQL tables on Supabase. Then, we are inserting the embeddings into these tables.

Ref in code: https://github.com/nrwl/nx/blob/master/tools/documentation/create-embeddings/src/main.mts#L327

const { data: pageSection } =
  await supabaseClient
    .from('nods_page_section').insert({
      page_id: page.id,
      slug,
      heading,
      longer_heading,
      content,
      url_partial,
      token_count,
      embedding
    }) // …

Step 2: User query analysis and search

When a user poses a question to the assistant, we calculate the embedding for the user’s question. The way we do that is, again, using openai.embeddings.create function with the model text-embedding-ada-002.

Ref in code: https://github.com/nrwl/nx/blob/76306f0bedc1297b64da6e58b4f7b9c39711cd82/nx-dev/nx-dev/pages/api/query-ai-handler.ts#L58

const embeddingResponse: OpenAI.Embeddings.CreateEmbeddingResponse =
  await openai.embeddings.create({
    model: 'text-embedding-ada-002',
    input: sanitizedQuery + getLastAssistantMessageContent(messages),
  });

The assistant compares the query embedding with these documentation embeddings to identify relevant sections. This comparison is essentially measuring how close the query’s vector is to the documentation vectors. The closer they are, the more related the content. The way this works is that it sends the user’s question embedding to Supabase, to a PostgreSQL function, which runs a vector comparison between the user’s question embedding and the stored embeddings in the table. The PostgreSQL function returns all the similar documentation chunks.

The function that is used uses the dot product between vectors to calculate similarity. For normalized vectors, the dot product is equivalent to cosine similarity. Specifically, when two vectors A and B are normalized (i.e., their magnitudes are each 1), the cosine similarity between them is the same as their dot product. The OpenAI embeddings are normalized to length 1, so cosine similarity and dot product will produce the same results.

Ref in code:

https://github.com/nrwl/nx/blob/76306f0bedc1297b64da6e58b4f7b9c39711cd82/nx-dev/nx-dev/pages/api/query-ai-handler.ts#L70

const { data: pageSections } = await supabaseClient.rpc(
  'match_page_sections',
  {
    embedding,
    // …
  }
);

Step 3: Generating a Response

With the relevant sections (documentation chunks) identified and retrieved, GPT (the generative AI) steps in. Using the relevant sections as context and following a systematic approach, GPT crafts a response.

This approach the AI is instructed to use (in the prompt) is the following:

• Identify CLUES from the query and documentation.
• Deduce REASONING based solely on the provided Nx Documentation.
• EVALUATE its reasoning, ensuring alignment with Nx Documentation.
• Rely on previous messages for contextual continuity.

Ensuring Quality

If there’s no matching section in the documentation for a query, the script throws a “no_results” error. So, after the initial search in the docs (PostgreSQL function), if the search returns no results (no vectors found that are similar enough to the user’s question vector), the process stops, and our Assistant replies that it does not know the answer.

The use of useChat function

It’s necessary here to clarify that we use the useChat (https://sdk.vercel.ai/docs/api-reference/use-chat) function of the Vercel AI SDK. This function, as mentioned in the docs, does the following:

It enables the streaming of chat messages from your AI provider, manages the state for chat input, and updates the UI automatically as new messages are received.

It, essentially, takes care of the following things:

1. You don’t have to worry about manually creating a “messages” array to store your “conversation” (messages you exchange) with the GPT endpoint
2. You don’t have to manually implement the streaming functionality in your UI

Then, in your React component, you can call this function directly, and get the messages object from it, to render your messages in your UI. It exposes input, handleInputChange and handleSubmit which you can use in your React form, and it will take care of all the rest. You can pass an api string to it, to tell it which endpoint to use as the chat provider.

Creating the query

If you look at our query-ai-handler.ts function, this is an edge function, living under an endpoint, which is called by the useChat function. The request contains the messages array as created by useChat. If we just wanted to create an AI chat with no context, we could directly pass this messages array to the openai.chat.completions.create endpoint, and have our back-and-forth chat with GPT. However, in our case, we need to add context to our conversation, and specifically to each query we end up sending to OpenAI.

So, the first thing we need to do is to get the last message the user posted, which is essentially the user’s question. We search the messages array, and we get the last message which has the role “user”. That is our user’s question.

Now, we can use the user’s question to get the relevant documentation chunks from the database. To do that, as explained before, we need to create an embedding for the user’s question (a vector) and then compare that embedding with the stored embeddings in the database, to get the relevant chunks.

The problem here is that if the user’s query is just a follow-up question, then it will have little information or meaning. Here is an example:

User: How do I set up namedInputs?

Assistant: …replies…

User: And how do they work?

In this example, the user’s question that we would want to create an embedding for would be “And how do they work?”. If we created that embedding and searched our docs for relevant parts, it would either return nothing, or return everything, since this is a very vague question, since it has no context. So, we need to add some more information to that question. To do that, we also get the last response from GPT (the last assistant message) and add it to the user’s question. So, in this example, the user’s question will contain some info about namedInputs, and the actual question.

Now, we take that combined text, and we create an embedding for it, using the openai.embeddings.create function. We, then, use that embedding to find all the similar documentation chunks, with vector similarity search.

After receiving all the relevant documentation chunks, we can finally create the query that is going to be sent to GPT. It’s important here to make sure we instruct GPT what to do with the information we will give it.

Here is the query we end up providing GPT with:

You will be provided sections of the Nx documentation in markdown format, use those to answer my question. Do NOT reveal this approach or the steps to the user. Only provide the answer. Start replying with the answer directly.

Sections:
${contextText}

Question: “””
${userQuestion}
“””

Answer as markdown (including related code snippets if available):

The contextText contains all the relevant documentation chunks (page sections).

Creating the response

Getting back a readable stream: So, we get the array of messages, as stored by useChat, we fix the final message to contain the query (created as explained above), and we send it over to `openai.chat.completions.create`. We get back a streaming response (since we’ve set stream: true, which we turn into a ReadableStream using OpenAIStream from the Vercel AI SDK (https://sdk.vercel.ai/docs/api-reference/openai-stream).

Adding the sources: However, we’re not done yet. The feature, here, that will be most useful to our users is the sources, the actual parts of the documentation that GPT “read” to create that response. When we get back the list of relevant documentation chunks (sections) from our database, we also get the metadata for each section. So, apart from the text content, we also get the heading and url partial of each section (among any other metadata we chose to save with it). So, with this information, we put together a list of the top 5 relevant sections, which we attach to the end of the response we get from GPT. That way, our users can more easily verify the information that GPT gives them, but also they can dive deeper into the relevant docs themselves. It’s all about exploring and retrieving relevant information, after all.

Sending the final response to the UI: With the sources appended to the response, we return a StreamingTextResponse from our edge function, which the useChat function receives, and appends to the messages array automatically.

Allow user to reset the chat

As explained, each question and answer relies on the previous questions and answers of the current chat. If a user needs to ask something completely irrelevant or different, we are giving the user the ability to do so by providing a “Clear chat” button, which will reset the chat history, and start clean.

Gathering feedback and evaluating the results

It’s very important to gather feedback from the users and evaluate the results. Any AI assistant is going to give wrong answers, because it does not have the ability to critically evaluate the responses it creates. It relies on things it has read, but not in the way a human relies on them. It generates the next most probable word (see glossary for generative AI below). For that reason, it’s important to do the following things:

1. Inform users that they should always double-check the answers and do not rely 100% on the AI responses
2. Provide users with feedback buttons and/or a feedback form, where they can evaluate whether a response was good or bad. At Nx we do that, and we also associate each button click with the question the user asked, which will give us an idea around which questions the AI gets right or wrong.
3. Have a list of questions that you ask the AI assistant, and evaluate its responses internally. Use these questions as a standard for any changes made in the assistant.

Wrapping up

In this guide, we’ve explored the intricacies of the Nx Docs AI Assistant, an innovative tool that enhances the experience of both users and authors of Nx documentation. From understanding the need for an AI assistant in navigating complex documentation to the detailed workflow of the Nx Docs AI Assistant, we have covered the journey from preprocessing documentation to generating coherent and context-aware responses.

Let’s see at some key takeaways:

Enhanced User Experience: The AI assistant significantly improves user interaction with documentation by offering personalized, context-aware responses to queries. This not only makes information retrieval more efficient but also elevates the overall user experience.

Insights for Authors: By analyzing frequently asked questions and areas where the AI struggles, authors can pinpoint documentation gaps and areas for improvement, ensuring that the Nx documentation is as clear and comprehensive as possible.

OpenAI API utilization: The use of embeddings, vector similarity search, and GPT’s generative AI capabilities demonstrate a sophisticated approach to AI-driven documentation assistance. This blend of technologies ensures that users receive accurate and relevant responses.

Continuous Learning and Improvement: The system’s design includes mechanisms for gathering user feedback and evaluating AI responses, which are crucial for ongoing refinement and enhancement of the assistant’s capabilities.

Transparency and User Trust: By openly communicating the limitations of the AI and encouraging users to verify the information, the system fosters trust and promotes responsible use of AI technology.

Accessibility and Efficiency: The AI assistant makes Nx documentation more accessible and navigable, especially for complex or nuanced queries, thereby saving time and enhancing productivity and developer experience.

Future steps

OpenAI released the Assistants API, which takes the burden of chunking the docs, creating embeddings, storing the docs in a vector database, and querying that database off the shoulders of the developers. This new API offers all these features out of the box, removing the need to create a customized solution, as the one explained above. It’s still in beta, and it remains to be seen how it’s going to evolve, and if it’s going to overcome some burdens it poses at the moment. You can read more about the new Assistants API in this blog post, which contains a detailed demo on how to use it for documentation q&a.

Glossary

Core concepts

I find it useful to start by explaining what some terms — which are going to be used quite a lot throughout this blog post — mean.

Embeddings

What they are

In the context of machine learning, embeddings are a type of representation for text data. Instead of treating words as mere strings of characters, embeddings transform them into vectors (lists of numbers) in a way that captures their meanings. In embeddings, vectors are like digital fingerprints for words or phrases, converting their essence into a series of numbers that can be easily analyzed and compared.

Why they matter

With embeddings, words or phrases with similar meanings end up having vectors that are close to each other, making it easier to compare and identify related content.

Generative AI

What it is

Generative AI, the technology driving the Nx Docs AI Assistant, is a subset of AI that’s trained, not just to classify input data, but to generate new content.

How it works

Generative AI operates like a sophisticated software compiler. Just as a compiler takes in high-level code and translates it into machine instructions, generative AI takes in textual prompts and processes them through layers of neural network operations, resulting in detailed and coherent text outputs. It’s like providing a programmer with a high-level task description, and they write the necessary code to achieve it, except here the ‘programmer’ is the AI, and the ‘code’ is the generated text response.

What Does “Generation” Mean in AI Context?

In AI, especially with natural language processing models, “generation” refers to the process of producing sequences of data, in our case, text. It’s about creating content that wasn’t explicitly in the training data but follows the same patterns and structures.

How Does GPT Predict the Next Word?

For our Nx Docs AI assistant we use GPT. GPT, which stands for “Generative Pre-trained Transformer”, works using a predictive mechanism. At its core, it’s trained to predict the next word in a sentence. When you provide GPT with a prompt, it uses that as a starting point and keeps predicting the next word until it completes the response or reaches a set limit.

It’s like reading a sentence and trying to guess the next word based on what you’ve read so far. GPT does this but by using a massive amount of textual data it has seen during training, enabling it to make highly informed predictions.

Context and Prompting — their role in AI models

Context

In the context of AI, “context” refers to the surrounding information, data, or conditions that provide a framework or background for understanding and interpreting a specific input, ensuring that the AI’s responses or actions are relevant, coherent, and meaningful in a given situation

Prompts

The prompt acts as an initial “seed” that guides the AI’s output. While the AI is trained on vast amounts of text, it relies on the prompt for context. For example, a prompt like “tell me about cats” might result in a broad answer, but “summarize the history of domesticated cats” narrows the model’s focus.

By refining prompts, users can better direct the AI’s response, ensuring the output matches their intent. In essence, the prompt is a tool to direct the AI’s vast capabilities to a desired outcome.

The GPT Chat Completion Roles

System

The “System” role typically sets the “persona” or the “character” of the AI. It gives high-level instructions on how the model should behave during the conversation. We start the instructions with “You are a knowledgeable Nx representative.” We also instruct the model about the format of its answer: “Your answer should be in the form of a Markdown article”. You can read the full instructions on GitHub.

User

The “User” role is straightforward. This is the input from the end-user, which the AI responds to. The user’s query becomes the User role message. This role guides what the AI should be talking about in its response. It’s a direct prompt to the AI to generate a specific answer. In our case, we take the user’s query, and we add it in a longer prompt, which specific steps the model must follow (as explained above). That way, the model focuses on the specific steps we’ve laid out, making it the immediate context for generating the answer. This is one more step towards more accurate answers based on our documentation only. Inside the prompt, which has the instructions, and the user’s query, we always add the context text as well, which are the relevant parts that are retrieved from the Nx Documentation.

Assistant

This role, in the context of OpenAI’s chat models, is the response of the AI. Previous Assistant responses can be included in the chat history to provide context, especially if a conversation has back-and-forth elements. This helps the model generate coherent and contextually relevant responses in a multi-turn conversation.

Learn more

- 🧠 Nx Docs
- 👩‍💻 Nx GitHub
- 💬 Nx Community Slack
- 📹 Nx Youtube Channel
- 🚀 Speed up your CI

Also, if you liked this, click the 👏and make sure to follow Katerina and Nx on Twitter for more!

Nx Docs AI Assistant was originally published in Nx Devtools on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Let me start by saying that I am not an AI expert and some of the things I say here may sound simplistic, but it’s the way that helps me understand them. So, let’s begin.

OpenAI just released the Assistants API, which pretty much simplifies the process of setting up a Q&A system based on a knowledge base for GPT.

To quote the OpenAI docs:

Retrieval augments the Assistant with knowledge from outside its model, such as proprietary product information or documents provided by your users. Once a file is uploaded and passed to the Assistant, OpenAI will automatically chunk your documents, index and store the embeddings, and implement vector search to retrieve relevant content to answer user queries.

This is pretty amazing, if you think that the process of chunking, indexing, storing and vector-searching the embeddings was done separately, with customized solutions.

I have a short section at the end of this document, explaining what embeddings and vectors are. And also a brief explanation on how you would implement a q&A based on a knowledge base without the Assistants API.

The demo

You can check out my Github repo which contains the example which I am going to explain here in detail:

https://github.com/mandarini/openai-assistant-demo

Please spend some time to also go through the README of that repo.

Motivation

Building the Nx AI Assistant was a journey that taught us quite a lot about how to use the OpenAI APIs for chat completions, and embeddings, and gave us a taste on how to interact with LLMs. So it was only natural that I wanted to try out the brand new API that would render some of that work obsolete (at least I think so, I’m no expert).

So, in the demo, which I am going to present in this blog post, I am using the Nx docs, I am uploading them on OpenAI, and then I am adding them in a new assistant. Then, I use this assistant to ask questions about these docs.

Project Overview

I have created a super simple chat interface (ChatGPT helped a lot) that accepts a question from the user, and replies based on the knowledge base of the Assistant.

The logic is the following:

1. Create an assistant: a. Upload your files to OpenAI, and b. Create an Assistant and pass it all the files id’s of the files you uploaded
2. Create a new message thread
3. Create a new message in the message thread with the user’s query
4. Run the thread using the Assistant that was just created
5. Retrieve the run’s result once run is complete
6. Return the messages to the UI

Let’s see these steps in more detail.

Step 1: Creating the assistant

The assistant creation step happens once, and “offline”. You only need to run it again if you want to update your knowledge base. I am not going to cover this in the present blog post.

Uploading the files

The first thing that you need to do is upload all the files that you want to use. In this example, I am uploading the files programmatically, from a local directory, like this:

for (const file of allFileNames) {
…
const oneFile = await openai.files.create({
purpose: 'assistants',
file: fs.createReadStream(filePath),
});
files.push(oneFile);
}

The result of the openai.files.create gives us back, among other metadata, the file’s id. You can see the full list of your uploaded files under https://platform.openai.com/files this URL. Each file can be deleted, you can copy it’s ID or you can manually upload more files. All of these actions can also be achieved programmatically with the Files object and methods.

Creating the assistant

Now, once you have all your files uploaded, and you also have their id’s handy, you can proceed and create your assistant, either programmatically, or through the GUI. Here is how it can be achieved programmatically:

const assistant: OpenAI.Beta.Assistants.Assistant =
await openai.beta.assistants.create({
instructions:
'You are Nx Assistant, a helpful assistant for Nx Dev Tools. Your primary role is to provide accurate and sourced information about Nx Dev Tools. Rely solely on the information in the files you have; do not use external knowledge. If the information is not in the files, respond with "Sorry I cannot help with that".',
model: 'gpt-4–1106-preview',
tools: [{ type: 'retrieval' }],
file_ids: […files.map((file) => file.id)],
});

Of course you can customize the instructions, but make sure to add that you only want your model to rely on the existing knowledge base. The openai.beta.assistants.create function will give us back some metadata about our assistant, including its ID. We can see the list of our assistants and their information (id, etc) under this URL: https://platform.openai.com/assistants

Step 2: Creating a thread

Initialize the thread

The first thing that needs to happen when the chat page is initialized, is for our client to create a message Thread. The message thread represents the conversation between the AI and the user. The command to create a new thread is simple:

await openai.beta.threads.create()

This function will return, among other metadata, also the thread’s id, which we are going to use to run it. This should ideally happen once every session (or once every time the user “resets” the chat).

Add the user’s message to the thread

Once we have the id of our thread, we can pass in that thread the message that the user sends from the chat interface. The user’s question, that is. Let’s take a look at the code:

await openai.beta.threads.messages.create(thread.id, {
role: 'user',
content: userQuery,
});

The role: user represents the (surprise!) user. The role: assistant represents the OpenAI API GPT assistant. The role names are defined in the API.

Step 3: Running the thread

Create a new “run” instance

Now that our thread is ready we can run it. First we need to create a “run” instance for our thread, and pass the id of our assistant to it:

const run = await openai.beta.threads.runs.create(thread.id, {
assistant_id: assistantId as string,
});

This function will return (among other metadata) a run id for this particular run.

Wait for run to complete

Now, this is where it gets tricky. You can read about the run lifecycle in the OpenAI docs: https://platform.openai.com/docs/assistants/how-it-works/runs-and-run-steps

Reading from the above page:

In order to keep the status of your run up to date, you will have to periodically retrieve the Run object. You can check the status of the run each time you retrieve the object to determine what your application should do next. We plan to add support for streaming to make this simpler in the near future.

We need to manually poll our run to see if it has completed. The openai.beta.threads.runs.retrieve(threadId, runId) function returns a status and once the status is completed we can finally call the openai.beta.threads.messages.list(threadId) function to get back a full list of all our messages in the thread.

Here is a simple implementation of the polling logic:

while (timeElapsed < timeout) {
const run = await openai.beta.threads.runs.retrieve(threadId, runId);
if (run.status === 'completed') {
const messagesFromThread: OpenAI.Beta.Threads.Messages.ThreadMessagesPage =
await openai.beta.threads.messages.list(threadId);
resolve({ runResult: run, messages: messagesFromThread });
return;
}
await new Promise((resolve) => setTimeout(resolve, interval));
timeElapsed += interval;
}

Once we get back our result, we can return the array of messages to the front end.

Future Enhancements

Part of the immediate improvement plans is to add a list of sources at the end of each message. This is easy to implement, since each message object contains a list of file id’s that were used for that message to be created. Then, it will be a matter of calling the openai.beta.threads.messages.retrieve function

(https://platform.openai.com/docs/api-reference) and getting the title of that file.

Of course, once streaming is implemented by the API, it should be used instead of polling, and it would make the response appear much faster.

Lots of other improvements could be added, and it’s still to be defined if implementing the assistant programmatically provides benefits over creating a custom GPT (ref: https://www.builder.io/blog/custom-gpt).

Conclusion

OpenAI’s Assistants API represents a significant step forward in making complex AI functionalities more accessible and practical for developers. By integrating a knowledge base directly into an AI assistant, we’re able to create a dynamic, responsive, and highly intelligent system that can provide specific, sourced information on demand. This was possible before, but with custom solutions, by “manually” chunking text and creating embeddings. “Manually” storing them in a vector db and implementing the vector search to return relevant sections according to a user query’s embeddings, to add as context.

The new approach is much simpler and more straightforward, as it comes out-of-the-box with the new API. Questions remain as to whether this approach can leverage issues such as potential downtime, or extra configurations that the other APIs support, but the feature is still in beta, so let’s see what will come next!

Glossary

Core concepts

I find it useful to explain what some terms mean.

Embeddings

What they are

In the context of machine learning, embeddings are a type of representation for text data. Instead of treating words as mere strings of characters, embeddings transform them into vectors (lists of numbers) in a way that captures their meanings. In embeddings, vectors are like digital fingerprints for words or phrases, converting their essence into a series of numbers that can be easily analyzed and compared.

Why they matter

With embeddings, words or phrases with similar meanings end up having vectors that are close to each other, making it easier to compare and identify related content.

Generative AI

What it is

Generative AI, the technology driving the Nx Docs AI Assistant, is a subset of AI that’s trained, not just to classify input data, but to generate new content.

How it works

Generative AI operates like a sophisticated software compiler. Just as a compiler takes in high-level code and translates it into machine instructions, generative AI takes in textual prompts and processes them through layers of neural network operations, resulting in detailed and coherent text outputs. It’s like providing a programmer with a high-level task description, and they write the necessary code to achieve it, except here the ‘programmer’ is the AI, and the ‘code’ is the generated text response.

What Does “Generation” Mean in AI Context?

In AI, especially with natural language processing models, “generation” refers to the process of producing sequences of data, in our case, text. It’s about creating content that wasn’t explicitly in the training data but follows the same patterns and structures.

How Does GPT Predict the Next Word?

GPT, which stands for “Generative Pre-trained Transformer”, works using a predictive mechanism. At its core, it’s trained to predict the next word in a sentence. When you provide GPT with a prompt, it uses that as a starting point and keeps predicting the next word until it completes the response or reaches a set limit.

It’s like reading a sentence and trying to guess the next word based on what you’ve read so far. GPT does this but by using a massive amount of textual data it has seen during training, enabling it to make highly informed predictions.

Links

Github: https://github.com/mandarini/openai-assistant-demo

The live demo: https://openai-assistant.vercel.app/ (which may or may not work because of API limits etc — it’s just a live demo)

Follow me on X: https://twitter.com/psybercity

Follow Nx: https://twitter.com/NxDevTools

In Nx 16.6 we are introducing our new generators for Storybook interaction tests! These new generators replace the default Cypress tests we used to generate along with a project’s Storybook configuration, particularly for those already using Storybook. The intention is that if a user chooses to use Storybook and generate Storybook configuration, to integrate in that experience Storybook Interaction testing, and skip generating Cypress tests, to keep everything in one place, in an integrated experience.

Prefer a video walkthrough? We’ve got you covered

Understanding Storybook Interaction Tests

Interaction tests allow users to verify the functional aspects of UIs. This is done by supplying the initial state of a component, simulating user behavior such as clicks and form entries, and finally checking if the UI and component state update correctly​. Very much like e2e tests are doing.

In Storybook, this workflow occurs in your browser, which makes it easier to debug failures since you’re running tests in the same environment you develop components.

How it works

You write a story to set up the component’s initial state, simulate user behavior using the play function, and then use the test runner to confirm that the component renders correctly and that your interaction tests with the play function pass​. Storybook’s Test runner is a standalone utility — powered by Jest and Playwright — that executes all of your interaction tests, and runs parallel to your Storybook.

Setting Up Storybook Interaction Tests on Nx

You can read our detailed guide on how to set up Storybook interaction tests on Nx, here: https://nx.dev/packages/storybook/documents/storybook-interaction-tests.

Writing Interaction Tests in Storybook

An interaction test is defined inside a play function connected to a story. The story simulates the user’s behavior once it loads in the UI and verifies the underlying logic​.

Under the hood, Storybook’s @storybook/addon-interactions mirrors Testing Library’s user-events API. So, you can use the same queries and assertions that you would use for Testing Library, like we already do with our unit tests.

For complex flows, it can be worthwhile to group sets of related interactions using the step function. This allows you to provide a custom label that describes a set of interactions.

Debugging and Reproducing Errors

Storybook provides an interactive debugger that displays the step-by-step flow of your interactions, and provides UI controls to pause, resume, rewind, and step through each interaction​.

If an error occurs during a story’s play function, it’ll be shown in the interaction addon panel to help with debugging. And since Storybook is a web app, anyone with the URL can reproduce the error with the same detailed information without any additional environment configuration or tooling required​.

Executing and Automating Tests

Storybook only runs the interaction test when you’re viewing a story. Therefore, as a Storybook grows, it becomes unrealistic to review each change manually. The Storybook test-runner automates the process by running all tests for you. This can be executed via the command line or on CI environment​.

What should I choose? Interaction tests or E2E tests?

Setting up interaction tests with Nx and Storybook provides an extra layer of confidence in the functionality of your components. It ensures that they not only look right but also behave correctly in response to user interactions.

Storybook interaction tests provide a unique advantage over traditional e2e tests, especially when considering the development setup. With Storybook already in place, you essentially have a controlled environment set up for each of your components. This allows you to write interaction tests almost immediately, without the overhead of setting up and navigating through a full application environment, as is the case with e2e tests.

Moreover, since Storybook isolates each component, you can ensure that the tests are solely focused on individual component behavior rather than application-level concerns. This results in faster test execution, easier debugging, and more granular feedback during the development process. In essence, with Storybook’s interaction tests, you get many of the benefits of e2e tests but with a setup that’s quicker, more focused, and integrated right into your component development workflow.

Screenshare

Useful Links

• https://storybook.js.org/docs/react/writing-tests/interaction-testing
• https://nx.dev/packages/storybook/documents/storybook-interaction-tests

Learn more

- 🧠 Nx Docs
- 👩‍💻 Nx GitHub
- 💬 Nx Community Slack
- 📹 Nx Youtube Channel
- 🚀 Speed up your CI

Also, if you liked this, click the 👏and make sure to follow Katerina and Nx on Twitter for more!

Storybook Interaction Tests in Nx was originally published in Nx Devtools on Medium, where people are continuing the conversation by highlighting and responding to this story.

The JavaScript ecosystem evolves at a rapid pace, frequently introducing new tools and packages. At Nx, we provide out-of-the-box integrations with the most popular among them so you don’t have to worry when stitching them together. That, however…yes you guessed it… can be a challenging task. There’s just one way to keep up: automation.

We already run a ton of automated testing on our repository to ensure we don’t break anything. But given Nx’s popularity and vast usage across open source and enterprise projects, we want to go a step further: introducing the Nx Ecosystem CI. Inspired by the work done by our friends on the Vite team, the Nx Ecosystem CI is designed to enhance the stability of Nx by testing pre-release versions with projects in the Nx ecosystem.

Inspired by the Vite Ecosystem CI

The Vite Ecosystem CI is an innovative tool that has significantly enhanced the use of Vite. It monitors the compatibility of Vite with various other packages and projects in the ecosystem by running tests against the latest changes in the Vite codebase and the projects it integrates with. This allows the Vite team to catch issues early and maintain a high level of stability, ensuring that developers using Vite can trust that new contributions to either Vite or their project will not result in breaking changes.

This robust testing system is essential because it gives users confidence in Vite’s reliability, encouraging more developers to adopt Vite. It’s a great example of proactive testing in a fast-paced ecosystem and an inspiration for other projects, including Nx. The concept of the Ecosystem CI introduces a framework-agnostic way of testing integrations of one tool with other tools in the ecosystem. It puts together a “syntax” with which tools can easily find the way to test their latest versions with one another.

Nx Ecosystem CI

The Nx Ecosystem CI is a fork of the Vite Ecosystem CI but is tailored specifically for the Nx ecosystem. It’s designed to ensure that Nx maintains its high standards of reliability and compatibility with all our users.

How Nx Ecosystem CI Works

The Nx Ecosystem CI works in the following way:

1. It clones the provided repo which uses Nx
2. It installs the project’s dependencies
3. It runs a number of scripts specified by the project’s author (eg. test, build, e2e)
4. It migrates the repository to the next version of Nx (using nx migrate next)
5. It runs the scripts again
6. It reports the results of the runs to the Nrwl Community Slack in the #nx-ecosystem-ci channel.

The main difference between the Nx Ecosystem CI and the Vite Ecosystem CI is that Nx Ecosystem CI uses the `next` version of Nx as published on npm, rather than cloning and building Nx locally, like Vite does in the Vite Ecosystem CI. This approach ensures that the tests run against the same code that developers are most likely to use in their projects. It also makes it easier for the script to migrate to that version.

At its core, the Nx Ecosystem CI is a set of command-line tools that run tests for a specific or all available suites. Each test suite corresponds to a specific configuration and consists of a set of commands executed in a given repository. The test suite checks for the correct execution of Nx commands, such as build, test, and e2e tests, ensuring that Nx functions as expected in different environments and projects.

Adding a new test suite

To add a new test suite for your project in the Nx Ecosystem CI, you would need to create a new file under the tests directory. The name of this file should reflect the suite it represents, for example, nx-rspack.ts .

The first step is to import the necessary modules and types from utils.ts and types.ts at the top of your file:

import { runInRepo } from '../utils'
import { RunOptions } from '../types'

RunOptions is a type that represents the options for running a test suite. It includes properties such as the repository to test, the branch to use, and the commands to run for building, testing, and performing e2e tests (all optional).

Next, you need to define the test function that accepts the RunOptions. Within this function, you’ll call the runInRepo function, passing in the options as well as any specific properties required for your suite:

Again, using the example of nx-rspack:

export async function test(options: RunOptions) {
    await runInRepo({
        …options,
        repo: 'nrwl/nx-labs',
        branch: 'main',
        build: ['build rspack'],
        test: ['test rspack'],
        e2e: ['e2e rspack-e2e'],
    })
}

In this example, the suite is set up to run on the ‘nrwl/nx-labs’ repository on the main branch. It will run build rspack, test rspack, and e2e rspack-e2e as its build, test, and e2e tests respectively. These commands will be invoked using the package manager used by your repository. So, in the nx-labs case, it will run yarn build rspack in the nrwl/nx-labs repo.

For this reason, adding a new test suite to the Nx Ecosystem CI also requires setting up appropriate scripts in your repository’s package.json file. These scripts provide the commands that will be invoked by your package manager to carry out the build, test, and e2e steps.

Here’s an example of how scripts might be configured in a package.json file for a repository using Nx:

"scripts": {
…
    "build": "nx build",
    "test": "nx test",
    "e2e": "nx e2e"
…
},

These scripts should be set up in such a way that they can be invoked directly by your package manager. For example, in a repository using pnpm, you could run the build script with the command pnpm run build.

When you create your test suite file, you’ll specify these script names in the build, test, and e2e properties of the options object passed to runInRepo.

export async function test(options: RunOptions) {
    await runInRepo({
        …options,
        repo: 'nrwl/nx-labs',
        branch: 'main',
        build: ['build'],
        test: ['test'],
        e2e: ['e2e'],
        })
}

With this setup, the Nx Ecosystem CI will run these scripts in your repository as part of its CI process, or just when you run pnpm test <name-of-suite> locally.

In addition to creating the test suite and setting up the package.json scripts, you will also need to add the name of the new suite to the workflow configuration files in the .github/workflows directory of the Nx Ecosystem CI repository. This suite name should match the filename of your test suite script.

There are two workflow files you’ll need to update:

• .github/workflows/ecosystem-ci-selected.yml
• .github/workflows/ecosystem-ci.yml

In .github/workflows/ecosystem-ci.yml you’ll find a strategy section with a matrix property. This matrix property specifies an array of suite names for the workflow to run. You’ll need to add your new suite name to this array.

Here’s what the strategy section might look like after adding a new suite named my-new-suite:

strategy:
  matrix:
   suite:
     - ….
     - nx-remix
     - nx-rspack
     - …
     - my-new-suite # your new suite

By adding your suite name to this file, you’re instructing the Nx Ecosystem CI to include your suite in its test runs.

In addition to the .github/workflows/ecosystem-ci.yml file, you also need to include your suite in the .github/workflows/ecosystem-ci-selected.yml file.

The ecosystem-ci-selected.yml workflow is designed to allow manual selection of a test suite to run. To add a suite to this workflow, you add it to the options array under workflow_dispatch > inputs > suite. Here’s what it might look like with a new suite named my-new-suite:

on:
  workflow_dispatch:
    inputs:
      suite:
        description: "testsuite to run"
        required: true
        type: choice
        options:
          - ….
          - nx-remix
          - nx-rspack
          - …
          - my-new-suite # your new suite

Adding your suite name to this file allows it to be manually selected for a test run via the GitHub Actions interface. This manual selection process provides additional flexibility and control over the testing process, allowing you to run individual suites as needed.

Reporting the results

The Nx Ecosystem CI is integrated with GitHub Actions, which helps with its automation process. The CI pipeline is scheduled to run three times a week (on Mondays, Wednesdays, and Fridays) and can also be triggered manually. The workflow uses a matrix strategy to run the suites in parallel. Each suite is given a big amount of memory, and the pipeline is configured with a long timeout, meaning that even if one suite encounters an error, the rest will continue to run. This ensures that we get comprehensive feedback on the health of all the test suites, regardless of individual failures. Once the test suites run, Github sends a message to the Nrwl Community Slack #nx-ecosystem-ci channel with the status of each suite, enabling the team and the community to view the results. Each result points to the Nx tag that was used, and also the job logs on GitHub.

Here is an example of a test run:

https://github.com/nrwl/nx-ecosystem-ci/actions/runs/5144215568/jobs/9260227337

Benefits for the Nx Community

The introduction of the Nx Ecosystem CI is a significant win for both the Nx team and the Nx developer community. For us, it enables us to catch issues early, often before they affect most end-users. By running tests against the `next` version of Nx, we can ensure that any changes we make are compatible with the various configurations that our users maintain.

For developers using Nx, the Nx Ecosystem CI offers reassurance that the tools they rely on are being actively tested and maintained. This provides confidence in the stability of Nx and its plugins.

Ecosystem CI as part of the Open Source community

We are not alone in recognizing the value of an Ecosystem CI approach. Other OSS projects including Nuxt, VueJs, VolarJs, and Rspack, have also adopted this strategy. You can explore their implementations here:

• Nuxt: https://github.com/nuxt/ecosystem-ci
• VueJs: https://github.com/vuejs/ecosystem-ci
• VolarJs: https://github.com/volarjs/ecosystem-ci
• Rspack: https://github.com/web-infra-dev/rspack-ecosystem-ci
• Storybook: https://storybook.js.org/blog/storybook-ecosystem-ci/

As we continue to improve and refine the Nx Ecosystem CI, we remain committed to the goal of making Nx a reliable and integral part of your development workflow. If you’re an open-source maintainer, you can create your own Ecosystem CI either from scratch (like Storybook) or by cloning the Vite Ecosystem CI. If your project uses Nx, you can easily add a new test suite for it.

Learn more

- 🧠 Nx Docs
- 👩‍💻 Nx GitHub
- 💬 Nx Community Slack
- 📹 Nx Youtube Channel
- 🚀 Speed up your CI

Also, if you liked this, click the 👏and make sure to follow Katerina and Nx on Twitter for more!

Introducing Nx Ecosystem CI was originally published in Nx Devtools on Medium, where people are continuing the conversation by highlighting and responding to this story.

Turn your phone (which has access to sensors) into a remote control (a Wii Remote) for an application that’s running on your computer (which — usually — does not have motion sensors) — using the web

Intro — When and why

I wanted to experiment with some web technologies and web APIs this summer (as if I was not stressed enough), so I decided to revisit (and rebuild for the better) an old idea of mine. The concept of turning my phone into a gamepad (or, more accurately, a Wii Remote of sorts), and using it to control some graphics on a web application running on my computer. I know that this idea is not super innovative, and I’m sure it has been executed before, maybe even in a better way. But still, I wanted to play around with sensors, data streams, and graphics.

I had toyed with that idea back in 2015, when I first built a “move your phone and watch a cube follow that motion on the screen, on a different machine”. I explain how I did it in this (very old, please don’t judge too much) blog post of mine, accompanied by a video. I revisited the idea in 2018, where I demoed a version of this idea, in Vienna, on May 18th, 2018, at the WeAreDevelopers conference. This time, I had decided to use solely web technologies and APIs. Here’s the YouTube link of my talk!

Now, in 2022, I decided to revisit this idea. I rebuilt the applications from scratch, and added a number of features to make them more user friendly, and generally improved the whole thing. I’ve also added documentation and instructions on how to play the game, and how to build it, too. All you need is Chrome on your phone (for the “gamepad”), and another machine with a web browser (computer, phone, tablet, whatever — the larger the screen the better) to display the actual game to be controlled.

Purpose and achievements

The purpose of this game|experiment|demo is to showcase the usage of the phone sensors through the web platform. Then, to suggest some ways these sensor data can be used to create interactive experiences on the web. And, most importantly, to provide a visualization of the sensor readings!

Sensors are already used in a wide variety of applications. For native applications, of course, sensors are a very common feature, and most applications use some kind of sensor in some way (whether it’s a motion sensor or an environmental sensor, or a combination of sensor data). We don’t see that as often on web applications, however. I don’t have any numbers to back up my claim, it’s just from pure observation. I may be wrong. It does not really matter, to be honest. :P

Sensor Data on the Web

Sensor data is exposed to the Open Web Platform. There are a number of Sensor APIs for the web that access these data. In this example we are mostly accessing sensor data through the Generic Sensor API. I find it necessary here to include the abstract of the Generic Sensor API specification:

“This specification defines a framework for exposing sensor data to the Open Web Platform in a consistent way. It does so by defining a blueprint for writing specifications of concrete sensors along with an abstract Sensor interface that can be extended to accommodate different sensor types.”

Types of Sensors

The following section copies parts of the Generic Sensor API specification, taken from here: https://www.w3.org/TR/generic-sensor/. You will see me linking this page a lot in this article.

High level — Low level

There are what we call “low level” sensors and “high level” sensors. The low level sensors are sensors which “are characterized by their implementation”. That means that they provide readings of an actual sensor chip, for example the Gyroscope. The high level sensors are “named after their readings, regardless of the implementation”. For example, they can be the result of algorithms applied to low-level sensors, like, for instance, the pedometer.

Available sensors

• Environmental

Sensors that measure physical properties of the environment they are in, and these are the Ambient Light Sensor, the Proximity Sensor and the Magnetometer

• Inertial

Sensors based on inertia and relevant measuring concepts. Such sensors are the Accelerometer and the Gyroscope.

• Fusion Sensors

This group of sensors provide measurements that are ‘fused together’ by fusion algorithms. The fusion algorithms might require data from one or multiple sources.

How the Generic Sensor API definition works

The Generic Sensor API provides a generic sensor interface which each sensor extends. The interface accepts some inputs and returns some outputs. It also exposes methods to start and stop the sensor, as well as exposes event handlers for the sensors. It defines a lifecycle as well. You can read all the details here.

Compatibility

Here you can see the Sensor interface browser availability.

In Chrome, for the sensors to work, you may have to enable some flags, to give access to the browser. These flags, on Google Chrome, are the following:

• chrome://flags/#enable-generic-sensor
• chrome://flags/#enable-generic-sensor-extra-classes

This is an interesting read that explains the implementation of the sensors in Chromium.

Safeguards

In any case, you can check the compatibility by calling the sensor. If you’re getting back readings, you are OK. If you are NOT getting back readings, then there may be a number of issues:

1. Your device has the sensor but your browser does not support the sensor
2. Your browser supports the sensor but your device does not have the sensor
3. Your device has the sensor, your browser supports the sensor, but the user did not give permission

The solutions to these issues are the following:

1. Use try — catch when instantiating the sensor object
2. Check for the sensor existence in `window`
3. Use the Permissions API to ask for the user’s permission

Threats

Of course, using device sensors, and gaining access to device sensors, has many security and privacy implications. The more information and data you have about a device, the easier that device becomes trackable, traceable, exploitable. Some common threats are listed here. Briefly:

• Location Tracking
• Keystroke Monitoring
• Device Fingerprinting
• User Identifying
• Eavesdropping (yes, with the gyroscope)

Safeguards

Again, copying from the docs (https://www.w3.org/TR/generic-sensor/#mitigation-strategies):

• Use https
• Ask for user permission using the Permissions API
• The sensors only work on visible and focused elements
• Sampling frequency and accuracy control
• Always inform the user of a sensor API usage

Why is this important? Why do I need it?

This is the million dollar question. I find the use of sensors on the web, apart from exciting, extremely helpful. It opens up lots of possibilities, and brings the web experience even closer to the native experience. Sensors are tied to our mobile phones, and the way we think about our mobile apps. From device orientation, to pedometers, to activity tracking, geolocation, brightness adjustment, and the list goes on. All these features are available to the web, and the way we build our apps and our PWAs can be even more enhanced when we provide the user with the full native experience that the sensor readings offer.

Possible applications

This is just some brainstorming, I cannot wait to hear your ideas:

• Adjust colors & theme according to light
• Create games
• Native-like interactions and events
• Experiment with potential applications in navigation
• Build your own fusion sensors

The game I created

I created a simple game, that takes the readings of a number of different sensors from a mobile device, and sends these data (through a websocket server) to an application running on another machine (preferably a computer of a device with a larger screen), so that it can control some animations.

This is definitely not an everyday usage example, but it certainly visualizes the readings these sensors expose to the web platform. So, though playing this game, the user can see in a visual way the data they can access if they start using the Generic Sensor API on the web.

The game parts

The game consists of two parts. The “gamepad” or the “Wii Remote”, and the “Dashboard of Activities” or “Playground”. You can access the application here:

https://ws-pakotinia.web.app/

Or here:

https://ws-pakotinia.firebaseapp.com/

If you are on your phone, click the “Gamepad” button, if you’re on your computer, click the “Playground” button.

Please, read the instructions before playing. They will clear up any questions you may have.

Gamepad

The “Gamepad” is your mobile device. It works best if you use Google Chrome, and you enable the flags, as instructed in the intro screen. Once you “log in” the game, you can start moving your phone, to see the visualization of the movements on the dashboard. Read the instructions if something is unclear.

Dashboard of activities

The “Dashboard of Activities” or the “Playground” is a collection of 6 different games you can play. Read the instructions carefully, please.

Challenges

Types

The main challenge I faced while building this project, was that I wanted to use TypeScript, so I needed all the types for the sensors I would be using. Kenneth has created the https://@types/w3c-generic-sensor package. This lacked the types for the AmbientLightSensor, so I added them :). For some reason, I am so proud of that PR. I’ve written more complicated code in my life, I’m sure, but that specific one, just the thought that it’s used by so many people, puts a grin on my face.

Polyfills

Of course, Kenneth has also created the motion-sensors-polyfill, as well. So that was a life saver, too.

Limitations

Of course, there are limitations, both to building this game, and to using these sensors, and to integrating sensors to your web application. I’m listing just a few that I thought of (or that I ran into):

• not all devices have all sensors
• not all devices have the same frequency in obtaining data
• not all devices sensors have the same sensitivity
• not all browsers use the same coordinate system
• even if a device has a sensor, the browser might not support reading it (eg. light)!

Accessibility

Make sure, if you are going to integrate sensors to your web applications, that you provide alternative ways of interactions, and consider the accessibility implications and limitations.

Where can I find your game and play it?

Here is the game:

https://ws-pakotinia.web.app/

Or here:

https://ws-pakotinia.firebaseapp.com/

And here are the docs/instructions: https://mandarini.github.io/sensors-demo/

Here is the repository for the code:

https://github.com/mandarini/sensors-demo

Further reading and references

This is the most important section of this article, since this article does not go deep into explaining sensors. It just explains what I did, and it points you to the detailed explanation of how I created this demo.

So, here go some links for you:

• W3c Generic Sensor API: https://www.w3.org/TR/generic-sensor/
• Sensors for the web: https://web.dev/generic-sensor/
• Intel’s demo for the Generic Sensor API: https://intel.github.io/generic-sensor-demos/
• My Demo: https://ws-pakotinia.web.app/
• My Documentation / Demo explanation: https://mandarini.github.io/sensors-demo/

Now what?

I’d love to speak more about this, so, yes, reach out to me!

I also want to hear your feedback, and your suggestions for more implementations of the Sensors in our web applications!

If I forgot to give credit to anyone, please let me know and I’ll update this with the missing credit.

And, follow me on twitter, and visit my website: https://psyber.city

tl;dr: Katerina speaks about her mental health, making analogies with Stranger Things. The reason she shares this is because maybe more people are having the same experiences, and it’s nice to know you’re not alone. Also, it’s good to know that people who are functional and happy and active may still suffer sometimes.

A few weeks ago I was at the after-party of a wedding. The wedding was of an old friend of mine, and the party was very enjoyable. It was held at a beautiful beach on a beautiful Greek island. There was good food, music, dancing, friends. A sort of ideal setting. I was having a lot of fun. It was late, already, and some friends were sitting on sunbeds on the beach. I went to join them, I sat on the edge of a sunbed, and sort of stopped. Negative thoughts started filling my mind, guilt, regret, for anything and for everything. It was as if the lights faded and the music stopped or was muffled, my friends disappeared and I was suddenly alone in this bad bad place. It must’ve shown on my face, because a friend who was sitting across from me shouted:

“Hey, Katerina, get out of the Upside Down”.

I jerked, lifted my stare, looked into her eyes, and smiled.

“That’s where I was”.

(thank you DALL-E for the — perfect really — imagery)

I think I speak more about my mental health as I grow older. I don’t know when I first met depression, but it was before I got PTSD. So it must not be PTSD-induced, my depression. Not strictly, at least. It started off as a panic attack. It must’ve been 2007. I lost control of my mind and was certain I was dying. It went away, then it visited me again in 2008, and 2010. The panic attack.

I think I started seeing my therapist, my first therapist, in 2009. I think it was after I told my mother about the panic attack. Or my sadness. I’m not sure which of the two.

In-between, there were moments of deep sadness and guilt, but I never paid too much attention to these. It was just the way it was. But it mainly expressed itself as a panic attack. My therapist tells me it’s the lack of a sense of security with my Self, which comes from my deep attachment to my parents, which I blame on my only-child-ness. I blame it on my inability to accept me as who I am. As not the best person in the world.

Some negative memories Vecna can grab onto

I think when I realized I’m not safe, that’s when everything started spilling out. A negative memory.

In 2006 I was chased by a young man, who was half naked, stroking his erection. I ran to escape the rape, and was hit by a car. Lightly, I just got a bruise. I ran into a shop to ask for help, and the shop-owner asked me if I’m Greek.

In 2008 it must have been, I was assaulted by a group of young men, who touched me on places that should not be touched and shouted vulgarities at me, and spat at me (literally). It was in the middle of a busy street, I was shouting for help, but nobody so much as turned their heads.

In 2011 I was strangled almost to death outside my house by a petty thief. I passed out due to lack of oxygen, and that’s when he released my neck. He must’ve thought I had died. Before dying (I call it dying because that was almost what it was) I had a vision of my mother, happily waving at me from the living-room window. The most beautiful, happy and serene face I have seen in my life. The serenity engulfed me, until I stopped being for a few moments.

Naturally, PTSD enhanced the depression. The first few months I could not walk alone. It was in 2013 that I stopped being 100% functional due to the panic attacks. I had panic attacks almost daily, and I had to go to the hospital, so that I felt I was in a safe place, where if I stopped breathing they would do something. That was the way the panic would always express itself after the 2011 event. It was the fear of not being able to breathe.

Cognitive Behavioral Therapy sort of worked, at least it made me sort of functional, to be able to make it through my Master’s and the essential social situations which I felt compelled I should attend to. But the monster was inside me. I was having a daily fight with my body. My Self. I felt my body like a prison, like this prison that’s keeping me from being carefree and happy.

Non-functionality

In 2016 was when I stopped being functional. I could not get out of the house. I could not move, I could not walk, I could not let myself feel tired. That’s when I also changed therapists. My first session with my new therapist, I barely made it there. My mother walked me. When I entered his office I started crying. He asked me what I wanted. I told him I wanted to see light at the end of the tunnel.

He helped me see light. I’m functional now. And I’m happy more than half the time. And I know to hide it when I’m not. That’s what’s killing me, right? Hiding my struggle.

What I tell my therapist, and what I tell my friends, is that depression is there. It never really leaves you. But you sort of learn to manage it. You sort of learn its tricks and you handle it in a way to not let it completely destroy your life. You live with it, and you know how to battle it when it’s getting stronger. It’s a part of what makes me, me.

The social aspect

I was watching Stranger Things the other day, the final season. In that season they sort of make it crystal clear that the monster is depression (guilt, PTSD, remorse). And I like the imagery of a whole group of people — a whole support group — fighting it. Maybe that’s the only way it can really go away. I was not lucky to have many people on my side. My parents and some friends were on my side, but a bit oblivious, or uneducated in this matter. I was surprised later to understand that my parents had given me the two main weapons against depression that I own. Writing, and walking. Unfortunately, other friends were not really supportive back then. When I confront them about it now, they tell me they did know what I was going through. I was not really open about it. I don’t blame them. You could see I had moments where I was not well, but all other moments I was playing normal. In reality, I was not myself.

I had a number of coping mechanisms, which made me act not-normal, and made me act in a peculiar way. I was making sure not to get tired. Not to drink alcohol or any other substance that may make me feel dizzy or reduce my ability to be in control. I was making sure not to run or get an elevated heart-rate so as not to mistake it with anxiety. I was making sure not to be very far away from home (a safe place) so that I could easily retreat there, should I need to have a full-blown panic attack and nobody noticing. And of course I should be able to retreat alone. So that nobody would understand I am unwell (or weak).

The problem was that part of my social circle was a little mean about it all. The thing that still puzzles me is that they could tell something was wrong, so why be mean to someone who looks unwell. I think they did not know how to handle it. So some of them gave me hell about not drinking, not staying out late, not being able to run or get tired. Hell. Again, I don’t blame them, they didn’t know, I was hiding my weakness. One of the worst things that someone had told me was “I cannot hang out with you when you are not well”. I tried to act pleasant, because I didn’t want to impose and force my “unpleasantness” onto anyone.

The lone wolf

So, as always, I was alone. And sometimes, being this lone wolf, this lone soldier, made me feel powerful. My partner never gave me hell about any of this shit, so that was nice. Then my friends started getting depressed and having panic attacks, and we could share bad experiences, finally. The thing is, in Stranger Things, there’s a whole group of people collectively fighting a collective depression. I wish that were the case. But it’s not very realistic. Since, even if you have a support group, still it’s you against yourself, in the end. It’s nice to have a “Mike” next to you, who’s usually oblivious of what’s going on deep inside, but they still want to support you, regardless. By just sort of being “there”. And nothing more. But even if you don’t have that “Mike”, there’s still a way out of the Upside Down. It just takes longer, maybe. I don’t know if it would have taken me less time with the right support group. Maybe it would not. Anyway.

Tainted moments

Moments can be tainted. By a sudden grip of a bad feeling, a sudden recollection of a bad memory, an unexpected trigger of the PTSD. Imagine a perfect moment. Laying in bed at night, next to my partner, my cats kneading my belly. Sitting on the couch, after a nice, tasty lunch, it’s summer, 40 degrees, Sunday, I have nothing to do, and I’m just relaxing. These moments, these moments in these safe places, can be darkened. The Stranger Things imagery conveys that feeling completely. Imagine Max in that scene in the Snow Ball. Everything was pretty and fun. And suddenly, she starts seeing these particles, sounds are distorted, and everything darkens. That’s what happens. That’s exactly what happens.

When I first started experiencing panic attacks, my greatest fear was the unpredictability of when they were going to hit. I don’t know if I would call them panic attacks now, even though they were panic attacks. I am trying to think of a better term, because it was panic indeed, but the trigger of the panic was not anxiety, but it was the deeply rooted depression. And the feeling of desperation that comes with depression. The feeling that all’s lost and you cannot escape. You cannot escape your skin, you cannot escape yourself, you cannot escape your body, you are infected, you are tainted. It’s going to get you. It’s there. It’s just waiting for the right moment, the moment you’re most vulnerable. Or maybe the moment you don’t believe it’s going to hit you, the moment you least expect it.

Fear as the master of all

And then fear becomes the master of all moments. Because all beautiful moments are susceptible to being tainted and destroyed, and you are susceptible to being destroyed at any moment. And during those beautiful moments is when you fear the most. Because you fear that this is when it will hurt the most for it to get you. This is when the damage will be the maximum.

And you start, slowly, to not be able to distinguish between excitement and happiness, and fear, and anxiety and pain, and panic. Any intense feeling can be all, so it’s panic, so it’s suffocation, so it’s fear, so it’s depression. Good news and bad news have the same effect on the body, the excitement fires similar neurons with anxiety. And sometimes you cannot tell which is which, so you give in to anxiety. And you’re alone.

That feeling of being alone in all this, is the most crippling feeling of all. You cannot really convey this to anyone. And if you convey this to anyone, then you feel weak. And you burn bridges or you pretend to be functional and smiling, to just cut the people out. Because you’re alone. Others don’t understand. It’s you who’s tainted by this. It’s you who’s infected. It’s got you (the Mind Flayer). Others don’t have these bad experiences that depression feeds upon. Others don’t have a panic attack to remember and fear. Or someone killing them. Or someone chasing them. You’re all alone. Because it’s you versus your mind after all. So, you feel even more isolated.

Therapy and loving my Self

At this point you think “why don’t you get therapy”. I’ve been in therapy for 13 years. Therapy is what helped me make it through, and therapy is what has helped me have a functional life. Sometimes I think that maybe I should have tried some medication, and maybe a therapist should have suggested some medication. For some reason nobody suggested medication, and for many years I was not even 100% sincere with my therapists about how bad the situation was. I was too proud. I was taught to be a “soldier”. And that’s the worst fallacy that will delay the ability to cope. The determination to remain proud and strong. And not yield. But you have to yield, you have to admit how hard it is, you have to open up.

I started being more able to cope, and started seeing light, after 7 years of therapy, and after changing therapists. And the reason why that happened was that I hit the bottom. I could not move, I could not leave my bed, I could not leave my parents house, without thinking I will die. My life was non-existent and I was just surviving. And that’s when I really started gradually admitting all of my weaknesses to my new therapist. And that’s when I started to really believe I can fight Vecna.

It was not until 2 years ago that I started admitting my worst deeds. To myself first, to my therapist afterwards. Describing all the bad things I have done in my life, and all the bad things I continue to do. Saying how I used to feel like the worst person in the world. And the most cursed, too (why me? etc). And after I started accepting all the things that make me, me (all the bad, and the good, and the not so bad, and the not so good), after that, then I started being able to share my shortcomings and my weaknesses with friends, too. And standing up for my mental health issues, and my disability to cope sometimes. And laugh about it in the end. Because I do make me laugh sometimes, with all the obstacles that I am setting up against me. All the little things that Vecna can grab onto and get hold of me.

Ariana and the savage

Last week my PTSD got retriggered really intensely. An event took place that was almost identical to my strangulation, one block away from my event. It was a bad week, with nightmares. I went to the police to check if it was the same person, because they arrested someone, it was not him. Then I heard that a past stalker of mine was asking about me. Another batch of nightmares. These people, my almost-killer, my stalkers, they almost make my life unlivable sometimes. So naturally I wish their lives to be unlivable. Or non-existent. :)

As Ariana says “been through some bad shit, I should be a sad bitch — who would have thought it’d turn me to a savage?”. I’ve been unlucky, but what the hell. I don’t want to look like I’m using my mental health as a means of getting away with anything. On the contrary, it sort of made me into a badass bitch. I say bring it on, and I know that since I’ve coped with all these things, there’s really nothing I cannot face. Really, I’ve become the lone soldier I was taught to be when I was little.

it sort of made me into a badass bitch

Vecna as my furry little friend

Vecna is there, I feel him. And I know that he will taint more of my moments. I will visit the Upside Down again. I will see the little particles, the sound will be distorted, the light will fade, again. But I am not afraid of it any more. It’s part of me, part of my life, and part of the world around me, and everyone’s world. I know that I can escape it, because I have the memory of me escaping it in the past. And I have the tools I need to escape it. But the most comforting thought is that this, Vecna, the Upside Down, the Shadow Monster, the Mind Flayer, are all part of me. And I embrace them as such.

So, yeah, I guess, bring it on! :)

Tainted Moments — or “Hello Vecna my old friend” was originally published in fileas. on Medium, where people are continuing the conversation by highlighting and responding to this story.

Vite for Storybook in your Nx workspace

Vite is a build tool that ensures faster load times, faster updates, smaller server start times, and more efficient bundling. As described in the docs, it consists of a dev server using ES modules and bundling using Rollup. Starting with Storybook 6.3, Storybook announced the community-led project for Vite support on Storybook, Storybook Vite builder. You can also take a look at this comparison of Storybook performance when using Webpack vs Vite.

You can take advantage of Vite’s speed in Storybook right now. We are going to be following the installation guide of the Storybook Vite builder, and applying the steps for an Nx Storybook setup.

How to use Vite for existing Storybook configurations

Here is a repo with the changes.

You can easily add Storybook configuration to your project (application or library) using the Storybook configuration generator for Nx. This will generate the Storybook configuration files for you, and in the project’s .storybook/main.js it will set the builder to webpack5. If your project is using Angular or React, our generator will also generate Stories for you (*.stories.*) based on your components and your components’ inputs/props.

After you have generated your Storybook configuration for your project, you can follow the steps described above to switch to Vite.

If you already have a project in your Nx workspace that has Storybook configured, here are the steps you need to follow to switch to Vite for Storybook:

1. First, you need to install the required dependencies:

yarn add -D vite @storybook/builder-vite

or

npm i -D vite @storybook/builder-vite

2. In your project’s .storybook/main.js file (eg.apps/my-app/.storybook/main.js) change the builder value to @storybook/builder-vite .

You also need to set the Vite configuration, to correctly resolve the paths of your workspace.

For that you need to use the viteFinal function, as described here, and add the vite-tsconfig-paths plugin in the plugins array of the Vite configuration.

The result will look like this:

// apps/my-app/.storybook/main.js

const rootMain = require(‘../../../.storybook/main’);
const { mergeConfig } = require('vite');
const viteTsConfigPaths = require('vite-tsconfig-paths').default;

module.exports = {

  …rootMain,

  core: { …rootMain.core, builder: ‘@storybook/builder-vite’ },

  stories: [

    …rootMain.stories,

    ‘../src/app/**/*.stories.mdx’,

    ‘../src/app/**/*.stories.@(js|jsx|ts|tsx)’,

  ],

  addons: […rootMain.addons, ‘@nrwl/react/plugins/storybook’],

  async viteFinal(config, { configType }) {    
      return mergeConfig(config, {      
          plugins: [            
              viteTsConfigPaths({          
                  root: '../../../',
              }),      
          ],    
      });  
  },

};

3. Then, just run Storybook for your project and you will see how it’s now using Vite instead!

nx storybook my-app

4. Observe the console for the nice Vite logs

SWC for Storybook in your Nx workspace

SWC (speedy web compiler) is a compiler written in Rust that can be used for both compilation and bundling.

Nx supports SWC. Also, the Next.js compiler, starting with version 12, uses SWC. So, if you’re using SWC in your project, or if you have a Next.js application, then you can use SWC for your Storybook as well.

How to use SWC for existing Storybook configurations

Here is a repo with the changes.

Storybook supports SWC using the storybook-addon-swc addon. If you want to use SWC with Storybook, please read the documentation.

The steps you need to follow to switch to SWC are the following:

1. Install the addon:

yarn add -D storybook-addon-swc

or

npm i -D storybook-addon-swc

2. In your project level .storybook/main.js, in the addons array, add the storybook-addon-swc addon.

Next.js 12, Storybook, Nx and SWC

Here is a repo with the changes.

If you’re using Next.js, you should also add the storybook-addon-next. You can read more in the documentation.

Here are the steps you can follow to add this addon:

1. Install the addon:

yarn add -D storybook-addon-next

or

npm i -D storybook-addon-next

2. In your project level .storybook/main.js, in the addons array, add the storybook-addon-next addon like this:

const rootMain = require(‘../../../.storybook/main’);
const path = require(‘path’);

module.exports = {

  …

  addons: [

    …

    ‘storybook-addon-swc’,

    {

      name: ‘storybook-addon-next’,

      options: {

        nextConfigPath: path.resolve(__dirname, ‘../next.config.js’),

      },

    },

  ],

  …

};

SWC for new Storybook configurations

Nx will generate Storybook configured with SWC if you use SWC as a compiler to your build target in your project.json, in your project’s configuration, or if you use the Next.js @nrwl/next:buildbuilder. If you’re generating Storybook configuration for a Next.js application (one that uses @nrwl/next:build), then Nx will make sure to add the storybook-addon-swc and the storybook-addon-next addons to your project’s .storybook/main.js or .storybook/main.ts.

Conclusion

Nx offers full support for Vite and SWC with Storybook, and the generators will make sure the transition is seamless and easy. So, go ahead and speed up your Storybook!

We would love for you to try it out and let us know what you think!

Also, make sure you don’t miss anything by

• Following us on Twitter, and
• Subscribe to the YouTube Channel for more information on Angular, React, Nx, and more!
• Subscribing to our newsletter!

As always, if you are looking for enterprise consulting, training and support, you can find out more about how we work with our clients here.

Speed up Storybook with Vite and SWC — with the help of Nx was originally published in Nx Devtools on Medium, where people are continuing the conversation by highlighting and responding to this story.