DEV Community: Pierre Mouchan

How I created a live subscribers counter in NextJS (with source code)

Pierre Mouchan — Tue, 11 Jun 2024 12:53:00 +0000

How I Created a Live Subscribers Counter in NextJS

Hey web developers,
I built an engaging feature on a newsletter subscription page to enhance the user experience and trust of my Obsibrain landing page. One intriguing way of doing this is by displaying a live subscriber counter. In this article, I will walk you through how I created such a feature using Next.js API and the Brevo API.

Introduction

In this tutorial, we will build a function that fetches the number of subscribers from Brevo and displays the total number on the front-end. Whenever there is a new subscriber, the counter will be updated in real-time.

First things first, the basic Next.js API route

This is the foundation of a Next.js API route.
The GET function is an asynchronous function that serves as the request handler for HTTP GET requests to this API endpoint.

This API route is located under:
app > api > get-subscriptions > route.ts

import type { NextRequest, NextResponse } from 'next/server'

export async function GET(req: NextRequest, res: NextResponse) {
  // More code...
}

Getting the Subscribers from Brevo

First things first, let's fetch the list of subscribers. We use the Brevo API for this purpose.
(explanation inside the code snippet)

Here's the code snippet:

import dotenv from 'dotenv'
import type { NextRequest, NextResponse } from 'next/server'

dotenv.config()

const BASE_URL = `https://api.brevo.com/v3`
const API_KEY = process.env.BREVO_API_KEY

// full url
const url = [BASE_URL, 'contacts'].join('/')

export async function GET(req: NextRequest, res: NextResponse) {
    try {
    // making the request with the required headers
      const response = await fetch(url, {
        method: 'GET',
        headers: {
          'Accept': 'application/json',
          'api-key': `${API_KEY}`,
        }
      })

      const data = await response.json()

    // checking for the response to be 'ok' and be successful
      if (!response.ok) {
        return new Response(JSON.stringify({ message: 'Error getting list of subscriptions' }), { status: 500 })
      }
    } catch (error) {
      return new Response(JSON.stringify({ message: 'Error getting list of subscriptions', error }), { status: 500 })
    }
}

Invalidating on Each New Subscriber

To keep our subscriber list fresh and updated, we use the revalidation option provided by Next.js to invalidate the cached data and fetch fresh data periodically both on backend and frontend.

export const revalidate = 300

export async function GET(req: NextRequest, res: NextResponse) {
//...
}

By setting revalidate to 300 seconds, the data will be revalidated every 5 minutes (backend) to ensure we are displaying the most current subscriber count.

const response = await fetch(url, {
        method: 'GET',
        headers: {
          'Accept': 'application/json',
          'api-key': `${API_KEY}`,
        },
        next: { tags: ['subscriptions'] }, // NextJS tags

      })

The tags property is an array of strings that can be used to uniquely identify a request. This is particularly useful when you want to invalidate the cache for a specific request in the future.

This means that whenever the cache for this specific request needs to be invalidated (for example, when a new subscriber is added), Next.js can target this request by looking for the 'subscriptions' tag (used in frontend in our case but can be invalidated on backend as well).

import { revalidateTag } from 'next/cache'

revalidateTag('subscriptions') // revalidate the cache for the get-subscriptions route

Returning the Data

Once we've fetched the subscriber data, the final step is to return this information in a structured format. The function wraps up the data in a JSON response that includes the total number of subscribers.

Here's the concluding part of the code:

return new Response(
  JSON.stringify({
    message: 'Subscriptions fetched successfully',
    data: { totalSubscriptions },
  }),
  { status: 200 },
)

This structured response allows the front-end to easily consume the data and dynamically update the subscriber count, ensuring a live, optimized (with cache) and interactive user experience.

Any Questions?

If you have any questions about my setup or if you encounter any issues while implementing this feature, feel free to reach out. I'm more than happy to provide additional explanations, give advice, or help troubleshoot any problems you might run into.

Here Are The Top 3 Reasons I’ve Created A Product To Empower Developers to Build Better Websites

Pierre Mouchan — Wed, 23 Mar 2022 08:44:41 +0000

Today, we are living in the digital era of infinite possibilities — Despite their origins, age, and status, people from all over the world are creating different businesses: E-Commerce, tech startup, NFTs, physical goods, etc.

Every one of those businesses needs a website.
Every one of those entrepreneurs will try to reach and find a developer.
Every one of those developers will do the job.

