Article: If Architectural Experimentation Is So Great, Why Aren’t You Doing It? - Related to experimentation, send, a, instrument, platform

Article: If Architectural Experimentation Is So Great, Why Aren’t You Doing It?

Key Takeaways Selling yourself and your stakeholders on doing architectural experiments is hard, despite the significant benefits of this approach; you like to think that your decisions are good but when it comes to architecture, you don’t know what you don’t know.

Stakeholders don’t like to spend money on things they see as superfluous, and they usually see running experiments as simply "playing around". You have to show them that experimentation saves money in the long run by making more effective-informed decisions.

These advanced decisions also reduce the overall amount of work you need to do by reducing costly rework.

You may think that you are already experimenting by doing Proofs of Concept (POCs). Architectural experiments and POCs have different purposes. A POC helps validate that a business opportunity is worth pursuing, while an architectural experiment tests some parts of the solution to validate that it will support business goals.

Sometimes, architectural experiments need to be run in the customer’s environment because there is no way to simulate real-world conditions. This sounds frightening, but techniques can be used to roll back the experiments quickly if they start to go badly.

As we stated in a previous article, being wrong is sometimes inevitable in software architecting; if you are never wrong, you are not challenging yourself enough, and you are not learning. The essential thing is to test our decisions as much as possible with experiments that challenge our assumptions and to construct the system in such a way that when our decisions are incorrect the system does not fail catastrophically.

Architectural experimentation sounds like a great idea, yet it does not seem to be used very frequently. In this article, we will explore some of the reasons why teams don’t use this powerful tool more often, and what they can do about leveraging that tool for successful outcomes.

First, selling architectural experimentation to yourself is hard.

After all, you probably already feel that you don’t have enough time to do the work you need to do, so how are you going to find time to run experiments?

You need to experiment for a simple reason: you don’t know what the solution needs to be because you don’t know what you don’t know. This is an uncomfortable feeling that no one really wants to talk about. Bringing these issues into the open stimulates healthy discussion that shape the architecture, but before you can have them you need data.

One of the forces to overcome in these discussions is confirmation bias, or the belief that you already know what the solution is. Experimentation helps you to challenge your assumptions to reach a enhanced solution. The problem is, as the saying goes, "the truth will set you free, but first it will make you miserable". Examples of this include:

Experimentation may expose that solutions that have worked for you in the past may not work for the system you are working on now.

It may expose you to the fact that some "enterprise standards" won’t work for your problem, forcing you to explain why you aren’t using them.

It may expose that some assertions made by "experts" or crucial stakeholders are not true.

Let’s consider a typical situation: you have made a commitment to deliver an MVP, although the scope is usually at least a little "flexible" or "elastic"; the scope is always a compromise. But the scope is also, usually, more optimistic and you rarely have the resources to confidently achieve it. From an architectural perspective you have to make decisions, but you don’t have enough information to be completely confident in them; you are making a lot of assumptions.

You could, and usually do, hope that your architectural decisions are correct and simply focus on delivering the MVP. If you are wrong, the failure could be catastrophic. If you are willing to take this risk you may want to keep your resumé updated.

Your alternative is to take out an "insurance policy" of sorts by running experiments that will tell you whether your decisions are correct without resorting to catastrophic failure. Like an insurance policy, you will spend a small amount to protect yourself, but you will prevent a much greater loss.

Next, selling stakeholders on architectural experimentation is a challenge.

As we mentioned in an earlier article, getting stakeholder buy-in for architectural decisions is crucial - they control the money, and if they think you’re not spending it wisely they’ll cut you off. Stakeholders are, typically, averse to having you do work they don’t think has value, so you have to sell them on why you are spending time running architectural experiments.

Architectural experimentation is key for two reasons: For functional requirements, MVPs are essential to confirm that you understand what consumers really need. Architectural experiments do the same for technical decisions that support the MVP; they confirm that you understand how to satisfy the quality attribute requirements for the MVP.

Architectural experiments are also key because they help to reduce the cost of the system over time. This has two parts: you will reduce the cost of developing the system by finding improved solutions, earlier, and by not going down technology paths that won’t yield the results you want. Experimentation also pays for itself by reducing the cost of maintaining the system over time by finding more robust solutions.

Ultimately running experiments is about saving money - reducing the cost of development by spending less on developing solutions that won’t work or that will cost too much to support. You can’t run experiments on every architectural decision and eliminate the cost of all unexpected changes, but you can run experiments to reduce the risk of being wrong about the most critical decisions. While stakeholders may not understand the technical aspects of your experiments, they can understand the monetary value.

