If you've been working with Next.js lately, you've probably seen the use client directive pop up in components. It's just one line at the top of a file, but it raises an important question: does it affect SEO? Short answer: No. Client components don't hurt SEO. Let me explain why. What use client actually does In Next.js 13 and above, components are server components by default. When you add use client to a component, you're telling Next.js this component needs client-side features like: State (useState, useEffect) Event handlers Browser-only APIs (like window or localStorage) Animations or heavy interactivity Here's the key thing: Client components are still pre-rendered on the server and included in the initial HTML. Search engines see them immediately, exactly the same as server components. The difference is that client components are also bundled and sent to the browser for hydration—making them interactive. Why people think use client hurts SEO (and why they're wrong) There's a common misconception that client components aren't server-rendered. This isn't true. Both server components and client components appear in the initial HTML that gets sent to the browser. From a crawler's perspective, there's no difference. Google sees the content immediately either way. So putting an <h1>, product description, or blog content in a client component is totally fine for SEO. The content is there in the HTML from the start. What actually matters for SEO While use client itself doesn't hurt SEO, there are two things that DO matter: 1. Don't hide content behind interactivity This is the real SEO risk. If content only appears after a user clicks a button, opens a tab, or submits a form, crawlers won't see it. Crawlers load the page and run JavaScript, but they don't interact with it. They don't click buttons or switch tabs. Bad for SEO: Product details hidden behind a "Read More" button Pricing shown only after selecting a tab Content that requires form submission to view Fine for SEO: Interactive components that render content immediately Client components with state that shows content on load Animations that don't hide initial content 2. Be mindful of performance Client components increase your JavaScript bundle size. If you're overusing use client across your entire app, you can end up with a bloated bundle that slows down your site. Performance affects SEO indirectly through Core Web Vitals and page speed rankings. But this is a holistic concern about your app's architecture, not a per-component decision. You shouldn't avoid putting an <h1> in a client component just because it's an <h1>. If that component needs interactivity, use use client. The performance cost comes from the component being in the bundle, not from what content it contains. The actual decision tree When deciding between server and client components, ask yourself: Does this component need client-side features? State management? Event handlers? Browser APIs? Interactivity after page load? Yes? → Use use client No? → Keep it as a server component That's it. It's about functionality, not SEO. How to use use client correctly DO use use client for: Forms with validation Interactive widgets Modals and dialogs Tabs (as long as content is visible on initial render) Animations Any component that needs state or browser APIs DON'T worry about: Whether the component contains an <h1> or important text Search engine indexing—crawlers see client components just fine Per-component performance decisions based on content type DO worry about: Hiding content behind clicks, tabs, or interactions Overall bundle size if you're using use client everywhere Whether you actually need client features or just defaulted to use client out of habit The bottom line use client doesn't hurt SEO. Both client and server components appear in the initial HTML that crawlers see. The choice between them should be based on whether you need client-side features, not whether the content is important for SEO. The real SEO concerns are: Hiding content behind interactivity that requires user action Overall app performance from excessive JavaScript bundles Get those right, and you can use client components wherever you need them without worrying about SEO.

Let’s get straight to the point: if you’re still using Redux to handle API requests and responses, stop. Right now. I know, I know—Redux has been the industry darling for years, the default state management solution for React apps. But here’s the hard truth: Redux was never meant to manage server state. Yet, so many developers are out here struggling, writing mountains of boilerplate, manually handling caching, and fighting race conditions—all because someone once told them Redux is the “best practice.” It’s not. If you’ve ever felt like managing API calls in Redux is a battle you have to fight every day, guess what? You’re not crazy. It actually is that hard. And the worst part? It doesn’t have to be. There’s a better way, and it’s called React Query. Redux Is the Wrong Tool for the Job Using Redux for request-response management is like using a screwdriver to hammer in a nail. It technically works, but it’s painfully inefficient, and you’ll probably hurt yourself in the process. Here’s why Redux struggles with server state: 1. Too Much Boilerplate – And You Know It Let’s be honest. If you’re managing API requests in Redux, you’re doing way too much work: You create action types for every request state: FETCH_USERS_REQUEST, FETCH_USERS_SUCCESS, FETCH_USERS_FAILURE—and that’s just for one API call! You write action creators to dispatch those types. You set up reducers to handle the new state. You use middleware like redux-thunk or redux-saga to handle async logic. You manually handle loading, caching, and error states in your UI. All of this just to make an API call and store the response. Why? Seriously, why? This isn’t just “doing things the hard way.” It’s self-sabotage. 2. Redux Is Bad at Synchronizing Server State Server state isn’t like client state. It’s dynamic, ever-changing, and needs to be kept fresh. Redux doesn’t know when data is stale. It doesn’t fetch new data unless you tell it to. This means you end up writing even more code to: ✅ Manually refresh stale data. ✅ Handle pagination and infinite scrolling. ✅ Refetch when a user revisits a page. ✅ Prevent unnecessary API calls. And if you forget to handle one of these? Boom—stale or duplicate data in your app. 3. Not Everything Needs to Be in Global State One of the biggest mistakes developers make is treating API responses as global state. Think about it: does a list of users fetched from an API really need to be globally accessible at all times? Probably not. Yet Redux forces you to treat it that way, adding complexity and unnecessary state management overhead. By shoving API data into Redux, you end up: ❌ Making debugging harder. ❌ Cluttering your Redux store with temporary data. ❌ Increasing the risk of out-of-sync state. Not everything belongs in Redux. And API data? That’s at the top of the list. React Query: The Tool You Should Be Using Instead Now, let’s talk about the solution: React Query. Unlike Redux, React Query was built specifically for managing server state. That means it does all the hard work for you. 1. Zero Boilerplate, Maximum Power Let’s rewrite that Redux API call, but this time with React Query: No actions. No reducers. No middleware. Just a single hook. Why write 100 lines of Redux code when you can do it in 10? 2. Built-in Caching and Background Fetching React Query automatically caches API responses and refetches when: ✅ The user revisits the page. ✅ The browser regains focus. ✅ Data becomes stale. No manual refreshing. No unnecessary API calls. Just fresh data, always. 3. Automatic Server State Synchronization With React Query, your data stays in sync with the server without you lifting a finger. Need to refetch when a mutation happens? It’s automatic. Need pagination or infinite scrolling? It’s built-in. Need to handle errors and retries? Already done. Everything Redux struggles with? React Query does effortlessly. 4. Optimistic Updates and Mutations Without the Hassle Ever tried handling optimistic updates in Redux? It’s a nightmare. With React Query, it’s just this: That’s it. No need to manually update state or write reducers. It just works. So, Should You Ever Use Redux? I’m not saying Redux is useless. It’s still great for client state—things like: ✅ UI state (modals, dropdowns, themes). ✅ Authentication state. ✅ Complex global app state. But for request-response management? Absolutely not. There is no logical reason—none—to still be using Redux for API calls when React Query exists. It’s Time to Move On If you take one thing from this article, let it be this: Redux is not for server state. Stop using it for API requests. Switch to React Query. Today. React Query: ✅ Less code ✅ Better performance ✅ Automatic caching and synchronization ✅ Smarter updates Redux for server state? Outdated, inefficient, and unnecessary. If you’re still using Redux for API requests, ask yourself: why? Then do yourself a favor—rip out the boilerplate and embrace React Query. Your future self will thank you.

Introduction Imagine this: you’re building a dynamic Next.js app where data must refresh every two minutes. Easy, right? Just use setInterval in useEffect and call it a day! Well, that’s what I thought until I ran into an unexpected challenge. As I opened multiple browser tabs, I noticed each tab was fetching data independently, at different intervals. They weren’t in sync, and that wasn’t ideal for user experience. This blog post is about the solution I arrived at: a frontend “cron job” approach to synchronize data-fetching intervals across multiple tabs. I’ll walk you through my process, the issues I faced, and the satisfying solution I found. Starting Out: The Initial Timer-Based Fetch At first, I set up my Next.js component to fetch data at a fixed interval. Here’s what it looked like initially: The Problem: Out-of-Sync Tabs Everything seemed great, until I opened a second tab. With each tab running its own instance of setInterval, data fetching became unsynchronized. Tabs would refresh at different times, creating a disjointed user experience. To illustrate, here’s how things looked: Opened the first tab at 12:01, so it fetches every odd minute (12:03, 12:05, etc.). Opened the second tab at 12:02, which then fetches every even minute (12:04, 12:06, etc.). The issue became clear: I needed every tab to fetch at the same time, preferably at exact two-minute marks (like 12:00, 12:02, 12:04), regardless of when a user opened the tab. Solution: Syncing Fetches at Even-Minute Marks To achieve sync across multiple tabs, I decided to align all data fetches with even two-minute intervals (e.g., 12:00, 12:02, 12:04). This approach ensures all tabs are fetching data at the same time. Here’s how I tackled it: Calculate Time to the Next Even Minute: First, determine how long it is until the next two-minute mark. This will be the initial delay. Set a Timeout for the First Fetch: Once we know the time until the next even minute, use setTimeout to start the first fetch exactly at that point. Set a Consistent 2-Minute Interval Thereafter: After the initial fetch, set up a regular setInterval to continue fetching every two minutes. This is how the final code turned out: Breaking Down the Code Calculate Initial Delay: By checking the current time in minutes and seconds, I computed the milliseconds remaining until the next two-minute interval. Start Fetching with a Timeout: The setTimeout uses the calculated delay to ensure that the first data fetch happens exactly at the next even minute. Set Interval After the First Fetch: Once the initial timeout triggers, setInterval starts the two-minute cycle, aligning all data fetches to happen in sync, every even minute across every open tab. Result: Perfectly Synchronized Fetching With this approach, I achieved a unified experience across all tabs. Now, no matter when a user opens the page, the data refreshes in sync at every two-minute mark. Here’s how it behaves now: Open a tab at 12:01:29, it waits until 12:02:00, then fetches every two minutes thereafter. Open another tab at 12:01:58, it waits only two seconds, then fetches at 12:02:00, staying in sync with other tabs. Final Thoughts This solution might feel like a small change, but it significantly improved the consistency of data display across tabs and browsers. This approach, aligning fetches to specific intervals, is sometimes called a “frontend cron job” because it emulates the regular scheduling of a backend cron job right in the browser. When to Use This Approach This sync method is useful when: You’re working with time-sensitive data that should be consistent across tabs. A traditional setInterval wouldn’t align with other instances in different tabs.

Introduction Building a data-driven application in Next.js is generally smooth, but things got tricky when I faced an SSL certificate error. The journey turned into a deep dive into client-server interactions, SSL certificates, and a workaround involving custom API routes. If you’re working with data fetching in Next.js and need to dodge SSL verification errors, this post is for you. Starting Out: A Simple Server Component The project began with a server component meant to fetch data directly from an external API and display it on the page. The logic was simple: call the API and render the data immediately on the server side. Here’s the initial setup: It seemed straightforward, but as soon as I deployed the component and ran it in production, I hit a wall. I was greeted by a net::ERR_CERT_AUTHORITY_INVALID error, indicating that the SSL certificate wasn’t fully trusted. This halted the entire process and left the page unable to fetch or display any data. SSL Errors Explained: Why This Happens SSL errors like ERR_CERT_AUTHORITY_INVALID usually mean that the server’s SSL certificate can’t be verified as trustworthy. In my case, the API’s SSL certificate didn’t meet the standard trusted certificate authorities in the browser. This is a common issue when working with certain staging APIs or self-signed certificates. The Workaround: Creating an API Route in Next.js To avoid this SSL error, I decided to set up an API route in Next.js. This approach allowed me to make the initial API call from the Next.js server, bypassing the SSL error by ignoring the certificate verification only server-side. Here’s how I set it up: 1. Create a new API route: This API route serves as a proxy between my Next.js app and the external API, handling the data fetching server-side. In this setup: The httpsAgent instance is configured with rejectUnauthorized: false, which skips SSL verification, avoiding the error. The Next.js API route /api/fetchGlobalData acts as a go-between, making the request to the external API and returning the data to my frontend. 2. Fetch Data in the Client Component: With the API route ready, I updated my client component to fetch data from this new endpoint. The Benefits of This Approach SSL Error Bypassed: By fetching data on the server side, the browser is shielded from any SSL certificate issues. Secure Data Handling: Sensitive data remains secure, as it’s handled entirely on the server. Consistent Refetching: With setInterval, I could refetch every 2 minutes, ensuring the data stays up-to-date without worrying about SSL issues impacting the client. Wrapping Up Converting my server component to an API route was a game-changer for this project. By letting the server handle SSL verification, I kept the client-side data flow smooth and reliable. The final implementation of this clever workaround allowed me to bypass SSL errors entirely while providing an effective and synchronized data-fetching setup. So, if you’re working in Next.js and encounter SSL issues, consider this approach, it’s a straightforward solution to a frustrating problem.

As a Frontend Software Engineer, I’ve had the opportunity to work on various challenging and rewarding projects. One of the key aspects I’ve focused on is optimizing frontend performance. Why is this so important? Because a fast, responsive web application can significantly enhance user experience and retention. Step 1: don’t ignore performance issues YES! don't be a lazy programmer. Perform an honest analysis on your application as you build. In our fast-paced digital world, speed and responsiveness are crucial. Yet, it's all too easy to brush off performance issues like slow load times and laggy interfaces. Let’s face it—no one likes waiting for a page to load. As developers, it’s our responsibility to ensure a smooth and efficient user experience. Ignoring these issues isn’t just lazy programming; it can also drive users away and hurt your product’s reputation. Why performance matters User experience: A fast website makes for happy users. Slow pages lead to frustration and higher bounce rates. SEO benefits: Search engines love speed. Optimizing your frontend can boost your site’s ranking. Conversion rates: Better performance can directly impact your business metrics. Users are more likely to stay and convert if your site is quick and responsive. Here are a few strategies I’ve found incredibly effective: Refactoring: By refactoring and optimizing code, I’ve improved readability and performance. This not only speeds up load times but also makes the codebase more maintainable. Responsive design: Ensuring that web applications look and function beautifully on all devices is crucial. I’ve utilized frameworks like React and Next.js to create seamless, responsive designs that engage users across desktops, tablets, and smartphones. Advanced analytics: Implementing comprehensive analytics has allowed me to track user interactions and identify areas for improvement. This data-driven approach ensures that we’re always enhancing the user experience based on real feedback. Security measures: Integrating secure APIs and implementing robust authentication mechanisms is vital. It’s not just about speed but also about creating a safe and reliable environment for users. A call to action Let’s not be lazy programmers. Let’s take pride in our craft and prioritize performance from the get-go. By doing so, we can create digital experiences that are not only beautiful but also fast and reliable. Join the conversation What are your go-to strategies for frontend performance optimization? Have you faced any challenges in this area? Let’s share our experiences and learn from each other. Feel free to reach out if you’re interested in discussing frontend development, have questions, or want to collaborate on exciting projects. Let’s keep pushing the boundaries of what’s possible on the web! Stay curious and keep coding! 💻✨

Imagine you're building a website. You head to the tool shed (or in this case, the web development toolbox) and see two fantastic tools: React and Next.js. Both are powerful, but they each have their specialties. Let's unpack them and see which one would be the perfect fit for your project! React: The Brick-by-Brick Builder Think of React as a toolbox filled with Lego bricks. These aren't ordinary Legos though – they're super-powered and designed specifically for building user interfaces (UI) for websites and apps. React lets you create reusable components, like mini Legos with specific functions. You can then snap these components together to build more complex interfaces. This is particularly useful for building single-page applications (SPAs), those fancy websites that feel like regular apps you download. Here's the beauty of React: it's incredibly flexible. You have tons of control over how you put everything together, kind of like building a Lego masterpiece according to your own blueprint. There's also a massive library of extra Lego sets (third-party libraries) you can integrate to add even more functionality. The downside? There's a bit more setup involved since you have more control over all the moving parts. But if you're up for the challenge, React offers a ton of creative freedom. Next.js: The All-in-One Toolkit Next.js is like React's super-charged sibling. It has all the component-building goodness of React, but it also throws in a bunch of pre-built tools to make your development life easier and faster. Imagine your Lego set now comes with pre-built modules for common features like routing (switching between pages on your website), data fetching (grabbing information from servers to display on your site), and even SEO (search engine optimization) tools to get your website ranking high in search results. Pretty cool, right? Let's settle the score: React vs Next.js When to Grab React: Complex SPAs with tons of customization: React gives you ultimate control, so you can build exactly what you envision. Love tinkering under the hood: If you enjoy getting down and dirty with the code and customizing every aspect, React is your jam. Already a React pro: If you're familiar with React and its ecosystem, diving in with React might be the most efficient route. When to Go with Next.js: SEO matters: Next.js is built with SEO in mind, so it's a great choice if you want your website to be easily found by search engines. Need for speed and a smooth user experience (UX): Next.js prioritizes performance and a frictionless user experience, keeping your website visitors happy and engaged. Want a framework that gets things done: If you don't want to spend ages building everything from scratch, Next.js has a ton of built-in features to streamline development. Overkill Alert! When is using Next.js an overkill? Well, imagine you're trying to hammer in a thumbtack—a simple task, right? Similarly, if you're building a straightforward website with just a few static pages and minimal interactivity, Next.js might feel like using a sledgehammer to crack a nut. Sure, Next.js is fantastic for dynamic web applications with server-side rendering and snazzy client-side routing, but for a project that's more like a gentle breeze than a whirlwind of activity, it might be like bringing a Ferrari to a Sunday stroll in the park—overkill, to say the least. Now, picture this: you're craving a good old-fashioned PB&J sandwich. You've got your bread, peanut butter, and jelly ready to go. But then you remember, you've got React in your toolkit. Using React for a project that's as simple as slapping together a sandwich might feel like using a high-tech sandwich-making robot just to spread the peanut butter evenly. Sure, React's component-based architecture and state management are top-notch, but for a project where you just need a couple of static pages and a sprinkle of interactivity, it's like using a bazooka to shoot down a fly—total overkill. My Final Takeaway The best tool depends on your project's needs. If you're unsure, start with React to grasp the fundamentals of building user interfaces. Then, you can transition to Next.js for future projects that require more speed, SEO, and built-in features. Remember, they're not rivals – they're powerful tools in your web development arsenal, each ready to tackle different challenges!

Conquering the SEO game with Next.js Ever feel like your website is buried under a pile of search results? If you're nodding in agreement, it might be time to SEO-ify your site. SEO, or search engine optimization, is the art and science of getting your website seen by the right people at the right time. And guess what? Next.js can be your secret weapon in this battle for search engine glory. Pre-rendering to the rescue! Unlike traditional React apps that wait for the browser to render content, Next.js can pre-render pages on the server. This means search engines see fully formed HTML, making it a breeze for them to understand your website's content. Speed is king with SEO. Next.js helps you create lightning-fast websites. Features like code-splitting and image optimization keep your pages lean and mean, which keeps visitors happy and search engines impressed. Don't forget user experience (UX)! Websites that offer smooth, interactive experiences tend to rank higher. Next.js makes it easy to build user-friendly interfaces that keep visitors engaged. After all, happy visitors are more likely to stick around and explore your content, sending positive signals to search engines. Meta magic! Next.js makes it easy to manage meta tags and descriptions, those little snippets of text that appear in search results. With clear and concise meta tags, you can give search engines (and users) a clear understanding of what each page on your website is about. The SEO benefits of Next.js go beyond these points. It offers features like automatic sitemap generation and built-in support for structured data, both of which can further improve your website's ranking potential. In conclusion, Next.js provides a comprehensive toolkit for building websites that search engines love. From pre-rendering and speed optimization to user-friendly features and meta management, Next.js has everything you need to create an SEO-friendly website that thrives in the ever-competitive world of search.

We've all been there: scrolling through social media and stopping dead in our tracks at a design that's pure eye candy. But then, on the other hand, there are those designs that just feel... off. You know what I mean? Not only do they lack that certain je ne sais quoi, but they are also very disturbing. I've always been passionate about good design. It's like magic—a well-crafted graphic or UI can grab your attention, inform you, and even spark emotions. But have you ever wondered what makes a design truly effective? The answer lies in a handful of core principles that anyone can learn! Here are 4 key principles to elevate your designs: 1. Contrast: Imagine a flat picture with no variation in colour or size. Boring, right? Contrast uses opposing elements like light and dark or big and small to create visual interest and guide the viewer's eye through your design. 2. Balance: Just like a well-built seesaw, a balanced design feels stable and pleasing to look at. This doesn't necessarily mean everything needs to be symmetrical. Balance can be achieved by strategically placing elements with varying weights to create a sense of harmony. 3. Hierarchy: Not all information is created equal. Hierarchy helps you prioritize what's most important in your design by using elements like size, colour, and placement to guide the viewer's attention. 4. Simplicity: "Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it's worth it in the end because once you get there, you can move mountains." - Steve Jobs Have you ever felt overwhelmed by a cluttered design? Simplicity is about focusing on the essential elements and removing anything that distracts from your message. A clean and clear design is easier to understand and leaves a lasting impression. By mastering these principles, you too can create graphics that captivate your audience and leave a lasting impression.