But not every developer will do it CORRECTLY.

Today, through my product and this blog article, I am sharing with you what those past 5 years in the industry have led me to think about my job and my colleagues’ work on the internet.

I. Seeing too many unoptimized websites.

We all see a huge amount of websites that takes ages to load.

You’ll tell me that this is not a problem and that bandwidth will be upgraded in the next following years and that 5G+ will solve all those issues. No more optimizations to do, everything is INSTANT.

Unfortunately, we haven’t reached this point yet — knowing that in my natal country, I am running on E with my mobile connection (Yep, it really sucks.).

The answer isn’t to wait for a magic 6G deployment over the whole globe. We all have to optimize our websites and projects at some point.

It isn’t something easy at first, but with some theory and practice, knowing that the major problems are coming from the size of your images and the libraries that we are using is a big step towards the optimization part.

We often heard a lot about accessibility and this is a fully different and legitimate topic but websites performance is often never taught in classes and online courses.

It should.

Loading time isn’t just a matter of performance — it has a huge impact on a site’s success, too.

Amazon found that every 100ms of latency cost them 1% in sales
Research shows that 53% of mobile users abandon sites that take over 3 seconds to load
70% of consumers admit that page speed impacts their willingness to buy from an online retailer

II. Seeing too many developers diving into big frameworks without having the fundamentals.

Getting rich quick-schemes doesn’t exist. Winning $15,000/month without kicking your own b*tt for years doesn’t exist as well.
I will tell you a secret: it is the same for frameworks.

I’ve seen too many developers diving into React, VueJS, and Angular without any proper fundamentals with JavaScript. Going from HTML basics to React in a few months of practice isn’t the answer.

I met some guys who were trying to handle some React projects without the basics of Javascript. I think you should at least have 2 years of experience in those basics languages before diving into such a thing. (personal opinion)

It’s like throwing yourself in the middle of a lake and asking you to come back to the shore — The problem is: you don’t know how to swim.

Do things slowly
Yeah, I know. It’s frustrating.

You want that job that requires some React skills.
You want to be better than your old colleague who is making awesome websites.
You want to leave your job and become the next Steve Jobs of websites.

It takes time.

Start with the basics, follow some DEV roadmap online: here is one, and, with some practices and real experiences, come back and learn React–in this order.

If you find yourself in these words, read them several times and follow my advice.

III. Seeing too many developers working with the wrong mindset and a bad workflow.

If you’ve been working as a developer for some years now, you’ll know that working on someone else project can be a pain in the ***.

You don’t fully understand his code/choices — you are not inside the other developer’s mind.

You take ages installing it on your computer — because he/she is using different packages, a different database, and some other mystical and strange software.

ANNNND… You’re telling yourself:

“Omg, why did he write that? This is not how it should be.”
“I am pressing SAVE and nothing is being reformated? wtf.”
“This project is a complete mess. Nothing is at the right place.”
“What is this horrible thing: const MyNeWVariAbles = 56*4;”
“Should I take an axe and threat my boss until he gave me something else to work on?”

I mean, there is hundreds of thousands of different packages, libraries, and ways to code, its not something that we can easily avoid? Right?

Indeed.

BUT, it is not an excuse to not order your files and folder correctly. It is not an excuse to avoid commenting your code and it is not a reason to disrespect your own code and work.

YOUR workflow, EVERYONE’s workflow matters.

M-I-N-S-E-T

Sorry, it is not a magical formula that will write some code for you.

It takes years of practice and self-reflection to become a better developer, to be fully responsible towards our own code, and to handle beautiful projects.

We are all improving at our own pace.

A developer with 1 year of experience can actually be smarter and better than another one with 8+ years in the industry–it is only a question of mindset.

Here is a non-exhaustive list of things that comes to me when I am thinking about “Having the right mindset” and “How a beginner developer can actually beat the senior one”:

Looking for new ways to improve
Learning how to write better code
Learning design fundamentals as a developer
Understanding what REALLY matters when handling website performances
Stop loading 15 libraries and packages to just use 4 of them
Stop spending 95% of the project development on the UI part rather than the UX part
Stop thinking about our own dev comfort zone and business before our clients’ and users’ needs
etc.

Today, I hope you fully understand why I wanted to share my knowledge through this product.

A quick article and introduction to what is currently working for me.

The workflow and mindset that helps me save time and do more.

The “behind the scene” concepts that are actually pushing my projects forwards and helping me win some awards.