Of course running experiments is not free - they take time and money away from developing things that stakeholders want. But, like an insurance policy that costs the amount of premiums but protects you from much greater losses, experiments protect you from the effects of costly mistakes.

Selling them on the need to do experiments can be especially challenging because it raises questions, in their minds anyway, about whether you know what you are doing. Aren’t you supposed to have all the answers already?

The reality is that you don’t know everything you would like to know; developing software is a field that requires lifelong learning: technology is always changing, creating new opportunities and new trade-offs in solutions. Even when technology is relatively static, the problems you are trying to solve, and therefore their solutions, are always changing as well. No one can know everything and so experimentation is essential. As a result, the value of knowledge and experience is not in knowing everything up-front but in being able to ask the right questions.

You also never have enough time or money to run architectural experiments.

Every software development effort we have ever been involved in has struggled to find the time and money to deliver the full scope of the initiative, as envisioned by stakeholders. Assuming this is true for you and your teams, how can you possibly add experimentation to the mix?

The short answer is that not everything the stakeholders "want" is useful or necessary. The challenge is to find out what is useful and necessary before you spend time developing it. Investing in requirements reviews turns out not to be very useful; in many cases, the requirement sounds like a good idea until the stakeholders or end-customers actually see it.

This is where MVPs can help improve architectural decisions by identifying functionality that doesn’t need to be supported by the architecture, which doubly reduces work. Using MVPs to figure out work that doesn’t need to be done makes room to run experiments about both value and architecture. Identifying scope and architectural work that isn’t necessary "pays" for the experiments that help to identify the work that isn’t needed.

For example, some MVP experiments will reveal that a "must do" requirement isn’t really needed, and some architectural experiments will reveal that a complex and costly solution can be replaced with something much simpler to develop and support. Architectural decisions related to that work are also eliminated.

The same is true for architectural experiments: they may reveal that a complex solution isn’t needed because a simpler one exists, or perhaps that an anticipated problem will never occur. Those experiments reduce the work needed to deliver the solution.

Experiments sometimes reveal unanticipated scope when they uncover a new customer need, or that an anticipated architectural solution needs more work. On the whole, however, we have found that reductions in scope identified by experiments outweigh the time and money increases.

At the start of the development work, of course, you won’t have any experiments to inform your decisions. You’re going to have to take it on faith that experimentation will identify extra work to pay for those first experiments; after that, the supporting evidence will be clear.

Then you think you’re already running architectural experiments, but you’re not.

You may be running POCs and believe that you are running architectural experiments. POCs can be useful but they are not the same as architectural experiments or even MVPs. In our experience, POCs are hopefully interesting demonstrations of an idea but they lack the rigor needed to test a hypothesis. MVPs and architectural experiments are intensely focused on what they are testing and how.

Some people may feel that because they run integration, system, regression, or load tests, they are running architectural experiments. Testing is essential, but it comes too late to avoid over-investing based on potentially incorrect decisions. Testing usually only occurs once the solution is built, whereas experimentation occurs early to inform decisions whether the team should continue down a particular path. In addition, testing verifies the characteristics of a system but it is not designed to explicitly test hypotheses, which is a fundamental aspect of experimentation.

Finally, you can’t get the feedback you need without exposing clients to the experiments.

Some conditions under which you need to evaluate your decisions can’t be simulated; only real-world conditions will expose potentially flawed assumptions. In these cases, you will need to run experiments directly with people.

This sounds scary, and it can be, but your alternative is to make a decision and hope for the best. In this case, you are still exposing the customer to a potentially severe risk, but without the careful controls of an experiment. In some sense, people do this all the time without knowing it, when they assume that our decisions are correct without testing them, but the consequences can be catastrophic.

Experimentation allows us to be explicit about what hypothesis we are evaluating with our experiment and limits the impact of the experiment by focusing on specific evaluation criteria. Explicit experimentation helps us to devise ways to quickly abort the experiment if it starts to fail. For this, we may use techniques that support reliable, fast releases, with the ability to roll back, or techniques like A/B testing.

As an example, consider the case where you want to evaluate whether a LLM-based chatbot can reduce the cost of staffing a call center. As an experiment, you could deploy the chatbot to a subset of your consumers to see if it can correctly answer their questions. If it does, call center volume should go down, but you should also evaluate customer satisfaction to make sure that they are not simply giving up in frustration and going to another competitor with more effective support. If the chatbot is not effective, it can be easily turned off while you evaluate your next decision.