And, above all, the best practices that lead me to publish wonderful experiences with incredible SEO and performance optimization.

This guy sums it up better than I do:

“More is less.”
— Ludwig Mies van der Rohe

Thanks for reading.

This post isn’t meant to be a ‘self-promotion article’ but if you still want to take a look at all those subjects — Here’s the link to this tool that hopefully will help you in your journey: https://www.staticstarter.com

If you enjoyed this one, take a look at my newsletter — Get my monthly free best resources for developers and designers right into your inbox! 📨
Or simply join the community and follow me on Twitter 🐦

Delivering a good Experience as a Developer

Pierre Mouchan — Thu, 10 Sep 2020 07:56:26 +0000

Quick note: This is my first article, aiming to warn new developers in the industry and giving a small refresh to all developers! I wrote this one using my experience and some other sources that I will link at the end. Enjoy reading!

“No product is an island. A product is more than the product. It is a cohesive, integrated set of experiences. Think through all of the stages of a product or service—from initial intentions through final reflections, from first usage to help, service, and maintenance. Make them all work together seamlessly.”
— Donald Norman

"Make them all work together seamlessly", said Donald Norman inventor of the term “User Experience” and professor in cognitive science in the ’90s at the University of California in San Diego. We should know, as developers of any kind, that our mission is to deliver a decent user experience. No matter what (and we will talk later of this “no matter what” again), we have to deliver something solid, something fast and something that can be easily understood and used. This is primarily the job of UX Designer to ensure that our app/website got a good UX but we, as developers, are also responsible for it and we need to make sure it works well.

User Experience (UX) and Developer Experience (DX)

Okay, okay slow down… Let’s defines both of them before diving into the real subject. We often hear about user experience and we should all be aware of this term.

User Experience

User Experience (UX) is really hard to explain… Simply because it means A LOT, and regroup A LOT of things. User Experience is a middle between “User Interface Design” and “Usability”. UX design, like I said cover a vast array of areas. UX design is a long, long process than even begins before the app is in the user’s hand.

Developer Experience

Developer Experience (DX) is quite a new term in the industry. It is greatly related to UX in a sense, and clearly self-explanatory — "The experience lived by developers.” On the other hand, DX is related to some services especially made FOR developers (the targeted audience).

Let’s take Stripe for example (an online payment platform), its usability is quite interesting. How can you know that this service respond to a DX and not an UX? So … you create an account, you log in, you go on the dashboard and BOOM, WOO, Stripe gives you a secret token, Webhooks, a DEVELOPER TAB in the navigation and an API Key?

An API what?

Stripe gives you directly “developers-only” information and doesn’t hide these options and settings in a subdomain like api.stripe.com. It’s why a “non-developer” person will be scared by this weird information and will be less tempted to use this online payment service, while a developer would be in paradise.

A good counterexample is Mailchimp (a marketing platform used to manage mailing list, newsletters and campaigns.) Unlike Stripe, Mailchimp hides the “developers-only” information in a different page. Mailchimp isn’t MADE FOR developers (even if developers can use it easily), their main target audience is marketers, which will not have trouble using it and will not be scared by weird developers stuff.

Have you already seen a random guy using Codepen or AWS? Seriously? Hope you understand the difference now. :)

Internal Developer Experience?

In the previous section, we define the experience that our products as developers should provide. These experiences remains, in a way, totally external, we provide an experience (UX or DX) for a specific external target. We should not forget that we are using the product too (yes, really!) We are touching the internal code of these future applications, so we are using them also, it is logical, right? For me, it’s a complete different branch of the experience that I like to call the Internal Developer Experience. They may sound complicated to understand by now, so l will take an example.

John to the Rescue

John is graduated from a marketing school, he was always a smart person and, as the tech industry arise, think that he should learn how to code. So he spent like 5 months taking courses over and over about HTML CSS and JS stuff to get his first job at “Lorem ipsum Agency” as a Front-End Developer. John never worked in a team before, he was just taking these courses online on “How to build a TO-DO list in HTML” (Please stop building to-do list guys, please…). John’s first mission was to build a website for a future industry with a navigation bar, a video player and a gallery. No problem for John, he made it successfully without any issue. He finished his website in time and the website is working, has a great User Experience and good performance for a new and fresh developer in the company.

(Until then, no worries, we agree?)

… then Sarah came

Next week, Sarah, another developer of “Lorem ipsum Company” had to develop a contact module on john’s website. So, Sarah opened his favorite code editor, clone the repository of John’s website and, and……
She was completely lost, she didn’t understand any lines of code of john’s website, and the folder structure of this project was completely a mess!
So, john had to take 5 hours to explain each file and function to Sarah, they lost a total of 10 hours of work (2 * 5 hours) and made “Lorem Ipsum Company” lose money and time.

The real question is: Why and How John passed a bad project to Sarah?

(Do you begin to understand where I’m going with the “Internal Developer Experience”, wait a minute, I will explain it in detail.)

This is a schema representing the time spent by John working on his website.

But … something in this schema is missing, something crucial is missing in John’s website. John does not understand why Sarah can’t work on it. John forgets about the “Internal Developer Experience”, he forgets about the best practices in terms of “working in a team” and that his code should not JUST be readable by himself but by ANY developers.

So let’s take a look at John’s timeline and let’s correct this. Here is what john should have done with his project.

What a complicated timeline? Isn’t it? How can John do two things at the same time? And firstly, what’s documentation and refactoring?

Let’s start with the beginning, definitions.

Code refactoring is the process of restructuring existing code into a more “readable” and often more “performant” of this code while preserving its functionality. Refactoring is intended to improve the design, structure, maintainability of an existing code source while creating a much cleaner, less complex and a more architectural version of it.

With some little refactoring session, John would have delivered a better experience to Sarah, right?

Can he do better than that? (Answer: always!)

Documentation is documentation, seems pretty obvious, but what does it mean for a developer?

It sounds simple? Written good comments is hard, it takes time, sometimes you know what you are doing, but you have difficulties to explain it, or to be sure to be understood (myself included). You have to be explicit about WHAT the code does and HOW it does it.

Last advice:

Your documentation needs to be ready at any time, be sure not to do it the last day. Example: you get sick Monday and the delivery is Tuesday, I hope someone in your company can work on your project!
Don’t over-document: The code may be self-explanatory sometimes. You should have good quality and minimal documentation in your source code.

Documentation has to be part of our job as developers, you have mainly two cases where you NEED to document it:

The first one: The case of John and Sarah, you have to pass a project to a colleague, your code needs to be enough documented to be understood by others than yours. It seems logical, since the other developer is not in your head and not behind you when you are working in your company (I hope), he can’t completely understand the “way” you developed the project.
The second one: Imagine working on a website, everything is fine again (like John’s case). One year pass, and you have to get back on this project and make adjustments on a module that you made 1 YEAR before… And you know what? You don’t understand any lines of codes! Good luck … and document it this time!

I could have made a full article on just “refactoring” and “documentation” but this is not the main purpose of this article (maybe one day), I let you google these terms if you are looking for more information.

Even if these two methods sounds like an obligation, we often tend to forget the cons that comes with the pros:

PROS:

The code is more readable, simpler and cleaner.
We ensure that we are going in the right direction when we are coding and adding comments at the same time (to know what we are doing).
Passing the project to another developer is not a pain (on both sides).
You could save money, time and headaches !

CONS:

If the code changes, you have to changes and correct the comments (nearly ever done).
It takes times, refactoring and documenting your code isn't free. It cost you time and so money.
If you have a short deadline, you would sometimes have to neglect the 'refactor'. Deadlines come before UX / DX and Internal Developer Experience unfortunately.

Summary

Did you remember ?

"...Think through all of the stages of a product or service – from initial intentions through final reflections, from first usage to help, service, and maintenance. Make them all work together seamlessly." — Donald Norman

“From first usage to help, service, and maintenance.” “Maintenance” here refers directly to what we talked about (Internal Developer Experience).

Today, I wanted to separate these three topics (UX/DX/Internal Developer Experience) but they are in a way all linked together. I hope you understood the importance of them and you will apply them in your future projects. Again, documenting a project is hard, it takes times, but the benefits are worth it.

They are all made to ensure the future of an application / website.
UX and DX for growing and keeping the users base and the Internal Developer Experience to ensure the maintainability and the evolution of it.

Oh, one more thing!

You can follow my adventures on social networks! 🚀

You can find my social networks bellow next to the“Follow” button, which you should have already clicked! 😎

Sources: https://developerexperience.io/practices/good-developer-experience

https://css-tricks.com/what-is-developer-experience-dx/

https://en.wikipedia.org/wiki/Code_refactoring

https://blog.submain.com/how-to-document-code/