In a perfect world, we wouldn’t need to experiment; we would have perfect information and all of our decisions would be correct. Unfortunately, that isn’t reality.

Experiments are paid for by reducing the cost, in money and time, of undoing bad decisions. They are an insurance policy that costs a little up-front but reduces the cost of the unforeseeable. In software architecture, the unforeseeable is usually related to unexpected behavior in a system, either because of unexpected customer behavior, including loads or volumes of transactions, but also because of interactions between different parts of the system.

Using architectural experimentation isn’t easy despite some very significant benefits. You need to sell yourself first on the idea, then sell it to your stakeholders, and neither of these is an easy sell. Running architectural experiments requires time and probably money, and both of these are usually in short supply when attempting to deliver an MVP. But in the end, experimentation leads to superior outcomes overall: lower-cost systems that are more resilient and sustainable.

This is my second article in a series of introductions to Spring AI. You may find the first one, where I explained how to generate imag......

Once, the rallying cry of the mobile revolution was, ‘There’s an app for that.’ Today, the new reality is that AI-powered agents are substantially cha......

I love working in small, autonomous, and focused teams to build high-quality software using the best tools available....

How To Instrument a React Native App To Send OTel Signals

In this post, we’re going to walk through how to instrument a React Native application to send data to any OpenTelemetry (OTel) backend over OTLP-HTTP. In a previous tutorial for CNCF, we showed how to do this using the OTel JavaScript (JS) packages. However, in this walkthrough, we will use the open source Embrace React Native SDK for a few key reasons:

The official OTel packages require some tiptoeing when integrating them because React Native is not directly supported as a platform by the OpenTelemetry JS packages. The Embrace software development kit (SDK) was purpose-built to support React Native, which allows us to integrate the SDK without workarounds.

The Embrace React Native SDK is built on top of Embrace’s native mobile SDKs for Android and iOS. This allows it to emit telemetry around crashes, memory issues, etc., that occur in the native code running in a mobile app. In other words, you get superior visibility into mobile app issues by accessing context from both native and JS layers.

Like the OTel SDK, the Embrace React Native SDK allows exporting data to any OTLP-HTTP endpoint. However, by also sending that data to Embrace, you can leverage the power of Embrace’s dashboard to gain further insights, which we’ll dig into at the end of this walkthrough.

For simplicity, we’ll focus on iOS in this walkthrough. This same flow will work for Android with some minor differences to the setup. (See Adding the React Native Embrace SDK and Getting Started with the Embrace Dashboard.

This tutorial will leverage @react-native-community/cli , which is a set of command line tools that help you build React Native apps. In particular, we’ll use its init command to quickly get a blank app up and running:

At this point you should have the community’s Hello World example app running on iOS. Next, add the core Embrace SDK package as well as the @embrace-io/react-native-otlp package to allow export to an OTLP-HTTP endpoint:

To initialize the SDK and configure it so that it points to your backend of choice (in this case, the Grafana Cloud OTLP endpoint), open [website] and add the following to the App functional component:

There are a few things happening in the above snippet, so let’s take a look at them one at a time:

Initializing the Embrace SDK in JavaScript: We are using the useEmbrace hook to start and configure the Embrace SDK. This is the simplest way to get the Embrace SDK started from the React Native layer. Note that, because we’re dealing with a mobile app, there may be interesting telemetry to capture before starting the JS layer that we would miss out on with this approach. The Embrace SDK can also be started in native code to account for this scenario, but we won’t get into that level of detail in this tutorial. More information can be found in the documentation if you are interested.

Configuring log and trace exporters: Logs and traces are two of the fundamental OTel signals. Here, we are setting both to be exported to the same backend. Note that the two exporters are configured independently of one another. If you wish, you could choose to set up just one, or you could send telemetry to different observability backend locations. Any backend that supports receiving data as OTLP-HTTP would work. In this example, we are choosing to use Grafana. If you don’t already have an appropriate backend setup, you can quickly get started with Grafana by registering to Grafana Cloud and creating an account. You may want to configure data insights like Tempo for traces or Loki for logs. We are also setting disabledUrlPatterns in the iOS configuration to exclude any capture of URLs with the pattern ["[website]"] . Embrace’s instrumentation automatically creates spans for any network requests. However, because the OTLP exporter makes a network request to send traces, this would produce a cycle where the export’s network request creates a span, which is exported and creates another span, and so on. Ignoring “[website]” allows us to export to it without creating additional telemetry.

Grabbing isPending and isStarted from the result of using the hook: We’ll use these values later on in the tutorial. They allow us to know when the Embrace SDK has successfully started so that we can build further instrumentation on top of it.

You haven’t yet added any instrumentation. However, you should still be able to see some useful telemetry in your observability system from the instrumentation that the Embrace SDK sets up automatically, such as capturing spans for network requests and logs for unhandled exceptions. To see these, relaunch the app and search in your observability tool for the new spans.

If you are using Grafana, you can log in to your Organization, select your Grafana Cloud stack and see some telemetry in the Explore section. Let’s dig into what you’ll see at this point:

The screenshot above displays the emb-session trace, which contains a lot of interesting information about what we call a “session.” In the OTel Semantic Conventions, sessions are defined as “the period of time encompassing all activities performed by the application and the actions executed by the end user.”.

By scrolling down in the side panel on the right, you can see even more information that is collected by default for every app session.

You can add your own custom tracing as well. In OpenTelemetry, this is done through a Tracer Provider, so start by adding Embrace’s tracer provider package, which implements this interface. Setting this up could look like:

In this snippet, the Embrace tracer provider is initialized and used to create a new custom span with the createSpan call. The tracer is used to start the span manually, and then at a certain point in the business logic, the span should be ended.

For testing purposes, we are using a timeout to end the span here, but a more interesting case would be to wrap some extended operation and end the span whenever the action it measures is complete. Notice that we are also setting a custom attribute and event to this instance in order to attach further context to the span.

You are now ready to assign that callback to a button and test it, which can be rendered simply as:

Once you trigger this action, you can take a look back at the Grafana dashboard. You should see something like the following:

The span named Span created manually reveals up in the list.

If you dig into this trace, you will see the custom attribute and event attached to it:

A more realistic app will support navigating between screens, which is likely something you will also want to record telemetry for. Embrace has a package that provides the instrumentation for this common use case. This package takes in the same tracer provider that you set up in the previous steps and wraps your components in order to create telemetry whenever the user navigates to a new screen:

Your app should now launch with a tab bar that has two items, with screens that look like this:

This example reveals a very simple navigation flow using the @react-navigation/native package between a home page and a details screen, but it also supports the packages expo-router and react-native-navigation .

Now that this is all configured, you can build the application again and navigate between views. Every time a view reveals up and then disappears (because another one is present), it will create a span that represents the period that the first view was displayed to the user.

There are now two new names in this list — home and details . These two spans were created by the Embrace package, which captures every navigation action in the application once the package has been configured.

Looking closely at one of these new spans, you can see that the package not only adds a few default attributes such as [website] or [website] , but also includes the attributes you configured earlier through the screenAttributes property of the EmbraceNavigationTracker component:

The NavigationContainer component consumed from @embrace-io/react-native-navigation is what we call an “instrumentation library.” It is a stand-alone package that produces telemetry data referring to the navigation flow, and it automatically starts and ends spans at the right time with the appropriate context. You can read in depth about how we approached building it.

This instrumentation library is exposed by Embrace, but it’s not locked to our product. The same component could be used to track telemetry data using any tracer provider.

Likewise, any instrumentation library that works with a tracer provider and produces valid signals can be hooked up to Embrace to start capturing additional telemetry.

Gaining Valuable Insights With the Embrace Dashboard.

The Embrace React Native SDK is a great option for quickly collecting valuable data to analyze user journeys and monitor the health of your applications across different devices. Embrace not only gathers this data for you but also provides a comprehensive set of tools to help you derive meaningful insights by processing all the signals collected by the SDK.

These include a powerful User Timeline showing exact sequences of events that led to an issue or poor customer experience:

The User Timeline allows developers to see what occurred in code from the user perspective ([website], taps and navigation), from the business logic ([website], networking and instrumented spans), and from the app and device layer ([website], memory warnings and crashes). Putting this information all in sequence allows developers to dig into the technical details affecting performance and correlate issues across the app’s stack.

In addition, you can easily integrate Embrace with your existing observability solution to power mobile SLOs (service level objectives) and create more cohesive workflows between DevOps/site reliability engineers (SREs) and mobile teams. One such example is network span forwarding, which makes it possible to trace the same request in the User Timeline and your backend monitoring service.

In this walkthrough, we covered how to instrument a React Native application to send data to any OTel backend over OTLP-HTTP. We used the Embrace React Native SDK because it is purpose-built for React Native and greatly simplifies the integration process over the OpenTelemetry JS packages. We also touched briefly on a few benefits in sending your OpenTelemetry signals to the Embrace dashboard.

Embrace is helping make OpenTelemetry work for mobile developers. We’ve built our iOS, Android and React Native SDKs on OTel while working with the community to improve the specification. If you want to learn more about how to leverage mobile observability built on OpenTelemetry, check out our open source repos or join our Slack community.

Lets say we have an algorithm which performs a check if a string is a palindrome.

bool isPalindrome(string s) { for(int i = 0; i < [website]; i+......

Editor's Note: The following is an infographic written for and 's 2025 Trend research, Developer Experience: The Coalescence of Develo......

Bhat: What we're going to talk about is agentic AI. I have a lot of detail to talk about, but first I want to tell you the backstory. I pe......

How to build a secure project management platform with Next.js, Clerk, and Neon

Around 30,000 websites and applications are hacked every day*, and the developer is often to blame.

The vast majority of breaches occur due to misconfiguration rather than an actual vulnerability. This could be due to exposed database credentials, unprotected API routes, or data operations without the proper authorization checks just to name a few. It’s significant to ensure that your application is configured in a way that prevents attackers from gaining unauthorized access to user data.

In this article, you’ll learn how to build a project management web application while considering security best practices throughout.

Although this article can be followed by itself, it is the second in a series covering the process of building Kozi - a collaborative project and knowledge management tool. Throughout the series, the following elements will be implemented:

Create organizations to invite others to manage projects as a team.

A rich, collaborative text editor for project and task notes.

A system to comment on projects, tasks, and notes.

Automatic RAG functionality for all notes and uploaded files.

Invite people from outside your organization to collaborate on individual tasks.

What makes this a “secure” project management system?

Data security is considered throughout this guide by using the following techniques:

Clerk is a user management platform designed to get authentication into your application as quick as possible by providing a complete suite of user management tools as well as drop-in UI components. Behind the scenes, Clerk creates fast expiring tokens upon user sign-in that are sent to your server with each request, where Clerk also verifies the identify of the user.

Clerk integrates with [website] middleware to ensure every request to the application is evaluated before it reaches its destination. In the section where the middleware is configured, we instruct the middleware to protect any route starting with /app so that only authenticated consumers may access them. This means that before any functions are executed (on the client or server), the user will need to be authenticated.

In this project, server actions are the primary method of interacting with the data in the database. Direct access to the database should always happen on the server and NEVER on the client where tech-savvy consumers can gain access to the database credentials. Since all functions that access the database are built with server actions, they do not execute client-side.

It's critical to note that calling these server actions should only ever be performed from protected routes. When a [website] client component executes a server action, an HTTP POST request of form data is submitted to the current path with a unique identifier of the action for [website] to route the data internally.

This means that calling a server function from an anonymous route might result in anonymous customers getting access to the data. This potential vulnerability is addressed in the next section.

Protecting access to the functions is only one consideration. Each request will have an accompanying user identifier which can be used to determine the user making that request. This identifier is stored alongside the records the user creates, allowing each request for data to ONLY return the data associated with that user.

When making data modifications, the requesting user ID is cross-referenced with the records being modified or deleted so that one user cannot affect another user’s data.

The combination of protecting access to the routes, being mindful of calling server actions, and cross-referencing database queries with the user making the request ensures that the data within the application is secure and only accessible to those who have access to it.

Kozi is an open-source project, with each article in the series having corresponding start and end branches. This makes it easy to jump in at any point to get hands-on experience with the concepts outlined in each piece, as well as a point of reference if you simply want to see the completed code. Here are links to the specific branches:

You should have a basic understanding of [website] and React as well.

Once the branch above is cloned, open the project in your editor or terminal and run the following command to start up the application:

npm install npm run dev Enter fullscreen mode Exit fullscreen mode.

Open your browser and navigate to the URL displayed in the terminal to access Kozi. At the bottom right of the screen, you should see Clerk is running in keyless mode.

You are now ready to start building out the core functionality of Kozi!

To store structured data, you’ll be using a serverless instance of Postgress provided by Neon. Start by heading to [website] and creating an account if you don’t have one. Create a new database and copy the connection string as shown below.

Create a new file in your local project named [website] and paste the following snippet, replacing the placeholder for your specific Neon database connection string.

DATABASE_URL= Enter fullscreen mode Exit fullscreen mode.

Prisma is used as the ORM to access and manipulate data in the database, as well as apply schema changes to the database as the data needs are updated. Open the project in your IDE and start by creating the schema file at prisma/[website] . Paste in the following code:

generator client { provider = "prisma-client-js" } datasource db { provider = "postgresql" url = env("DATABASE_URL") } model Project { id String @id @default(cuid()) name String description String? owner_id String created_at DateTime @default(now()) updated_at DateTime @updatedAt is_archived Boolean @default(false) } model Task { id String @id @default(cuid()) title String description String? owner_id String is_completed Boolean @default(false) created_at DateTime @default(now()) updated_at DateTime @updatedAt project_id String? } Enter fullscreen mode Exit fullscreen mode.

We’re using the owner_id column instead of user_id since this application will be updated to support teams and organizations in a future entry.

Next, create the src/lib/[website] file and paste in the following code which will be used throughout the application to create a connection to the database:

import { PrismaClient } from ' @prisma/client ' const globalForPrisma = globalThis as unknown as { prisma : PrismaClient | undefined } export const prisma = globalForPrisma . prisma ?? new PrismaClient () if ( process . env . NODE_ENV !== ' production ' ) globalForPrisma . prisma = prisma Enter fullscreen mode Exit fullscreen mode.

To sync the schema changes to Neon, run the following command in the terminal:

npx prisma db push Enter fullscreen mode Exit fullscreen mode.

If you open the database in the Neon console and navigate to the Tables menu item, you should see the projects and tasks tables shown.

Finally, since it is not best practice to use the Prisma client in any client-side components, you’ll want a file to store interfaces so that TypeScript can recognize the structure of your objects when passing them between components.

Create the src/app/app/[website] file and paste in the following:

export interface Task { id : string title : string description ?: string | null is_completed : boolean created_at : Date updated_at : Date project_id ?: string | null owner_id : string } export interface Project { name : string id : string description : string | null owner_id : string created_at : Date updated_at : Date is_archived : boolean } Enter fullscreen mode Exit fullscreen mode.

Configure /app as a protected route with Clerk.

Clerk’s middleware uses a helper function called createRouteMatcher that lets you define a list of routes to protect. This includes any pages, server actions, or API handlers stored in the matching folders of the project.

All of the core functionality of the application will be stored in the /app route, so upgrade src/[website] to use the createRouteMatcher to protect everything in that folder:

import { clerkMiddleware , createRouteMatcher } from ' @clerk/nextjs/server ' const isProtectedRoute = createRouteMatcher ([ ' /app(.*) ' ]) export default clerkMiddleware ( async ( auth , req ) => { if ( isProtectedRoute ( req )) await auth . protect () }) export const config = { matcher : [ // Skip [website] internals and all static files, unless found in search params ' /((?!_next|[^?]* \ .(?:html?|css|js(?!on)|jpe?g|webp|png|gif|svg|ttf|woff2?|ico|csv|docx?|xlsx?|zip|webmanifest)).*) ' , // Always run for API routes ' /(api|trpc)(.*) ' , ], } Enter fullscreen mode Exit fullscreen mode.

The /app route will use a different layout from the landing page, which will contain a collapsible sidebar that contains the (a Clerk UI component that lets clients manage their profile and sign out), an inbox for tasks, and a list of projects that tasks can be created in.

Start by creating the src/app/app/components/[website] file to render the elements of the sidebar:

' use client ' import { cn } from ' @/lib/utils ' import { ChevronRightIcon , ChevronLeftIcon , InboxIcon } from ' lucide-react ' import React from ' react ' import Link from ' next/link ' import { UserButton } from ' @clerk/nextjs ' function Sidebar () { const [ isCollapsed , setIsCollapsed ] = React . useState ( false ) return ( < div className = { cn ( ' h-screen border-r border-gray-200 bg-gradient-to-b from-blue-50 via-purple-50/80 to-blue-50 p-4 dark:border-gray-800 dark:from-blue-950/20 dark:via-purple-950/20 dark:to-blue-950/20 ' , ' transition-all duration-300 ease-in-out ' , isCollapsed ? ' w-16 ' : ' w-64 ' , ) } > < nav className = "space-y-2" > < div className = "flex items-center justify-between gap-2" > < div className = { cn ( ' transition-all duration-300 ' , isCollapsed ? ' w-0 overflow-hidden ' : ' w-auto ' , ) } > < UserButton showName />.