Table of Contents

· It’s been 5 years …
· What Changed with me?
· Entering Mobile Development
· Being in the Flutter World
· Entering Blockchain & Web3
· The Maestro I’ve become
· The Expert’s Paradox
· The #GDE Exposure
· Honorary Mentions
· Parting Words

It’s been 5 years …

It’s been 5 years since I last shared my developer career story. That was back in 2020, when I had become a Google Developer Groups on Campus (GDGoC) Lead. At the time, the GDGoC program was called Developer Student Clubs (DSC). In that piece, I wrote about my story from 2015, when I was first exposed to programming in secondary school, through 2020, when I was deeply involved in the community.

Now, in 2025, another five years have passed.

In this retrospective, I will walk you through my unique experiences, lessons learned, more community engagements, and of course, about being in the Google Developer Experts (GDE) program.

What Changed with me?

In 2020, I was a full-stack web developer. Today, I’m a full-stack blockchain, mobile, and web developer. Back then, I was a GDGoC lead, organizing local events in school. Now, I’m a GDE, mentoring others, speaking at greater events, and sharing expert knowledge on Google technologies.

At the time, I had built a card game with Java and followed various tutorial projects. I had also built the first version of my portfolio website and delivered my first freelance website gig. Shout out to my cousin, Ebuka, for that referral.

Since then, I have worked with various teams and built multi-user production software. I have learned about system architectures and gained mind-blowing developer experiences. I won a big hackathon, published many articles, and spoke at multiple events. I have met many people and, of course, have grown older 😎.

It has been an additive process. Learning a new technology does not discard old ones. New experiences do not invalidate previous ones. I am simply stacking knowledge which in turn builds expertise.

Overall, I keep learning. I’ve learned a lot about Cloud and AI. I build with AI and manage deployments on Google Cloud. Last year, I earned the Associate Cloud Engineer Certification. This year, I’ve trained different audiences on “building with AI”.

Entering Mobile Development

By the end of 2019, I was already this good in many web technologies. I wanted to venture into something different. In my locality, in most freelance gigs, mobile apps are the next in demand after websites. So I felt like digging into apps.

To get started, I took the time to overview mobile technology and decide which to use. I did some research and checked out Android native with Kotlin, React Native with JavaScript, and Flutter with Dart. After “testing the waters”, I knew Flutter was for me.

Flutter had the most seamless developer experience. Its hot-reload feature and cross-platform ability were mind-blowing. I loved how Flutter code felt close to plain English (due to widget names and syntax). The Flutter community was also very inviting.

I spent time reading the Dart and Flutter docs. They were easy to grasp because I was already good at coding and UI. To build my skills further, I rebuilt the Joker card game I had done in Java with better algorithms and data structures in Dart. I also read a lot of code from open-source Flutter apps to get the hang of it.

Being in the Flutter World

I made cool cash with Flutter. Over the years, I worked with Vorbtech Innovative Solutions to build apps for clients. I worked with Coders Triangle to build CTLearn, with LokDon to build WalletSMSLockr, and with Dado Food to maintain their ecosystem of apps (Customer, Rider, and Vendor) across Google Play and Apple stores.

There were other side gigs I delivered successfully.

Getting those jobs was purely from the community. I was always referred or recommended by others. I didn’t get to apply at any point. Indeed, the community is truly priceless.

Around 2022, I got accepted as a freeCodeCamp contributor. As a contributor, I write articles that are read by developers across the community. I wrote articles about things I had learned and things I had figured out while studying and using Flutter.

🥳🥳🥳 Joining freeCodeCamp as a contributor! | Obumuneme Nwabude | 19 comments

The first article was about “How to Implement Any UI in Flutter”. Surprisingly, I received the most “thanks tweets” for it. Guess it is really helpful to beginners.

I also wrote articles on Flutter that got published on CSS-Tricks and Sweetcode.

Aside from coding and writing articles, in 2022, during my free time, I answered questions in Stackoverflow on anything I know. Additionally, across these years, I have had many speaker and workshop sessions over the years on Flutter.

Naturally, I’m a good orator. I use this skill to teach and share about Flutter. I’ve had sessions on UI, animations, forms, state management, CustomPaint, Flutter for web developers, Flutter with blockchain, panel sessions, and more.

In my opinion, my most outstanding Flutter session was at #DevFestLagos2024. It was a highly technical workshop on “How to build Android Bubbles in Flutter”. It was inspired by my experience an building SMS app. At the time, there was no content online on the topic. The recorded session is on Youtube and the workshop code is on GitHub.

Entering Blockchain & Web3

As with my habit of adopting something new, by the end of 2020, the next buzzing tech word in my locality was Crypto. I embarked on my blockchain journey, overviewed Solidity and Rust, and got started building on-chain.

There are interesting engineering differences in Web3 vs Web2. I guess I will put up an article about this later. At its core, blockchain apps focus on distributed access and security concerns.

In all honesty, Web3 is a still a working progress. Yes we have working blockchains and continuous adoption. However, there is still technical groundwork to do for seamless real-world integrations.

For example, you can’t run long loops (for, while, …) within the chain, or the transaction will fail. Or is it the 24kb limit of Solidity contracts you have to handle? Or is it the awesome gas fees 😂

Crypto is a work-in-progress AND it has its proofs-of-work.

Regardless, I’m now a guru in this domain. Together with my co-founder, we’ve built three solid Web3 dApps with production users. One of which is Chainbills that won 2nd place in the Wormhole side-track of the Solana Renaissance Colosseum hackathon in 2024.

Best Multichain Project | Superteam Earn

Why crypto? Well, I admire the idea of decentralization: giving power to the community.

It is difficult, or almost impossible, to fully run things successfully in a decentralized way. We need some centralization at certain points. “Yin-Yang” mixture kind of. Either way, blockchain is cool. I’m glad to have entered there and I encourage you to check out the technologies we have here.

The Maestro I’ve become

Programming languages usually vary in syntax and few specialties. In general, you can re-build the exact same software in another language. Semantics in language usage is usually the difference.

Figuring this out explains why it is not about the number of programming languages you know, but how good you are at core programming. In diverse software categories, there are always similar code patterns.

I’ve grasped that core programming and it’s like second nature to me now. In fact, because of this, it is now effortless for me to venture into a new programming domain (I’m thinking of the next one already 😂)

I have improved to the point that I know what a given block of code should do just by reading it. When I read code, I instantly understand the execution flow.

Nowadays, I mostly do code reviews for projects rather than programming like I did before. I quickly spot UI flaws, logic errors, and security mishaps in codebases of languages I know.

Behind the scenes, it has been years of efforts that naturally resulted in mastery. You know you have become good at something when you can do so much of it while also teaching or inspiring people.

They say programming is quite different from coding. The difference is in the thinking. The engineering in software engineer is that you can plan the solution or algorithm of a problem. That’s the programming part.

At CTO levels, we do this across the system and in the bits of each sub-service. AI can’t do that. It can write the code we tell it to. But, it can’t have the entire product context at all times like we humans always do. That’s by the way.

I’m not saying I’m perfect. Learning never ends and I keep growing. But once in a while, it’s okay to look back and celebrate how far we’ve come.

After gaining solid grounds in Blockchain technologies, I embarked on Cloud & AI. With my technical expertise, it was effortless to grow far and fast in these domains.

At DevFest Abuja this year, I anchored a workshop on “Leveraging BigQuery for Business Data in Google Cloud”.

The Expert’s Paradox

Sometimes, what makes a maestro (master) is strength in multiple related domains, not only high expertise in one. At this high level of orchestrating systems, I clearly see how technical knowledge in different areas comes together to make me a good system admin. You know, “jack of all trades” kind of approach.

Notwithstanding, I’m young and I’ve been busy. By busy, I mean very busy. Work, life, community, and other responsibilities consume so much of my time. I’m happy they’ve been fruitful. I pray the future remains brighter than ever.

I rarely have time these days, not even to share updates on social media. There are many technical articles I want to write and publish, but there’s no time. Hopefully, in this new year, I will do better.

Still because of time constraints, it took me a long while to draft this retrospective story. I had it all planned in my mind but no time to write it down. I’ve been busy being an expert 😅. I am glad that this story is finally in written words.

The #GDE Exposure

The Google Developer Experts (GDE) program consists of individuals who meet two criteria:

1. Have advanced-level knowledge and experience in a specific Google technology AND
2. Continuously contribute to the community around that technology.

The program is both a community for its members and an award for their voluntary contributions. Community contributions include open-source code activity, published libraries, writing articles, making videos, speaking at conferences, Stackoverflow answers, etc. Once you have a track record of such over the years, you are a good candidate for the program.

At various events, I met mentors and individuals who introduced and recommended me to the GDE program. By mid-2024, I applied, was interviewed, and got accepted.

As a GDE, I have enjoyed countless benefits from Google:

• Global Recognition and Listing on the Experts Directory
• Access to the global and local network of GDEs
• More speaking opportunities
• Invitations to Google-run events
• Google Developer Premium Subscription (my favorite; it provides other premium resources)
• etc…

Becoming an Expert has catapulted my developer career. I have learned much more and met more industry leaders.

I volunteer because I naturally can do it and others benefit from it. I have helped and mentored various individuals. I will continue this especially as the GDE program now enables me to make more impact.

Recently, thanks to Google, I was at Nairobi, Kenya for the GDE Sub-Saharan Africa (SSA) #TrainTheTrainer event. I met with fellow GDEs from the region, learned more about AI and Hardware, and gave feedback about Google Products. It was a unique networking experience to spend quality time with other Experts.

I was very active and notorious at the event — helping with minor tasks, exchanging contacts and taking photos with everyone present. After all, we are a closed group 😎.

#trainthetrainer | Obumuneme Nwabude

Honorary Mentions

That’s it for my 5-year story. But before we part, I would like to mention a few people and share my future plans.

First is my co-founder, Maxwell. We first met at a bank and were sharing our displeasure with the money systems. Next day, we were coincidentally together in a hospital. One thing led to another and now we are family.

Max is one-of-a-kind. His resilience needs to be studied. I hold him in high regard. He pushed me deep into the crypto space and he has been involved in many parts of my personal life. Thank you, sir.

Another person is the one who introduced me to the DSC program (now GDGoC). We met during the Google Africa Developer Scholarship. He was the mentor of my peer learning group. By following his lead, I was exposed to many technologies and industry leaders.

Today, Akinjobi Sodiq works with the Google Developer Ecosystem. But to me, he remains my first eye-opener and I owe him great respect. Thank you sir.

Next on my list is Auwal MS. He was the program manager for the DSC program in SSA and later was in charge of GDGs for some time. He guided me and gave me perfect advice at strategic points. I owe a good part of my success to him. Thank you sir.

Someone else I celebrate is Eunice Allela. She oversees GDEs in the SSA region. We met last year, before I became a GDE. She was the final person to recommend me for the program. Since then, I haven’t let her rest. Sorry ma, but it’s my little way of trying to stay impactful. Thanks for the many things you do.

There are many others who deserve honorary mentions here. I’m quite social and have a huge “people dictionary”. I’m sorry I can’t call out everybody, but believe me, I sincerely appreciate you. Is it Festus that kept recommending me? Is it Phenom, Leo, Gabriel, … who fulfilled one task or the other for me?

Or is it the multiple peers, colleagues, GDG organisers, fellow GDEs? Naming everybody would fill this entire story. Thanks, everyone; you are all the real MVPs. We will see at the top! 💪

Parting Words

Thank you for reading this far.

Among the many things that inspire me, ability stands out.

“If you can think it, you can do it.”
“Why keep it for later if you can do it now?”
“Believe you can and you’re halfway there.”
“Start where you are. Use what you have. Do what you can.”
“You can do anything you want if you stick to it long enough.”
…

Looking into the future, I intend to help create more community impact in Cloud and AI as I’ve become so proficient in them as well. I’m also preparing to take the Google Cloud Professional Data Engineer Exam.

As for the next technology I will pick up, I am strongly considering hardware: ARM, Arduino, microcontrollers, Raspberry Pi, etc. This time, the inspiration is thanks to Robert.

I haven’t fully decided yet if I will write code for those systems. Well, let’s see how it goes.

Cheers to continuous growth and development.
Cheers to more knowledge, expertise, and adventure.
Cheers to your success — yes, the success of you reading this 😇.

See ya,
Bye 👋.

Road to Mastery — Being a Google Developer Expert was originally published in Google Developer Experts on Medium, where people are continuing the conversation by highlighting and responding to this story.

Many businesses have a booking system. For example:

• Booking a consultant/therapist,
• Reserving a hotel room,
• Reserving a hall/an auditorium for an event,
• etc.

All booking systems have one thing in common: leaseable services (or resources). Customers can use these resources for a set period of time.

Booking is planning the availability of such resources. Booking/Reservation systems are important because they help with avoiding clashes among customers. The resource(s) can only be available for one customer at a time.

This article tells how to plan any booking system with Firebase. If you are not using Firebase, you will still find some concepts in this article useful. Especially the idea of a template timetable.

Table of Contents

∘ How does booking work?
∘ Constraints of a Unit Time per Slot
∘ Various degrees of booking complexity
∘ How to structure an availability/template timetable
∘ A Firebase briefing
∘ Overview of a Booking System with Firebase
∘ How to structure the reservation documents in Firestore
∘ How to use a calendar in the UI of a booking/reservation system
∘ How to query for available slots in your UI with Firestore
∘ How to query for available slots in your UI with Cloud Functions
∘ How to make a reservation with Cloud Functions
∘ Miscellaneous Concepts
∘ Thank You!

How does booking work?

Before tech became standard, bookings were manual. A secretary had to keep some calendar. To make a reservation, the secretary would check for available slots.

A prospective customer will agree with the secretary on a particular time slot. This slot becomes the booking or the reservation.

Now many apps have gone digital. We do reservations and have retained the manual booking algorithm.

The process is straight to the point:

• Check for available slots.
• Display them (in a calendar).
• On a customer’s request, reserve a chosen slot.

A customer can’t make a reservation on an already-taken slot.

From the above, we can draft out the following 3 functionalities of booking systems:

1. Having time slots for when the resource is available.
2. Booking/Reserving the resource based on a customer’s choice.
3. Ensuring that no other customer books/reserves a taken time slot.

These 3 points will be helpful to us as we explore how to structure any booking system.

Constraint of a Constant Time per Unit Slot

Most booking systems (if not all) have a constraint on the lease of their resources. The constraint is, per lease, the reservable time slot is an integer multiple of a constant.

That is, the entire system knows that there is a base duration for how long a customer is using a resource. It could be an hour, 2 hours, a day, etc. This base time is the time per unit slot for that resource.

For example, you can book a hotel room for a day or for integer multiples of a day. You can’t book a hotel room for half a day or for one and a quarter days at once. Only a day or two days at a stretch or 3 days, etc.

In the context of the hotel room, the time per unit slot is 1 day.

Constraining this value to a constant is important for most booking/reservation systems. All code in the system uses this constant to determine how long the resource(s) will be in use.

This constraint is the basis of booking. If it doesn’t exist, the booking process becomes very difficult to manage.

Everything is possible. Such systems exist where there is no such constraint of a constant.

If that is the system you are building, then the major part of this article might not help you. If you fall in this category, please share your use case. Let’s see if we can help plan your system.

Various degrees of booking complexity

Let’s take a hotel for example. When you reserve a room for a specific day, that day will no longer be available for any other reservation.

Managing hotel bookings (per room) is easy. This is because hotel rooms usually have daily slots. So we mark a day on a particular room as taken and that’s it.

Things get different when for a given resource, the time slots are a little dynamic.

Consider a therapist’s schedule. Customers can book hourly slots with the therapist.

At first, it seems easy to build a reservation system for this therapist. I mean, the therapist could be available from 9 to 5, every Monday to Friday.

Things change when there are working hours when this therapist is not available. Or when there is a known circumstance preventing a regular flow of availability. Or when there is the need for custom availability at custom times.

As you see, sometimes, in our products, the resources we are reserving don’t have easy slots. The booking process becomes more complex.

For the sake of clarity, let’s categorize these degrees of complexity. We will use these categories in consequent parts of this article.

Level A. When we have to allocate a resource per day or per hour or per multiples of those.

Level B. When we can’t do Level A because there are exceptions in some hours or some days. Our system needs to have an “availability timetable” for our resource(s). The system will use this timetable to make reservations.

Level C. When we have many resources. And each resource has its own different availability timetable. And their timetables are different from each other.

Irrespective of your system’s complexity level, making reservations is the same process.

How to structure an availability/template timetable

This concept is more of an intuitive one. You don’t need it if you are in Level A or if your “reservable” has regular slots (like hotel rooms’ daily slots).

But, if it doesn’t, the following are tips on how you can plan the template timetable for the resource. The idea is to craft a data structure that tells the codebase when the resource is available.

I found it easier to use numbers for everything in the timetable. So when recording days of the week, 1 will be for Monday, 2 for Tuesday, etc.

Also, for hours in a day, using the 24-hour style is better than the 12-hour style. It is harder to code for AM/PM when 13 can mean 1 PM, 14 can mean 2 PM, etc.

Furthermore, these timetables should only record only the start times of available slots. This is because the time duration is the same for every lease (constraint of a unit time per slot). And by extension, there is no need for hardcoding end times in the timetable.

Besides, keeping track of both start and end times in the template has a disadvantage. Updating the timetable will be more demanding.

Let’s look at 7 example use cases with varying complexity.

// 1. Varying start hours in a day, for every day of the resource's use.
[8, 10, 11, 13.5, 14, 15]
//    The above means that for every day, we can have 6 slots in a day
//    which each start from 8 AM, 10 AM, 11 AM, 1:30 PM, 2 PM, and 3 PM.

// 2. Varying days in a week, for every day of the resource's use.
[1, 3, 5, 6]
//    The above means that for every week, we can have 4 daily slots
//    which are Mondays, Wednesdays, Fridays, and Saturdays.

// 3. Same start hours on varying days of the week.
{
  "hours": [8, 10, 14, 16],
  "days": [1, 2, 4, 5]
}
//    The above means that the resource is available on Mondays, Tuesdays,
//    Thursdays, and Fridays ("days"). And on those days, 
//    slots are from 8 AM, 10 AM, 2 PM, and 4 PM ("hours").

// 4. Varyings dates in a month, for daily use of the resource.
[2, 3, 5, 6, 8, 10, 12, 14, 17, 18, 19, 21, 25]

// 5. Varying dates in a month, for varying days of the week.
{
   "days": [5, 6, 7],
   "dates": [2, 3, 4, 5, 8, 9, 11, 12, 15, 16, 22, 25, 27, 28]
}
//    The above means that the resource is only available on month dates,
//    that fall on weekends. 

// 6. Varying start hours in varying days of the week.
{
  1: [8, 10, 11, 13.5, 14, 15],
  2: [9, 12, 14, 15, 16, 17],
  4: [8, 9, 10, 12, 14.5, 16],
  5: [11, 12, 13.75]
}
//   The above means that: 
//   * Monday has a similar schedule to use case 1 above. 
//   * Tuesday's slots are entirely different. 
//   * The resource is not available for reservations on Wednesdays,
//     Saturdays, and Sundays (their keys: 3, 6, 7) are not included. 
//   * Friday has only 3 slots unlike the others.
//   * And on Friday, the last slots starts from 1:45 PM

// 7. Varying start hours, for varying dates of the month.
{
  2: [8, 10, 12, 14, 16],
  3: [7, 9, 11, 13, 15],
  4: [9, 10, 11, 12, 16],
  // ... other dates and times
  15: [7, 8, 9],
  // ... other dates and times
  28: [9, 10, 11, 12, 13, 14, 15],
}
//    The above means that: 
//    * The 2nd of every month has 5 slots (like the 3rds and 4ths). 
//    * Every 15th has only 3 slots.
//    * 28ths have 7.
//    * (You can fit in for other dates).

As the snippet shows, the timetable is the smallest data structure that tells the resources’ hiring frequency.

The above examples assume easy times per unit slot (hourly or daily). The same concept applies if you use a different time per unit slot. E.g. 15 minutes, an hour 30 minutes, 3 hours, 6 hours, 2 days, etc.

Some examples above are unrealistic. Look at the 7th example. I’m not sure there exist real-life businesses that lease out their services following it. Well, as developers, we should account for every possibility.

Remember that you don’t always need a template timetable. In fact, you should not craft one if you don’t need it.

Only create one if your system doesn’t allow a regular flow of use (every hour, every day, every 2 days, etc.).

Drafting a timetable is creating a data structure that tells the resources’ availability. I trust your intuition for doing it well as there is no one-fits-all method for this.

Having created a template timetable, where do you store it? Where do you place this data structure that every other part of the system should use?

The answer is it depends. You either hardcode the availability timetable or you save it in a database.

If your system is leasing one resource, save the timetable in the code. Also, if you are leasing a fixed number of resources that don’t easily change, then save the timetable in the code too.

When saving it in code, export it as a global constant. Every part of the code that needs to make reservations or display them will look up the timetable.

If the resources (or their details) often change, it means you are storing them in a database. In this scenario, the timetable should be in the database too. It should be there because it might also be changing.

These resources can have different template timetables. That is, your system is in Level C. In that case, store each timetable together with each resource. When leasing a resource, check and reserve while following its timetable.

Level C is the most complex. A practical example of a Level C system is a session/tutorial management system. A system that connects mentors/tutors and students.

In this system, tutors come and define when they are available. In turn, students come and reserve slots in the calendars of these tutors.

Users can specify their own availability timetables. We have no other choice but to save each timetable together with the resource (the tutor’s data in this case).

The time per unit slot of all resources in this very complex booking system is still constant.

It is also possible that resources have different times per unit slot in your system. In that case, for each resource, also save it’s time per unit slot in the database.

That will be a lot of complexity and I’m not sure of the app’s UI engineering to fit all possible use cases.

That has been a lot on the theory and engineering of reservation systems. Let’s switch over to Firebase and the implementations of booking.

A Firebase briefing

Firebase has Authentication to sign in users. Firebase Authentication allows email and password or federated identity sign-in. We can use Firebase Authentication to know which user is making a reservation.

Firebase also has Cloud Firestore, a NoSQL, and a client-accessible database. By being NoSQL, you can store an entity’s data (a reservation) as a document. In turn, documents are grouped into collections (reservations collection).

With Firestore, apps can access documents and collections through the Firebase SDK. As such, you can query available slots and render them to the user directly from your UI.

Firebase also has Cloud Functions. Cloud Functions are invocable code that securely runs inside Google’s data centers. They are serverless endpoints that you invoke only when you need them.

A booking system can use Cloud Functions to make a reservation. You can liken the Cloud Function code to the manual secretary. It will check if the proposed slot is free and reserve it for the customer.

That is why we are using Cloud Functions for reservations. To ensure that nobody makes a booking on a slot that is already reserved.

Also, we want to reserve a “reservable” time slot. If the resource uses an availability timetable, we can check if the reserved time is part of it.

Overview of a Booking System with Firebase

First, define the resource(s) that customers can reserve.

State it/them out and have it (them) in mind. Event Centre, Hotel Rooms, Therapist Times, etc.

Next, figure out how often these resources are “reservable”. If your system falls in Level A (simplest) category, then you have less work to do.

You will build the system around this regular frequency of resources’ availability.

If your system falls in Level B or C (more complex categories), craft the template timetable(s). Store them in code or in Firestore. Other parts of the system will look up the timetable when reserving resources.

Once you’ve defined this time-slots abstraction, the next thing is to build your UI. In most cases, you will have a calendar that displays taken and available slots.

In most cases, users have to sign in to make a reservation (so that we know who is booking a resource).

Once in your app, users can view booked slots in the calendar. You can fetch reservations from Firestore (you would have stored them there).

Finally, to make a reservation, the system should make calls to Cloud Functions. You will have to create the functions yourself. In the functions’ code, you will store the reservation in Firestore.

To recap:

1. Define the reservable resource(s).
2. Determine (from your product spec) the complexity level of the resource(s).
3. If in Level A (simple daily/hourly availability), use that logic when building.
4. If not in Level A, define the availability/template timetable. Other parts of the system will rely on this.
5. Build your UI and set up Firebase to retrieve slots based on the availability timetable of 3 or 4 above.
6. Use Cloud Functions to allow users to make reservations.

From now on, we will look at some of the above flow in detail.

Note that we are using JavaScript to write Firebase-related code in this article. If it doesn’t suit you, re-implement the algorithms in your choice programming language.

How to structure the reservation documents in Firestore

There are some reservation systems that only one user accesses. The system is an aid to a real-life clerk in some office.

In such a system, this clerk or secretary creates all the reservations. You can see such simplicity may be in a hospital’s reception or the work of a personal assistant.

In this case, a reservation document will have the following:

• the start time of the reservation,
• the end time (or the duration),
• the customer’s data,
• and any other necessary info.

It is possible that there are many receptionists or clerks. In that case, also store the userId (or uid) of the person making the reservation.

If customers reserve slots themselves, store their uids in the reservation document.

Storing their uid is necessary to keep track of who did what. Storing is also useful when fetching all the reservations made by a particular admin or user.

Below is a TypeScript interface. It defines a proposed type signature for your reservation document object.

// reservation.ts model file
// (possible structure of a reservation document)

interface Reservation {
  "uid": string, // if need be
  "startTime": Timestamp,
  "endTime": Timestamp, 
  "customerInfo": { // not necessary if you can obtain this from the 
    "name": string,  // customers database/info or from somewhere
    "email": string, // else in the database. can also be useful for future
    "phone": string, // reference if in case the user deletes their account
  },
  "additionalInfo": { // for demo purposes, please use what is 
    "reasonForVisit": string, // relevant to your system.
    "hasPaid": boolean
  },
  // any other neccessary data according to your system
}

The above code can serve as a guide and should not be an absolute reference. Only declare properties that are relevant to your system.

The type signature of startTime and endTime is Timestamp. Timestamp is a valid data type in Cloud Firestore. It is the best option to represent a specific date and time in our database.

startTime and endTime are properties that all reservation documents should have. I mean, we are booking this resource for a specific time right?

Another variation is to store startTime and duration instead of startTime and endTime. Both do the same thing. If you are storing duration instead, choose whether to store it in seconds or in minutes.

How to use a calendar in the UI of a booking/reservation system

Most if not all booking/reservation systems have a calendar in their UI. The calendar makes it easy for the user to get to the date they want the resource and then make the booking there.

Another advantage of the calendar is that it prevents the user from making a reservation in the past. The user could view past reservations through the calendar but not edit them. But can’t book anywhere on a date older now.

In apps and websites, users can view calendars in various modes: daily, weekly, and monthly. Calendars can also have custom combos like 3-day views, 2-week views, etc.

If your system is in Level A, the calendar’s minimum view mode will be a group higher than the Unit Time per slot. That is, if your resources have daily availability, you want to display the calendar in weeks or months.

If your system has a template timetable (is in Level B or C), the calendar’s view mode should be a time range that matches the range of the template timetable. This is specific to each template timetable.

When a user accesses the calendar page/screen, the UI code should fetch reservations. Using them, the code should disable calendar slots where bookings exist already.

How you implement this depends on how your system works. Let’s say your calendar is in a monthly-view display. And that your reservable is a daily resource. Disable the calendar’s days where there are already bookings.

It is possible that the calendar is in a weekly view display. And there is a weekly availability timetable for the reservable. First, fetch the timetable in the UI. Then disable the calendar spots that are not included in the timetable.

After that, fetch the reservations within the time frame of the displayed week. Then further disable the calendar for those days/hours. The calendar now has only empty slots to book from which the user can book.

If there are no empty slots, the user has to move the calendar to the next week. Your UI code should redo the above fetchings on the change of the “displayed time” range.

This pattern of disabling booked slots can work in any calendar view. The difference is that in daily view, you might be disabling hours instead of days.

This is an algorithm you can use whether you are coding for mobile or on the web. I trust you are a developer (or you are hiring one/some) and how to implement it in the target platform wouldn’t be an issue.

Besides, it will be hard to show a sample code for this as it will deviate from the scope of this article.

How to query for available slots in your UI with Firestore

All calendar views (day, week, or month) have the least date and the highest date in view. Or rather, there is always the oldest date and the latest date in the context of every calendar view.

To query the database for reservations within the calendar view, use these two dates.

For example, let’s say our UI is in weekly view, and the first day is Sunday, 16th July, and the last is Saturday 23rd July. In this context, 00:00 on the 16th is our oldest timestamp while 23:59 on the 23rd is our latest.

Use these two timestamps when querying the reservations collection in Firestore. Following is a snippet of what the query should look like in JavaScript.

oldestDateFromCalendarView and latestDateFromCalendarView are from your UI code.

import { 
  collection, 
  getDocs, 
  query, 
  where, 
  Timestamp
} from 'firebase/firestore';
const reservationsRef = collection(db, 'reservations');

const startTime = Timestamp.fromDate(oldestDateFromCalendarView);
const endTime = Timestamp.fromDate(latestDateFromCalendarView);
const q = query(
  reservationsRef, 
  where('startTime', '>=', startTime), 
  where('endTime', '<=', endTime), 
);
const querySnapshot = await getDocs(q);
querySnapshot.forEach((doc) => {
  // update your UI by blocking calendar spots that match the dates here
  console.log(doc.id, " => ", doc.data());
});

The above is okay if only admin(s) create reservations.

It is not good for systems where customers make bookings themselves. We don’t want a customer to see the details of reservations of other customers. That’s why we need to create a cloud function.

Also, Firebase has Firestore Rules to secure data access from client apps. Use them to ensure that only reservations’ creators can read or update reservations.

How to query for available slots in your UI with Cloud Functions

Let’s create a fetchReservations Cloud Function. It will query Firestore for reservations. It will return only the startTime and endTime properties of every reservation.

You shouldn’t use cloud functions if there is no sensitive data to hide from other customers. Or if secretaries or admins are the people making reservations. In such a case, querying Firestore from the frontend/UI should serve.

The Cloud Function we will create should be an onCall Function. Following is what fetchReservations function should look like.

const functions = require('firebase-functions');
const { initializeApp } = require('firebase-admin/app');
const { getFirestore, Timestamp } = require('firebase-admin/firestore');

initializeApp();
const db = getFirestore();
const reservationsRef = db.collection('reservations');

exports.fetchReservations = functions
  .runWith({ enforceAppCheck: true }) // Optional, but recommended.
  .https.onCall(async (data, context) => {
    // Optional, but recommended
    if (!context.app) {
      throw new functions.https.HttpsError(
        'permission-denied',
        'The function must be called from an App Check verified app.'
      );
    }
    // Necessary to obtain the details of the signed in user.
    // Optional if any body can view reservations
    // Optional if the only admins/secretaries make reservations.
    if (!context.auth) {
      throw new functions.https.HttpsError(
        'unauthenticated',
        'The function must be called while authenticated.'
      );
    }
    const { endTime, startTime } = data;
    if (!(endTime instanceof Timestamp)) {
      throw new functions.https.HttpsError(
        'invalid-argument',
        '"endTime" in data must be a valid Firestore Timestamp.'
      );
    }
    if (!(startTime instanceof Timestamp)) {
      throw new functions.https.HttpsError(
        'invalid-argument',
        '"startTime" in data must be a valid Firestore Timestamp.'
      );
    }
    try {
      const querySnapshot = await reservationsRef
        .where('startTime', '>=', startTime)
        .where('endTime', '<=', endTime)
        .get();
      return querySnapshot.docs.map((doc) => {
        // TODO: also extract any other public reservation data
        // from the following (if need be)
        const { endTime, startTime, uid } = doc.data();

        let isMine = false;
        if (uid == context?.auth?.uid) isMine = true;
 
        // TODO: also return any other extracted data alongside 
        return { endTime, startTime, isMine, id: doc.id };
      });
    } catch (e) {
      console.error(e);
      throw new functions.https.HttpsError('internal', e);
    }
  });

The code of this cloud function enforces AppCheck. AppCheck helps to make sure that calls to the cloud function come from our apps. The function also ensures that only signed-in users can view reservations.

The code then proceeds to verify that the caller provided valid Timestamps. As expected, the function returns an array of reservation objects. These reservations each have startTime and endTimes.

The extra isMine property tells the UI to allow edits or deletes by the user. (Well, that’s if you permit such in your product).

Also, we are returning the database id of each reservation. This is to know which reservation the user would like to edit.

This Cloud Function throws errors where they occur. It is the work of the UI code to appropriately catch and handle these errors.

These error types are from Firebase Cloud Functions and they respond with the appropriate HTTP status code.

The try block is to ensure that our Cloud Function will still respond to the UI if something unexpected takes place. Printing the catch block’s error to the console will show in the Firebase Console Logs for Cloud Functions.

On the frontend/UI code, you will call this fetchReservation function instead of fetching the reservations from Firestore directly. This will help mitigate the issue of privacy.

The frontend/UI code that calls the fetchReservation cloud function should look like the following:

import { Timestamp } from 'firebase/firestore';
import { getFunctions, httpsCallable } from 'firebase/functions';

const functions = getFunctions();
const fetchReservations = httpsCallable(functions, 'fetchReservations');

const startTime = Timestamp.fromDate(oldestDateFromCalendarView);
const endTime = Timestamp.fromDate(latestDateFromCalendarView);
let reservations;

try {
  const result = await fetchReservations({startTime, endTime});
  reservations = result.data;
} catch (e) {
  // TODO: 
  // instead of alerting the browser, show a custom toast
  alert(e);
}

if (reservations) {
  // TODO: 
  // reservations where fetched successfully, disable calendar spots
  // that match the reservations' times
}

The above calls the cloud function and returns the list to the UI code. The code should now use it and block appropriate calendar spots.

So far, we have kept track of reservations and have shown them to the users. Now, let’s look at the last part of the reservations flow.

How to make a reservation with Cloud Functions

The Cloud Functions code for making reservations should do 2 core things:

1. Ensure there is no booked slot on the requested booking time.
2. Make the booking by creating the reservation document in Firestore.

Following is what themakeReservation function should look like.

const functions = require('firebase-functions');
const { initializeApp } = require('firebase-admin/app');
const { getFirestore, Timestamp } = require('firebase-admin/firestore');

initializeApp();
const db = getFirestore();
const reservationsRef = db.collection('reservations');

exports.makeReservation = functions
  .runWith({ enforceAppCheck: true }) // Optional, but recommended.
  .https.onCall(async (data, context) => {
    // Optional, but recommended
    if (!context.app) {
      throw new functions.https.HttpsError(
        'permission-denied',
        'The function must be called from an App Check verified app.'
      );
    }
    // Necessary to obtain the details of the signed in user.
    // Optional if only admins/secretaries can make reservations.
    if (!context.auth) {
      throw new functions.https.HttpsError(
        'unauthenticated',
        'The function must be called while authenticated.'
      );
    }
    const { endTime, startTime, /* any other form data */ } = data;
    if (!(endTime instanceof Timestamp)) {
      throw new functions.https.HttpsError(
        'invalid-argument',
        '"endTime" in data must be a valid Firestore Timestamp.'
      );
    }
    if (!(startTime instanceof Timestamp)) {
      throw new functions.https.HttpsError(
        'invalid-argument',
        '"startTime" in data must be a valid Firestore Timestamp.'
      );
    }
    
    // TODO:
    // Also validate if the duration between startTime and endTime
    // is a mulitple of the Time per Unit Slot for the resource.
    // This is also where to lookup and use the availability/template
    // timetable if that applies to your system.

    // TODO: 
    // Validate any other form data at this point.
    // Form data here means other data needed to make 
    // a reservation according to your system.

    try {
      // fetch booked slots for the requested time.
      const querySnapshot = await reservationsRef
        .where('startTime', '>=', startTime)
        .where('endTime', '<=', endTime)
        .get();
      
      // ensure there is no booked slot on the requested booking time.
      if (!querySnapshot.empty) {
        throw new functions.https.HttpsError(
          'invalid-argument',
          'There are already bookings for the sent time slot.'
        );
      }
      
      const reservationData = { 
        endTime, 
        startTime, 
        uid: context.auth.uid, // if necessary
        /* TODO: add other validated form data */ 
      };
      const newReservRef = await reservationsRef.add(reservationData);

      return { id: newReservRef.id, isMine: true, ...newReservRef.data() };
    } catch (e) {
      console.error(e);
      throw new functions.https.HttpsError('internal', e);
    }
  });

The cloud function returns the created reservation and this time with its id. Use this returned object in the UI to disable the just-booked calendar spot.

The above code includes some comments. The comments tell where you should get form data, validate it, and add it to the reservation document.

Form data here is other details that the user provided when booking. These are details relevant to your system. Maybe if the user selected massage services while booking the hotel room. Or the patient’s history/story for the consultant/therapist. Or whatever.

The UI could get that info from some form that pops up after the user has selected a calendar spot. Send that info alongside the time slot to the makeReservation cloud function to book that user.

In the case where your system has multiple different resources, this is where to fit more details about the resource choice into the reservation document.

As for how to call this function from the frontend/UI code, the following JavaScript snippet should help.

startCalendarTime and endCalendarTime are from the time slot that the user selected.

import { Timestamp } from 'firebase/firestore';
import { getFunctions, httpsCallable } from 'firebase/functions';

const functions = getFunctions();
const makeReservation = httpsCallable(functions, 'makeReservation');

const startTime = Timestamp.fromDate(startCalendarTime);
const endTime = Timestamp.fromDate(stopCalendarTime);
// TODO: obtain other form data from the UI
const reservationData = {startTime, endTime, /* other form data */ };
let madeReservation;

try {
  const result = await makeReservation(reservationData);
  madeReservation = result.data;
} catch (e) {
  // TODO: instead of alerting the browser, show a custom toast
  alert(e);
}

if (madeReservation) {
  // TODO: 
  // reservation was successfully created, update the UI or navigate out
}

Miscellaneous Concepts

Let’s look at 5 extra ideas that could be part of any booking system.

1. Updating/Deleting Reservations

Users should be able to update/delete their reservations. However, depending on your system, you might not allow this.

You could allow updating to a certain degree. Maybe updating appointment details only. Or allowing updates of time if the update is coming 3 days before the schedule.

Deletes are sensitive. For example, let’s say a hotel’s policy includes non-refundable payments. This hotel’s booking system should not allow deletes.

If you have gotten here, the code for updating or deleting wouldn’t be an issue for you.

2. Listening to Real-Time Changes

Firestore has real-time abilities. It is capable of updating your frontend code with data as that data changes elsewhere.

Booking is sensitive. We want to always be sure that a user doesn’t book on an already booked slot.

Using a listener, we can update the calendar UI with booking slots while the user is on the page. It makes the UI reactive and helps ensure the one customer per slot policy.

When fetching reservations from Firestore, fetch them through the query listener. This way, let’s say another user creates a reservation elsewhere. The calendar of the current user will auto-update with a block on that reservation.

Given the following query:

const q = query(
  reservationsRef, 
  where('startTime', '>=', startTime), 
  where('endTime', '<=', endTime), 
);

Instead of a one-time fetch of the query:

const querySnapshot = await getDocs(q);
querySnapshot.forEach((doc) => {
  // update your UI by blocking calendar spots that match the dates here
  console.log(doc.id, " => ", doc.data());
});

Listen to changes and Firebase will handle the rest:

onSnapshot(q, (querySnapshot) => {
  querySnapshot.forEach((doc) => {
    // update your UI by blocking calendar spots that match the dates here
    console.log(doc.id, " => ", doc.data());
  });
});

3. Temporary Unavailabilities

How do we handle cases when the leasable resource would be unavailable for a normal time slot? How does the system exempt that particular unavailability circumstance?

For example, due to scheduled maintenance, a hotel can withhold some rooms on a particular day. A therapist can be on leave. A leasable hall can be on renovation.

An easy answer could be to create a reservation for that time slot and that solves the problem. Another way is to let the system be aware of these kinds of circumstances. And also check for them while checking reservations from the UI.

You shouldn’t worry about this when you start building. They rarely happen. Also, you are trying to build a Minimum Viable Product. But if you come across the need to handle this scenario, you will scale through.

4. The need for storing both start and end times in reservations

At first sight, it may not make sense to store both startTime and endTime/duration in a reservation document. After all, just the startTime is necessary.

This is especially true, given the constraint of a unit time per slot. Every code knows the duration of a reservation and can calculate the endTime. This thought pattern is okay. But it doesn’t scale. We need to build robust systems.

Saving either the duration or the endTime in every reservation makes the data complete and less ambiguous. It makes easy access to or display of correct and complete data about a reservation anywhere.

It helps any new member joining the team to understand what’s happening (by observing patterns).

It also helps to maintain clean records of the system even if the system changes the unit time per slot for those resources.

Because at a future time when the unit time has been increased or decreased, past reservations should still show or use the previous “unit time per slot”.

For a concrete example, if a therapist changes session times to 45 minutes instead of the previous 1 hour, you will need to update the code and maybe the template timetable. You don’t have to worry about older reservations since they will still be displaying the previously saved 1 hour duration or endTime target.

5. Chaining Multiple Time Slots

This is another reason for storing the duration/endTime in the reservation document.

By chaining multiple time slots, we mean when a customer is reserving multiples of the unit time at once.

For example, a customer is using a hotel room for 3 days at a go. A patient wants more time with a consultant so they go for 2 sessions at once. Or an event spans 3 days and uses the same hall as the venue.

Handling this is intuitive in the booking system. The calendar should allow selecting multiple spots at once and that’s it.

Thank you!

Thank you for being part of this journey. It has been a long ride. Firebase makes life easy. Building a booking/reservation system should not be hard either.

If you plan booking/reservation systems well, you will properly execute them. And that is irrespective of the complexity. And as we’ve seen you can build them on Firebase.

We covered many use cases of booking. I hope we’ve discussed your use case (or parts of it at least).

Toast to the many systems you build.

Cheers!

How to structure any booking/reservation system with Firebase was originally published in keepdeploying on Medium, where people are continuing the conversation by highlighting and responding to this story.

About CORS

CORS (Cross-Origin Resource Sharing) is a policy that helps with user security. It is a mechanism by which the browser permits or denies access to data on a website (domain name) from another.

Let’s say you are browsing on example1.com. You want to download a picture hosted at example2.com. By default, the browser will not allow you to do so. The reason is to ensure that you don’t obtain malicious data from example2.com.

But then what about CDNs and hosting static assets on different domains? Why aren’t they blocked by CORS?

Well, all backend codes have the ability to add specific HTTP headers to an HTTP response. When they add such headers, they tell the browser: “Hey, it is safe to get data from me”.

When you enable CORS on a given backend (by adding appropriate headers on the HTTP response), the browser will permit access to data from that server. So if example2.com now has CORS enabled, example1.com can safely download the image hosted at example2.com.

Note that CORS is solely a browser problem. It doesn’t exist in the context of API tools like Postman, httpie, cURL, etc.

How to enable CORS

There are 2 ways to solve the CORS problem. We’ve seen the first one already. That is, adding headers on the response of an API call.

All CORS headers start with “Access-Control”. For example:

• Access-Control-Allow-Origin,
• Access-Control-Allow-Headers,
• Access-Control-Allow-Methods,
• etc.

As their name indicates, these response headers specify what kind of entity should be allowed in the CORS policy. For example, Access-Control-Allow-Origin tells the browser which domain names can access data.

On the backend side, you can give a specific set of domain names to Access-Control-Allow-Origin. You could also set this header to an asterisk (*). This is a wildcard. It will permit calls from all browsers at all times. The same is the case with other Access-Control headers.

What about when you don’t have access to the backend code? Or when you are just consuming an API and CORS surprises you (after all it worked in Postman)? Or you don’t even understand the process of setting HTTP response headers? What could you do?

This is where a proxy comes in. Proxy servers are the second way to solve CORS issues.

What is a proxy server?

Proxy servers are intermediaries. A proxy server is a man-in-the-middle between your browser and the CORS-disabled backend.

Proxies simply carry out the API call you are trying to make from the browser. The difference lies in the fact that the proxy server does not make this call inside the browser. As such, there are no CORS limits.

The proxy server adds the appropriate CORS headers on the response from the API call. Consequently, your browser won’t complain and at the same time, you obtain the data you wanted from the target server (or example2.com).

What are Firebase Functions?

Firebase is a serverless platform. It is a Backend-as-a-Service that permits you to quickly build and deploy various parts of your architecture. Firebase Functions are endpoints that run isolated business logic and return immediately.

An invocation (or HTTP call) to a Firebase Function is FREE (well technically). Firebase gives us two million free invocations monthly. After which we pay $0.4 for any extra million invocations.

Now 2,000,000 HTTP calls are much for a personal CORS proxy server. And even if you exceed that quota, you will still be making an invocation at $0.4 / 1,000,000 invocations. That gives you a negligible cost of $0.0000004 per invocation. So we can safely say that an invocation is free.

What’s the reason for mentioning billing and money? Well, to use Firebase Functions, you will need to set up billing with Google Cloud if you haven’t yet done so. And if it is your first time in the Google Cloud Platform (GCP), you are eligible for $300 of GCP credits for 3 months.

What we will be doing

We will create a personal proxy server with the help of Firebase Functions. Firebase Functions is a good choice because:

• Invocations are cheap.
• Each invocation always returns independently (this is serverless stuff).
• We leverage Google’s global infrastructure (high speed and scaling).

The proxy is a personal one in the sense that you can use it to bypass CORS issues when using APIs you don’t control. Members of your organization can also leverage such a technique.

Of course, make sure that the data you are accessing is safe. The essence of bypassing CORS is to get things done and not to defeat the security patterns put in place by browser specifications.

Setup a Firebase project

• Go to the Firebase Console.
• Create a new Firebase project (or choose an existing one).
• Enable billing for that project. Go to Functions and Click on “Upgrade Project”. It will take you to GCP and you enter your card. Skip this step if you already have billing setup.
• On your PC, download and install NodeJS. Skip this step if you have it installed.
• Next, install Firebase locally. Run the following command. Of course, no need if you are already a Firebaser.

npm install -g firebase-tools

• Sign in to Firebase in the terminal. Run the following command.

firebase login

• Next is to create a local project folder. Let’s name it proxy.

mkdir proxy && cd proxy

• Now initialize Firebase Functions. The following command will ask you to choose a Firebase project. Choose that you had set aside earlier. Choose JavaScript (instead of TypeScript) for a programming language. Install dependencies.

firebase init functions

Set up Cloud Functions as a proxy server

Now it is time to go about coding. We will have to write JavaScript code that will serve as the proxy server. But we need two packages from npm for our code to work.

1. We need the cors package to do the actual CORS work. It will add the appropriate CORS headers to all our responses.
2. We need the node-fetch package. It makes the API call inside Cloud Functions.

To install these packages, first, change the current directory of the terminal into the functions folder (created by Firebase in the previous step). Run the following command.

  cd functions

Then, run the following command to install the packages.

npm install cors node-fetch@2.6.1

Notice that we pinned the node-fetch to its version 2.x. The reason is that version 3.x and above are exported as ESM-only modules. When you import them with require , they won’t work. Special shout out to Olivier de Broqueville for noticing this.

Open the generated proxy project folder in your IDE. Open index.js file found in the functions folder. Delete its contents and paste the following code inside.

The above code declares a cors Cloud Function. The function first rejects any call to it that lacks a valid URL value in the request query string. It then sets up the HTTP call, makes the call, and responds in a CORS-enabled way.

That’s it about the code for a proxy server.

Now, we need to deploy the Cloud Function. Run the following command to make it go live.

firebase deploy --only functions

After a successful deployment, you can now use the cloud function as a proxy server. To use the proxy, use the following: https://us-central1-<project-id>.cloudfunctions.net/cors?url=<encoded-url>.

Where <project-id> is the unique project ID of your Firebase project and <encoded-url> is the URL that you want to bypass CORS.

Remember to append the encoded URL in the query string. You can skip encoding if there are no queries on the URL.

See the proxy in action

• Visit any website (let’s say google.com) on a new browser tab.
• Open the browser developer tools (Press Cmd/Ctrl + Shift + i).
• Click on the console tab.
• Try fetching any other website (let’s say medium.com). It should report a CORS error. For example:

await fetch('https://medium.com');

• Retry fetching but this time, prefix your proxy server’s endpoint. It should go successfully. For example:

await fetch('https://us-central1-<project-id>.cloudfunctions.net/cors?url=https%3A%2F%2Fmedium.com%0A');

Note that us-central1 is the default location of new Firebase/GCP projects. If you are not comfortable with it, or you want a data center closer to your location, you can choose a different project location at the point of creating the project. However, this project location can’t be changed once it has been set.

Also, you can encode or decode URLs at urlencoder.org.

Cheers!

So far, we’ve seen why CORS errors occur and how to build a proxy server with Firebase Cloud Functions.

The proxy server is one tool you can build with Firebase. Another tool you can build is a URL shortener. The best part? You can build your own URL shortener for FREE entirely on Firebase. Read how to do it here.

How to create a CORS proxy server with Firebase Functions was originally published in keepdeploying on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, you will understand possible the causes of poison messages in a message broker. You will also learn how to restore them in both Memphis.dev and RabbitMQ.

Table of Contents

• What is Service Oriented Architecture?
• What is a message broker?
• About Memphis.dev
• About RabbitMQ
• What are poison messages?
• How to Restore Poison Messages from Memphis
• How to Restore Poison Messages from RabbitMQ
• Summary

What is Service Oriented Architecture?

Service Oriented Architecture (SOA) involves splitting different parts of your application into services. That way you can have services for Authentication, Batch-Processing, Managing Videos, Notifications, etc.

Separating core functionalities into services help your platform to scale appropriately. You also get to enjoy the benefit of the whole system not breaking down when one service malfunctions. In addition, you can improve each service without tampering others.

Such backend features usually carry out asynchronous tasks. These asynchronous activities don’t complete at the same time. If a user is interacting on your platform, you don’t want the user to wait for long processes to complete. You want to continue interactivity. At the same time, you want a service to tell you when it is done with its job. This is where message brokers come in.

What is a message broker?

A message broker is a communication tool used within service-oriented platforms. A message broker (or message queue) is a man-in-the-middle for services in your backend.

With message brokers, some services can send messages to the broker whereas some can receive. Services that send messages are called producers. On the other hand, services that receive messages are called consumers.

A “message” in message broker stands for what the service sends. It could be an event, piece of data, a task, etc. A “message” represents what the services communicate.

As a broker, a message broker is an intermediary for messages. As a queue, a message broker permits you to stock up messages till consumers get them. Message brokers complete the scaling of Service Oriented platforms. Message brokers ensure that services appropriately communicate with each other.

Memphis.dev and RabbitMQ are example message brokers. They are both open source. Both Memphis.dev and RabbitMQ have a dashboard (or UI) to visualise and manage “messages”.

You can install both of them on any Operating System with Docker. If you don’t have Docker installed, install Docker for your Operating System here.

About Memphis.dev

Memphis.dev is a real-time data processing platform. It is an open-source, real-time data processing platform for in-app streaming use cases.

Run the following command in your terminal to install Memphis.

curl -s https://memphisdev.github.io/memphis-docker/docker-compose.yml -o docker-compose.yml && docker compose -f docker-compose.yml -p memphis up

When the command completes, open localhost:9000 in the browser, it should show you the Memphis UI. Execute the following steps to get started:

• Enter your email, full name, and set a password. Your email address is important for account recovery. Create account.
• Enter hello for both factory and station names. These are just for demo purposes. Click Next.
• Enter hello for app username. Click next.
• Click or skip through the next welcome onboarding code and steps. Then launch the dashboard.

About RabbitMQ

RabbitMQ is the most widely deployed open source message broker. With tens of thousands of users, RabbitMQ is one of the most popular open source message brokers.

Run the following command in your terminal to install RabbitMQ.

docker run -it --rm --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:3.10-management

When the command completes, open localhost:15672 in the browser, it should show you the RabbitMQ UI. Sign in with guest as both username and password. These are the default credentials when you set up RabbitMQ with Docker.

What are poison messages?

Poison messages are those messages that have not reached their destination. The message broker had received them but it found it hard to deliver them. At times, it could not deliver them because the consumer may be offline. So the broker will keep sending the messages till they finally become poison.

Another reason why poison messages could occur is because of acknowledgment. In a normal setup, when a consumer receives and uses up a message from the broker, the consumer acknowledges that message. Acknowledging a message tells the broker that that message has been received. Acknowledging is important. It is the broker’s way of ensuring proper communication across services.

Asides acknowledging, a consumer can reject a message (negative acknowledgment). When a consumer receives a message and rejects it or does not acknowledge it, the message broker will keep on retrying. It keeps retrying because it wants to ensure that the message gets across to the consumer. After all, that’s why it is a broker in the first place!

Also, there is usually a predefined number of times a broker would keep retrying messages before those messages become poison. You can also set this “number of times”. Also, you can instead configure a message broker to keep retrying but for a period of time (like 5mins, 2hours, 7days, etc.)

We call these failed messages poison because they introduce unintended effects to the system. If it was a user-initiated task, this user may never get the intended value delivered. If the value were a paid feature, such failure could cause a terrible customer experience (and loss of money). On the broker’s side, it could reduce platform fidelity. As it could seem that the message broker is not reliable for its job.

Poison messages are also called dead letters. “Dead letters” suit properly for poison messages for two reasons:

1. Messages are letters in the context of the broker’s transactions. A letter has a destination likewise a message.
2. The letters are “dead” because they did not reach their appropriate destination.

Rather than discarding failed or unacknowledged messages, message brokers keep retrying as stated above. If retry time or number of retries exceed the preset maximum, message brokers store these poison messages (or dead letters). You then need to restore these poison messages to ensure smooth running of your system. How you restore poison messages (or dead letters) depend on the message broker you are using.

How to Restore Poison Messages from Memphis

To restore poison messages in Memphis, resend the poison messages and acknowledge them.

To see this in action, let’s use NodeJS to create a simple “Hello World” usecase of Memphis. We will write code that sends and receives “Hello World” messages to and from Memphis. However, the consuming part will not acknowledge the messages. This way Memphis will keep sending till they become poison messages.

Create a new memphis-poison folder, install memphis, and run the code for the above setup. Run the following commands in your terminal to do the above.

mkdir memphis-poison 
cd memphis-poison 
npm init -y
npm install --save memphis-dev

Create a new index.js file inside the newly created memphis-poison folder. Paste the following JavaScript code inside.

const memphis = require('memphis-dev');

(async function () {
  try {
    await memphis.connect({
      host: 'localhost',
      username: 'hello',
      connectionToken: 'memphis'
    });

    const consumer = await memphis.consumer({
      stationName: 'hello',
      consumerName: 'hello_consumer1',
      consumerGroup: 'hello_consumer_group',
    });
    consumer.on('message', (message) => {
      console.log(message.getData().toString());

      // commented out the following line to produce poison messages
      message.ack();

    });
    consumer.on('error', (error) => {
      console.log(error);
    });

    const producer = await memphis.producer({
      stationName: 'hello',
      producerName: 'hello_producer1'
    });
    for (let index = 0; index < 10; index++) {
      await producer.produce({
        message: Buffer.from('Hello world')
      });
      console.log('Message sent');
    }
    console.log('All messages sent');
  } catch (ex) {
    console.log(ex);
    memphis.close();
  }
})();

The above code connects to Memphis broker. It produces 10 “Hello World” messages and consumes them. Run the file by running the following command in the terminal. Ensure you are within the memphis-poison folder inside the terminal.

node index.js

Notice that the terminal keeps receiving the “Hello World” messages. This is because the message.ack(); line is commented out. That code is supposed to acknowledge the messages but as it is commented out, the messages become poison messages.

The default Time-To-Live (TTL) for messages in Memphis is 30 seconds. So the code will keep receiving “Hello World”s for up to half a minute before it stops and becomes poison.

Check the Memphis UI dashboard to see the poison messages. It will create a Dead Letter Station (DLS) and keep the poison messages there.

To restore the poison messages, simply restore and acknowledge them.

• Select all of the poison messages and click on resend.
• Get back to the code, uncomment the message.ack(); line, and re-run the file.

This will re-produce 10 “Hello World”s, then consume them, and also restore the poison messages from the previous run. And that’s how to restore poison messages from Memphis broker.

How to Restore Poison Messages from RabbitMQ

To restore poison messages in RabbitMQ, create a Dead Letter Exchange (DLX) for those messages.

To see this in action, let’s use NodeJS to create a simple “Hello World” use case of RabbitMQ. We will write code that sends and receives “Hello World” messages to and from RabbitMQ. However, the consuming part will negatively acknowledge the messages. This way RabbitMQ will keep sending till they become poison messages.

Create a new rabbitmq-poison folder, install rabbitmq, and run the code for the above setup. Run the following commands in your terminal to do the above.

mkdir rabbitmq-poison 
cd rabbitmq-poison 
npm init -y
npm install --save amqplib

Create a new index.js file inside the newly created rabbitmq-poison folder. Paste the following JavaScript code inside.

const amqp = require('amqplib/callback_api');

amqp.connect('amqp://localhost', function (error0, connection) {
  if (error0) throw error0;

  const queue = 'hello';
  const msg = 'Hello World!';

  connection.createChannel(function (error1, channel) {
    if (error1) throw error1;

    channel.assertQueue(queue, {
      durable: false,
      messageTtl: 10000
    });

    for (let index = 0; index < 10; index++) {
      channel.sendToQueue(queue, Buffer.from(msg));
      console.log(` [*] Sent ${msg}`);
    }
    console.log('All messages sent');

    console.log(` [*] Waiting for messages in ${queue}. To exit press CTRL+C`);
    let receiveCount = 1;
    channel.consume(queue, (msg) => {
      console.log(` [${receiveCount}] Received ${msg.content}`);
      receiveCount++;

      // the following negatively acknowledges the message to make it poison
      channel.nack(msg);
    });
  });
});

The above code connects to RabbitMQ broker. It produces 10 “Hello World” messages and consumes them.

In channel.assertQueue, we’ve set the messageTtl (Messages’ Time To Live - TTL) to 10000 (10 seconds actually). We are setting this so that RabbitMQ can stop retrying after 10 seconds. RabbitMQ doesn’t set a default TTL. So we can say that RabbitMQ’s default TTL for messages is infinity. We are setting this TTL to ensure that the messages quickly become poison messages.

In channel.consume, we are keeping count of how many times the consumer received messages from RabbitMQ. The receiveCount quickly gets huge under 10 seconds and finally stops counting (the consumer stops receiving). It gets this high to tell how much RabbitMQ keeps retrying messages to ensure they get delivered.

Still in channel.consume, the channel.nack(msg); line causes the messages to be negatively acknowledged. Given that the messages have not been acknowledged and that they have a 10-second time-to-live, they become poison messages.

Run the file by running the following command in the terminal. Ensure you are within the rabbitmq-poison folder inside the terminal.

node index.js

To restore the poison messages, create a Dead Letter Exchange (DLX) for those messages. To create this DLX, you will need to setup a different channel for consuming these dead letters (or poison messages). This DLX will consume the dead letters immediately after they get negatively acknowledged.

Create a different dlx.js file within the rabbitmq-poison folder. Paste the following code inside

const amqp = require('amqplib/callback_api');

amqp.connect('amqp://localhost', function (error0, connection) {
  if (error0) throw error0;

  const queue = 'helloDlx';
  const msg = 'Hello World!';

  connection.createChannel(function (error1, channel) {
    if (error1) throw error1;

    channel.assertQueue(queue, { deadLetterExchange: 'dlx' });

    let sendCount = 1;
    const interval = setInterval(() => {
      channel.sendToQueue(queue, Buffer.from(msg));
      console.log(` [${sendCount}] Sent ${msg}`);

      if (sendCount > 10) {
        clearInterval(interval);
        console.log('All messages sent');
      } else {
        sendCount++;
      }
    }, 500);

    console.log(` [*] Waiting for messages in ${queue}. To exit press CTRL+C`);
    let receiveCount = 1;
    channel.consume(queue, (msg) => {
      console.log(` [${receiveCount}] Received ${msg.content}`);
      receiveCount++;

      // makes poison messages and send them to the dead letter exchange above
      channel.nack(msg);
    });
  });

  connection.createChannel(function (error2, channel) {
    if (error2) throw error2;

    channel.assertExchange('dlx', 'direct');

    let receiveCount = 1;
    channel.consume(queue, (msg) => {
      console.log(` [${receiveCount}] Restored Poison ${msg.content}`);
      receiveCount++;
    });
  });
});

The above code connects to RabbitMQ broker. It uses a different queue (helloDlx) from the queue in index.js (hello) to show the restoring process. The main difference between this code and the code index.js is that this code introduces the Dead Letter Exchange (DLX).

In this example, the name of the DLX is simply 'dlx'. You should use more meaningful DLX names in your codebases. DLX are backup kind of services to ensure that the poison messages get properly handled.

When creating the DLX (inside the second channel), we used channel.assertExchange('dlx', 'direct');. However, when setting the primary queue for the messages (inside the first channel), we indicated the DLX in the options parameter with channel.assertQueue(queue, { deadLetterExchange: 'dlx' });.

The above code also sends a message every 0.5 seconds till they reach 10 messages. This speed reduction is to see the restoring process in action.

Run this dlx.js file in your terminal:

node dlx.js

This consumes the dead letter messages immediately. Notice that the “Hello World” messages get restored after their first negative acknowledgment.

Summary

To restore poison messages in Memphis, simply resend and acknowledge them. To restore poison messages in RabbitMQ, setup a dead letter exchange for them.

The manner of creating poison messages in this article was mainly for demo purposes. In real life, you will encounter poison messages from unforeseen circumstances. Consuming services could get faulty and hence cause unacknowledged messages. Either way, you’ve learned how to restore poison messages from Memphis broker and RabbitMQ.

Cheers!

Helpful Resources

• Dead Letter Station (DLS) — Memphis Docs
• Dead Letter Exchanges (DLX) — RabbitMQ Docs

Introduction

Major systems have all become digital. Usage of applications keeps increasing. Scaling your apps is now implicit.

Usually, your application will consist of multiple services. These services will each be in charge of doing something different. Let’s say you’re building a chat application. You could have a messages service, a notification service, a status/stories service, a call service, an authentication service, etc.

One or more of these services have to communicate with each other. You want your app to scale properly. You’ll choose the best communication method for your platform’s services. You need a message broker.

A message broker is an intelligent middleman for your application’s services. A message broker receives “messages” from one or more services. It then delivers these “messages” to other services that want to consume them. This way, your platform scales and meets your users’ demands.

A message broker is made up of 3 parts. A queue, producers, and consumers. The queue is the manager of messages. The producers send messages to the queue while the consumers receive them.

What is Memphis Broker?

Memphis is a modern, powerful, and open-source message broker. Memphis takes away the excess work for data engineers and developers. Memphis broker gives you good developer experience. It reduces your development time by 90%.

Memphis is unique. It comes with a UI and a CLI. You can use the UI to visualize the movements of data. You can use the CLI to run important commands on the broker. There is also the sandbox at sandbox.memphis.dev for interacting to see what it looks like without installing it.

Memphis is available for Go, Java, NodeJS, and Python. More platforms will be supported soon. In Memphis, a queue is called a station. And many stations can be found in a factory. When you start using Memphis for the first time, you will at least need to create a factory and a station inside that factory.

How to set up Memphis broker using Docker

Docker is a popular tool for executing and managing software. It provides containers for software execution. It guarantees that a container will have the required dependencies for a given program to run.

You can use Docker to install Memphis. The advantage of using Docker is that you are assured that Memphis will work properly everywhere. Memphis will be the same in your local development and when your app is in production.

To install Memphis, you need to have Docker installed. If you don’t have Docker installed, install Docker for your Operating System here. Start Docker and ensure it’s running.

Run the following command in your terminal to install Memphis. It’ll fetch the Docker compose file for Memphis set up and set up Memphis appropriately.

curl -s https://memphisdev.github.io/memphis-docker/docker-compose.yml -o docker-compose.yml && docker compose -f docker-compose.yml -p memphis up

If the command completes successfully, Memphis should be up and running in Docker. If you encounter any issues, consider checking your internet connection.

This is a one-time installation of Memphis. In consequent times, when you need to use Memphis, simply launch Docker Desktop and ensure that the Memphis containers are running.

Carry out the following instructions to complete the Memphis setup in the UI:

• Open localhost:9000 in the browser, it should show you the Memphis UI.
• Sign in with root and memphis. These are the default credentials of the “root” user when you set up Memphis with Docker.
• Enter chat as the factory name. Enter chat as the station name. Click “Next”.
• Enter chat as the application user name. Click “Create app user”. It should show you “memphis” as the connection token (password). This is the default.
• Skip through the next steps and access the dashboard.

Note: You can use a different factory, station, and username instead of chat above. We are using chat to keep things simple. Use names that are meaningful to your project. The Memphis UI permits you to manage factories, stations, and users. You can create more users with varying passwords/tokens. This ensures security.

What we will be building

Many applications now need to have a real-time ability. Real-time event-driven architectures use message brokers for many-to-many inter-service communication. Examples of real-time apps include online games, admin dashboards, chat apps, etc.

Let’s build a simple chat app. Because it is a simple app, it will have only two services for now. One for all messages and the other for sending messages. The app should have more services but these two are enough to show how to use Memphis.

Let’s call this chat app FastChat. In this article, you’ll learn how to build FastChat using Memphis broker and NestJS. To keep things simple, FastChat won’t save chat messages to any database. It’ll keep them in memory while the application is alive. FastChat mainly focuses on showing you how to use Memphis broker.

The final codebase for FastChat is here on GitHub.

What is NestJS?

NestJS is an open-source JavaScript framework for server-side applications. It leverages TypeScript’s features to build robust apps. You can structure your Nest project around controllers, modules, and services to properly modularize the code.

FastChat has two services: AllMessages and SendMessage service. These two services will intercommunicate using Memphis broker. We will group them into a Nest module (ChatMessagesModule) because they relate to the same entity.

FastChat also has a BrokerModule. This module will configure Memphis broker. It’ll import the MemphisModule and connect the Nest app to Memphis. The BrokerModule will also expose a BrokerService through which other parts of the application can access Memphis.

How to set up NestJS

To install NestJS, you need to have NodeJS installed. If you don’t have NodeJS installed, download and install it from here.

To install NestJS, open a new terminal instance and run the following command:

npm install -g @nestjs/cli

Now create a new NestJS project. We will use fast-chat for the project name. Run the following command:

nest new fast-chat -p npm

The -p flag is use npm as package manager. Open the newly created fast-chat project in your favorite code editor.

How to set up the ConfigModule in NestJS

Next, we have to set up Memphis broker inside NestJS. But during the setup, we have to connect NestJS to Memphis broker. For such connection, we need at least three properties:

• host: The domain name or IP address where Memphis is found, e.g. localhost
• username: The user that NestJS will act on their behalf, e.g. root
• connectionToken: The password (token actually) of the above user.

The above three are sensitive information. For security purposes, they shouldn’t be added to source control. Rather, we need to access them through environment variables.

NestJS provides a ConfigModule for providing environment variables. It uses dotenv internally. Create a file with .env as name directly inside the fast-chat project folder. Paste the following inside:

MEMPHIS_HOST=localhost
MEMPHIS_USERNAME=chat
MEMPHIS_TOKEN=memphis

These are the default credentials. You should use more secure credentials in production. That is the very reason of use the ConfigModule in the first place.

Add the NestJS’ ConfigModule to the fast-chat project. Run the following command to install it.

npm install --save @nestjs/config

Import the ConfigModule in AppModule. NestJS auto-created the src/app.module.ts file among other files when we created the project. This file contains the declaration of AppModule. Replace the contents of AppModule with the following:

import { Module } from '@nestjs/common';
import { ConfigModule } from '@nestjs/config';
import { AppController } from './app.controller';
import { AppService } from './app.service';

@Module({
  imports: [ConfigModule.forRoot({ isGlobal: true })],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

Here, we are importing the ConfigModule and setting the isGlobal to true. Doing this will auto-import the ConfigModule in all other modules we will create (which is what we want). In consequent files that need any values from the .env file, you will only access them from ConfigService (coming later on).

How to setup Memphis broker in NestJS Run the following command to install Memphis in FastChat:

npm install --save memphis-dev

Generate the BrokerModule (to set up Memphis) with the following command:

nest generate module broker

This will create a new broker.module.ts file inside a new broker folder. Delete the contents of this new broker.module.ts file and paste the following:

import { Module } from '@nestjs/common';
import { MemphisModule } from 'memphis-dev/nest';

@Module({
  imports: [MemphisModule.register()],
  exports: [BrokerService],
})
export class BrokerModule {}

The above imports and registers the MemphisModule. It also exports a BrokerService (which we will create right away. This BrokerService connects the app to Memphis (when NestJS starts up). This BrokerService is what other parts of the Nest app will use to interact with Memphis.

Run the following command to create the BrokerService:

nest generate service broker

This will create a new broker.service.ts file inside the broker folder. Delete its contents and paste the following:

import { Injectable, OnModuleInit } from '@nestjs/common';
import { ConfigService } from '@nestjs/config';
import { MemphisService } from 'memphis-dev/nest';

@Injectable()
export class BrokerService implements OnModuleInit {
  consumer;
  producer;

  constructor(
    private configService: ConfigService,
    private memphisService: MemphisService,
  ) {}

  async onModuleInit(): Promise<void> {
    try {
      await this.memphisService.connect({
        host: this.configService.get<string>('MEMPHIS_HOST'),
        username: this.configService.get<string>('MEMPHIS_USERNAME'),
        connectionToken: this.configService.get<string>('MEMPHIS_TOKEN'),
      });
      this.consumer = await this.memphisService.consumer({
        stationName: 'chat',
        consumerName: 'chatConsumer',
        consumerGroup: 'chatConsumers',
      });
      this.producer = await this.memphisService.producer({
        stationName: 'chat',
        producerName: 'chatProducer',
      });
    } catch (error) {
      console.error(error);
      this.memphisService.close();
    }
  }
}

The BrokerService imports the ConfigService and the MemphisService. NestJS injects these services using its automatic dependency injection.

The BrokerService implements the OnModuleInit lifecycle method. This is the right place to connect Memphis broker. It is the right place because NestJS calls this method when initializing dependencies. Notice that it connects to Memphis using environment variables from the ConfigService.

The BrokerService also exposes references to the producer and consumer entities of Memphis broker. Other services will use these references to produce or consume “messages” (or events).

Note: Use meaningful consumer and producer names. Use meaningful names that can distinguish which project a particular producer is producing from or from which is a consumer consuming.

Now we’ve successfully set up Memphis broker. We now need to create the ChatMessages services and link them with Memphis.

But Before we head over to creating services let’s review another useful tool. Servers usually expose REST APIs that clients will call. However, there are alternative methods for server-to-client communication. One of such methods is gRPC.

What is gRPC?

RPC means Remote Procedure Call. It means calling a function that is located remotely (in the server).

gRPC is an open-source RPC framework for client-server communication. gRPC exposes server functions or microservices to clients. The clients too use gRPC to access data from the server(s). gRPC is available for all programming languages.

gRPC is faster than REST APIs. It is faster because it uses Protocol Buffers to exchange data (rather than JSON or XML). Protocol Buffers (ProtoBuf) is a neutral way of expressing structured data. ProtoBuf is easy to understand.

FastChat uses gRPC because gRPC is the go-to way for client-server communication in a Service Oriented Architecture (SOA).

How to set up gRPC in NestJS

To set up gRPC, run the following command while inside the fast-chat directory:

npm i --save @grpc/grpc-js @grpc/proto-loader @nestjs/microservices

It adds necessary dependencies for using gRPC in NestJS. Next, create the protobuf (.proto) file for the services in FastChat.

Create a new folder in the src folder, name this new folder chat-message. Create a new file inside this new folder. Name the new file chat-message.proto. Paste the following into this src/chat-message/chat-message.proto

syntax = "proto3";

package ChatMessage;

message Empty { }

message ChatMessage {
  string author = 1;
  string text = 2;
  int64 time = 3;
}

service SendMessageService {
  rpc send (ChatMessage) returns (Empty) {}
}

service AllMessagesService {
  rpc all (Empty) returns (stream ChatMessage) {}
}

This is what protobuf looks like. It is language agnostic. The first line is mandatory and it tells the version of protobuf in use. In this case, "proto3", (the latest version).

message in protobuf refers to a custom type we create. ChatMessage contains an author (a string), the message’s text (string) and when the time the message was sent. int64 is a safe way of representing time as a timestamp.

This protobuf file is not a TypeScript file. By default, NestJS includes all TypeScript files when building the server. If a given NestJS project needs to monitor or include non-TypeScript files into the building process, Nest has to be aware of those files.

The src/chat-message/chat-message.proto above file is an example. To tell Nest about it, add it to the nest-cli.json file. This file is directly inside the fast-chat project folder. Include the following in the JSON file:

  "compilerOptions": {
    "assets": ["**/*.proto"],
    "watchAssets": true
  }

One more config step for gRPC involves adding gRPC as a microservice into NestJS. Delete the contents of src/main.ts file and paste the following:

import { NestFactory } from '@nestjs/core';
import { MicroserviceOptions, Transport } from '@nestjs/microservices';
import { join } from 'path';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.connectMicroservice<MicroserviceOptions>({
    transport: Transport.GRPC,
    options: {
      package: 'ChatMessage',
      protoPath: join(__dirname, 'chat-message/chat-message.proto'),
    },
  });
  await app.startAllMicroservices();
  await app.listen(3000);
  console.log(`Application is running on: ${await app.getUrl()}`);
}
bootstrap();

How to create a service with NestJS

Now that gRPC is properly set up, let’s implement our AllMessages and SendMessage services. These services will interact with the ChatMessage type or interface. We need an equivalent of these type in TypeScript (separate from what we declared in protobuf).

Create a new chat-message.interface.ts file inside the chat-message folder. Paste the following inside.

export interface ChatMessage {
  author: string;
  text: string;
  time: number;
}

Next, create a ChatMessagesModule that will contain the AllMessages and SendMessage services. Run the following command to create the module.

nest generate module chat-message

This will create a new chat-message.module.ts file inside the chat-message folder. Given that we will use Memphis broker in the services, import the BrokerModule into this newly generated ChatMessageModule. Delete the contents of the chat-message.module.ts file and paste the following:

import { Module } from '@nestjs/common';
import { BrokerModule } from 'src/broker/broker.module';

@Module({
  imports: [BrokerModule]
})
export class ChatMessageModule {}

gRPC requires that NestJS code implments the methods and services defined in the protobuf file. To implement these services, we will use a controller. A controller in NestJS holds logic for API endpoints. But given that FastChat uses gRPC, the controller will rather hold gRPC functions and services.

Create a new ChatMessageController. Run the following command:

nest generate controller chat-message

It will create a new chat-message.controller.ts file inside the chat-message folder. Replace the contents of this file with the following:

import { Controller } from '@nestjs/common';
import { GrpcMethod } from '@nestjs/microservices';
import { Observable, ReplaySubject } from 'rxjs';
import { BrokerService } from 'src/broker/broker.service';
import { ChatMessage } from './chat-message.interface';

@Controller('chat-message')
export class ChatMessageController {
  private readonly chatMessages$ = new ReplaySubject<ChatMessage>();

  constructor(private brokerService: BrokerService) {}

  onModuleInit(): void {
    this.brokerService.consumer.on('message', (message) => {
      this.chatMessages$.next(
        JSON.parse(message.getData().toString()) as ChatMessage
      );
      message.ack();
    });
  }

  @GrpcMethod('AllMessagesService', 'all')
  all(): Observable<ChatMessage> {
    return this.chatMessages$.asObservable();
  }

  @GrpcMethod('SendMessageService', 'send')
  async send(chatMessage: ChatMessage): Promise<void> {
    await this.brokerService.producer.produce({
      message: Buffer.from(JSON.stringify(chatMessage))
    });
  }
}

ChatMessageController declares a chatMessages$ ReplaySubject. This is an entity that we can push values to and listen to values from.

ChatMessageController obtains the BrokerService via dependency injection. In the OnModuleInit lifecycle hook, we consume “messages” from the BrokerService’s consumer, and emit them to chatMessages$ ReplaySubject. message.ack(); tells Memphis that the “message” is acknowledged (so that it won’t send that “message” again).

ChatMessageController also implements the two communicating services of this real-time app. SendMessageService takes a ChatMessage and produces it to the BrokerService. In turn, AllMessagesService provides as chatMessages$ ReplaySubject as an Observable.

Production and Consumption of broker messages can only be done with strings. This is why we convert ChatMessages to and fro strings when sending and receiving them from the BrokerService’s producer and consumer.

At this point, we’ve successfully setup a simple real-time app with NestJS and Memphis broker.

[Optional]: Test the Real-time chat app with gRPC client

With the way gRPC works, you technically don’t make REST API requests. You have to access your backend services from another gRPC SDK (client or server).

We can test the above chat services. One way is to create another gRPC client inside the NestJS project folder. This client will make calls to the services. In turn, you can observe their action in the Memphis Broker UI.

Update the AppModule to import the gRPC ClientsModule. Replace the contents of src/app.module.ts with the following:

import { Module } from '@nestjs/common';
import { ConfigModule } from '@nestjs/config';
import { ClientsModule, Transport } from '@nestjs/microservices';
import { join } from 'path';
import { AppController } from './app.controller';
import { AppService } from './app.service';
import { BrokerModule } from './broker/broker.module';
import { ChatMessageModule } from './chat-message/chat-message.module';

@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),
    BrokerModule,
    ChatMessageModule,
    ClientsModule.register([
      {
        name: 'CHAT_MESSAGE',
        transport: Transport.GRPC,
        options: {
          package: 'ChatMessage',
          protoPath: join(__dirname, 'chat-message/chat-message.proto')
        }
      }
    ]),
  ],
  controllers: [AppController],
  providers: [AppService]
})
export class AppModule {}

Generate a new ClientController that will call the gRPC methods. Run the following command in the terminal:

nest generate controller client

This will create a new client.controller.ts inside a new client folder. Replace the contents of this new file with the following:

import {
  Body,
  Controller,
  Inject,
  OnModuleInit,
  Post,
  Res
} from '@nestjs/common';
import { ClientGrpc } from '@nestjs/microservices';
import { Response } from 'express';
import { firstValueFrom, Observable } from 'rxjs';
import { ChatMessage } from '../chat-message/chat-message.interface';

interface AllMessagesService {
  all(): Observable<ChatMessage>;
}

interface SendMessageService {
  send(chatMessage: ChatMessage): Observable<void>;
}

@Controller('client')
export class ClientController implements OnModuleInit {
  private allMessagesService: AllMessagesService;
  private sendMessageService: SendMessageService;

  constructor(@Inject('CHAT_MESSAGE') private readonly client: ClientGrpc) {}

  onModuleInit(): void {
    this.allMessagesService =
      this.client.getService<AllMessagesService>('AllMessagesService');
    this.sendMessageService =
      this.client.getService<SendMessageService>('SendMessageService');

    this.allMessagesService.all().subscribe((chatMessage: ChatMessage) => {
      console.log(chatMessage);
    });
  }

  @Post('')
  async sendMessage(
    @Body() chatMessage: ChatMessage,
    @Res() res: Response
  ): Promise<void> {
    await firstValueFrom(this.sendMessageService.send(chatMessage));
    res.json({ status: true, message: 'Acknowledged' });
  }
}

This ClientController subscribes to the all method of the AllMessagesService and prints every ChatMessage to the console. It also exposes a /client POST endpoint to receive messages and send them to Memphis broker (through the send method of SendMessageService).

Run nest start to start the NestJS application.

Use any API tester (cURL, Postman, ThunderClient extension on VS Code, etc.) to send a post request to localhost:3000/client. The body of the post request should reflect a valid ChatMessage like:

{
  "author": "UserA",
  "text": "Test Chat Message",
  "time": 1661096069756
}

You should receive an acknowledgement feedback. Check the Memphis UI at localhost:9000, you should notice the sent message (event). Check the NestJS logs and notice that it printed your ChatMessage. Send more POST requests and notice more messages and logs.

The final codebase for FastChat is here on GitHub.

Why did we use Memphis broker?

In a message broker (like Memphis), messages are like events. They are what services use to communicate.

FastChat above is a simple usecase of a message broker. You might not see the essence of producing and consuming messages if this is the only thing you want to build. Besides we placed the two services in the same .proto file. We also implemented both services with the same controller. These were because of simplicity.

In a big project, you will separate your services. They might be in different NestJS projects and deployed from different servers. Yet, they will be communicating via Memphis broker. If you were building a chat infrastructure, other services like notifications, authentication, security, etc. are reasons why you should use Memphis broker.

You will use a Memphis broker because it ensures many-to-many (N:N) communication across your application’s services. It also ensures that every service receives the events or “messages”.

Summary

Memphis broker stands out in its speed and ease-of-use among other message brokers. You can install it with Docker. It has a UI and CLI through which you can manage your projects. You can also manage factories, stations, and users with Memphis broker.

The above FastChat is a simple real-time app to get you started with Memphis broker in NestJS. In summary, to build a real-time app with NestJS and Memphis broker:

• Connect to Memphis broker using the MemphisService and the connection parameters.
• Then produce and consume messages as you need in your application.

Happy Coding!

However, you can decide to create a URL shortener for personal or organizational branding purposes, so only you or your organization can shorten links with that shortener. Some organizations have URL shorteners for themselves: Google has g.co, LinkedIn has lnkd.in and Telegram has t.me.

Your reason for building a URL shortener will reflect how you structure the shortener’s front end. That is whether the public can access an interface where they can edit URLs or only you or permitted members in your organization can have such access.

Whatever your reason would be, the logic and backend for URL shortening are the same. The flow is simple:

1. Capture the link after the short domain name.
2. Look up the long URL.
3. If there has been a valid stored long URL, redirect to this long URL.
4. Else, if there is no long URL set for a given short link, respond with 404.

On Domain Names

Domain names are human-readable website names. They are the “whatever dot com” you type in a browser to visit a particular website. For example: medium.com, telegram.org and flutter.dev.

As implied in the act of URL shortening, you need a short domain name to build a URL shortener. It needs to be short to fulfill the demand of the URLs being shorter than their longer equivalents.

You can buy domain names at various domain registrars. Namecheap is one of them. I got obum.me from there. Namecheap also gives free Domain privacy for life.

Architecture

To build a URL shortener, you first need web hosting. The short domain name will be tied to this hosting. As such, if people click on any shortened link (or open such a link in a browser), their request can be handled in some way.

Secondly, you need a database to store shortened links and their long URL. And finally, you need a backend engine to redirect the users to the long URL (if one was stored in the database) or 404.

Firebase

Firebase is a Backend-as-a-Service that helps you build, improve, and grow applications. It provides you with tools that individually or together make your app robust.

Firebase is a platform that comes with many services like Analytics, Authentication, Realtime Database, Hosting, Cloud Messaging, etc. Firebase has the 3 parts of backend that we need for a URL shortener: Cloud Firestore, Cloud Functions, and Firebase Hosting.

Cloud Firestore

Cloud Firestore is a NoSQL database from Firebase. It allows you to create, update, store, and delete data as you want. With Cloud Firestore, you are in charge of data access and structure.

You will first need a Firebase project. Create one at console.firebase.google.com. You can choose an existing project if you wish.

Create a Firestore Database in the project here (Select Cloud Firestore from the left sidebar). Create the database in production mode.

Cloud Functions

Firebase is a serverless platform. It provides you with “one-time” callable backend endpoints (Cloud Functions). A given cloud function just runs the logic it is supposed to and ends.

You can configure a cloud function to handle http requests. That way the function will take care of the backend engine for the URL shortener. It will check the request endpoint, look up the database, and redirect as appropriate.

A note on Billing

You need to write code for the functions, but before that, you have to set up billing. Please don’t fret. This article’s title says “free” and it is not a lie.

Firebase is linked to the Google Cloud Platform. It is a cloud platform and like all of them, they have some pay-as-you-go features.

With Cloud Functions, you have 2 million free invocations per month. In other words, you would have had more than 2 million requests on that URL shortener Firebase project before Firebase will charge you.

And if you exceed (firstly, congrats on that, your marketing is optimum), you will be charged as little as $0.4 for any extra million invocations. This is cheap. In reality, before you get to this point, you should have monetized well enough to cover that cost.

For the record, for the 2 years (and counting) that I have been using Firebase, I have never received any bill. Besides, you can add a $1 alert/budget to receive emails if any resource usage wants to increase.

Setup Billing

To set up billing, Go to the functions page in your project and click on “Upgrade project”. Add your card or link with a Google Cloud Platform billing account and you are done. You can also add the warning alert/budget at this stage.

Setup Cloud Functions

Configure cloud functions code with the following steps:

1. NodeJS and Firebase
   a. Download and Install NodeJS from here if you don’t have it installed.
   b. Run the following command in a terminal instance to install Firebase locally.

npm install -g firebase-tools

c. Sign in with your Google Account. Run the following command to log in. It will take you to the browser.

firebase login

2. Setup functions code

a. Create a new folder for the project and change focus to it in the terminal. Run the following command.

mkdir url-shortener && cd url-shortener

b. Run the following command in a terminal instance to initialize functions. The prompt will guide you through a series of intuitive questions. However, preferably choose JavaScript and also install dependencies.

firebase init functions

c. Open the newly created url-shortener project in your preferred editor. Paste the following JavaScript code into the newly created index.jsfile found in the functions folder.

In addition to checking the database and redirecting as appropriate, the code saves every request to the database (you can use this for analytics purposes in the future). The code also keeps counts of requests and created and deleted links. This is the preferred way to keep counters in NoSQL databases because if the app grows big, getting the total count by fetching all documents and summing is rather expensive.

Change the example.com domain for the home route (“/”) to your domain of choice. If you have none, remove that line entirely.

3. Deploy

Run the following command to deploy the cloud functions code. It will do different things, and if all is well, it will successfully deploy the functions.

firebase deploy --only functions

A note on Counting and Logging

The third Firebase component of our URL shortener is hosting. But before proceeding to Firebase Hosting, let’s look at two improvements that can be done with the counter and with logging in the Cloud Functions code above.

With regards to the counter, the code tracks created and deleted links. This was the former way to do things. Besides, counting is implemented as two individual cloud functions. Their invocations add to the Firebase billing or charge.

The new and better way to know the count of Firestore documents is simply the COUNT function. It is available on the server-side for all collections and queries. So, instead of keeping a separate collection for counters as in the code above, you can just call collection.count() where ever you need the total number of documents in a collection.

As concerns logging, you can use Cloud Logging to log all the requests. It logs request and request metadata better than the code above. It also allows you to quickly check the amount of requests logged at high scale levels.

Firebase Hosting

Firebase Hosting offers free static-files hosting for up to 10GB. In this URL shortener, you will really never use any of that space. Everything is handled by Cloud Functions. Configure Firebase Hosting with the following steps.

1. Create a new empty folder inside your url-shortener project folder. Name this new folder public.

2. Paste the following setup code into the firebase.json file that was created by Firebase when you set up Cloud Functions. It tells Firebase to send all requests to the hosting to the app cloud function that you had deployed.

3. Deploy

Run the following command to deploy and set up hosting. It will do different things, and if all is well, it will successfully deploy to some custom link. (<your-project-id>.web.app)

firebase deploy --only hosting

4. Domain Name

Go to the hosting dashboard (while on a wide screen). You will see the “Add custom domain” button, click it and follow the flow to set up the short domain for the URL shortener you bought.

If you didn’t buy a domain, your shortened URL will be longer, but the URL shortener will still work.

Congratulations!

You have successfully set up a URL shortener with Firebase. To test this, go to Cloud Firestore and add a link. Create a links collection. Leave the id to be auto-generated. Add a short key with value as the shortened part of the URL (after the slash). Then add a second long key with value as the long link to where the user will be redirected to. Save.

If you visit <your-short-domain>/short or <your-project-id>.web.app/short, your browser should auto redirect you to the value of long.

If things don’t go right, drop a comment and we will solve it.

Frontend

Firebase is a backend service and this article was focused on the backend. Like I said at the beginning of the article, the front-end of the URL shortener greatly depends on whether the URL shortener is open to the public or not.

In fact, if opened to the public, you would have more work to do. You will have to set up Firebase Authentication and link it with the frontend. In addition, links will have to have an extra ownerId to ensure that only their creators can edit them. You will also have to edit Firestore Security Rules to ensure security.

In my case, I built a URL shortener with obum.me. I use it to share links to my articles or profiles. The front-end is some rather private admin dashboard that I built with Angular Material.

Keep Deploying

URL shorteners are helpful in many ways. We need them in copies, flyers, social media, etc. to share links in a rather attractive way. You can use existing URL shortener platforms, however, they could have a paid tier with the features you need.

Building your own URL shortener gives you full control. You can edit the short and long parts of a given URL at any time. Firebase gives you the ability to create a URL shortener with its backend services all for free as we have seen.

Cheers to the many URL shorteners you will build and deploy!

How to build a URL shortener for free with Firebase was originally published in Firebase Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Though called “serverless" (without server), serverless doesn’t mean that there are technically no servers. However, in such backend systems, no engine needs to always listen to requests as it’s common with monolithic systems. It feels like there is no server and hence serverless.

Serverless is a type of Microservices architecture where backend routes are run/executed only when needed. Serverless involves the browser doing the majority of the website’s workload.

The frontend is usually coded with heavy JavaScript so the browser executes new data/UI (User Interface) rendering and router management without the backend. Such websites are commonly called Single Page Applications (SPAs). They could be made with plain/vanilla JavaScript or with JavaScript frontend frameworks like React, Angular, Vue, …

Serverless is Fast

The frontend app in serverless architecture uses modern browser APIs to cause changes in the browser’s routing without reloading the web page. The idea of not reloading the web page is an admirable innovation. When a page is reloaded, the browser will need to re-download a set of similar HTML, CSS, and JavaScript files it had previously downloaded, to re-render the very page. This takes a great deal of time, especially if the user has a poor internet connection.

So instead of wasting such network request times, the frontend JavaScript can make calls to serverless APIs and update the DOM (Document Object Model) and frontend UI with needed data in the background. The frontend app could have some loading animations to keep the user waiting when the user initiates an interaction that will require backend data (like submitting a form, loading user profile, updating crucial information, …). Consequently, the user spends less time browsing and will have an overall better user experience.

Also, the backend transfers a lower amount of bytes when the frontend needs it — lower in that HTML and CSS are not re-downloaded, making the browsing a lot faster.

Browsers are faster in executing JavaScript already present in the user’s device than in sending requests to servers, waiting for the servers to construct the needed files (based on the requested route), downloading the response files, and re-rendering the entire UI.

Static Hosting

In entirely standalone/full-blown backend systems, where the backend engine does more work, the server needs to be listening at all times on some particular port to send responses back to requests. The backend is usually never idle because it’s in charge of every bridle and bit of the website.

In serverless architectures, the frontend is built as some set of static files for the UI. A separate hosting is available for these static files and all assets (like icons and images) necessary for the frontend. GitHub Pages, Firebase Hosting, Vercel, Netlify, Cloudflare Pages … offer such static site hosting.

Such hosting is usually free or may come at negligible cost. Reasons being: first, it responds with files that don’t change (static files) and it leverages CDNs (Content Delivery Networks). Secondly, it has no complex backend engine like Java, Python, NodeJS, PHP, … to keep listening for routes.

These files could be hardcoded HTML, CSS, and JavaScript files, or the build files of Frontend JavaScript frameworks. Note that the word static doesn’t mean that the website doesn’t have dynamic features. Static here is used relative to monolithic systems that build the HTML and CSS files in real-time when requested in contrast to already having the files statically available.

Functions

Everything that is sent to the Frontend is public and as such, important and private processes should not be exposed to frontend JavaScript. Backend business logic can be run by one-time callable API routes or functions, that process requests and return data when needed. Firebase Cloud Functions, AWS Lambda, Azure Functions, Vercel Functions, Netlify Functions, … offer such serverless deployment. These services are usually free or may cost a penny.

Serverless architecture is a combination of functions code and static hosting. The hosting provides the browser with everything UI needed for rendering while the functions provide the API or the data that should come from business logic, and be hidden from public consumption.

Serverless is cheap

The cost of running both deployments (hosting and functions) is negligible, both at small and large-scale deployments. After all, the services involved are free and if they will have some cost, it will be a little charge. So yes, serverless is cheap.

When compared to the cost of running monolithic backend engines, serverless is cheap and cost-effective. You need to make Virtual Machines (VMs) always available to effectively run such centralized architecture. Cloud Providers charge per hour or minute usage for VMs to be alive. And as these VMs need to be alive and the charge keeps going high and high. This is financially demanding and when compared to the serverless backend solution, serverless wins.

Automatic Deployments

Continuous Deployment/Integration (CI/CD) is smooth with serverless. Most platforms that provide these static hosting and cloud/serverless functions tend to offer some automated deployment method, usually from online hosted version control systems like GitHub, GitLab, BitBucket, … So you technically will always have your site auto-updated as you develop it and your site would rarely need maintenance outbreaks.

Scaling is assured

Cloud Providers and Tech companies that offer deployment services, for both monolithic and serverless architecture always assure scaling. Given their wide range of data centers and internet availability, these companies generally are cool with being servers to immense global traffic. But then in the technology being served, there might be a scaling problem.

In themselves, static files and functions will always scale. They will always be capable of serving large bandwidth and many requests because they respond once and that’s all. There is still space for more requests or API calls because on average, the static files host and functions processor tends to be more available, given that they serve files and data once per time and stop there.

This may not always be the case for the monolithic architecture counterpart. As the engine is always running, many variables are kept at runtime. At times, the programming language involved may also induce considerable overhead on the VM’s CPU. The software can crash within itself causing server errors with 500 status codes even on page load. And all this because of the voluminous traffic of requests coming to your website.

What could be worse? Maybe your cloud subscription may have a fixed number of CPUs/memory (which might not be enough for your monolithic deployment), or you did not opt-in for the available auto-scaling features.

Of course, AWS Elastic Beanstalk, Google App Engine, Azure App Services, … that provide these dynamic backends are optimized for them. But then the scaling options of serverless outweigh those of its counterpart.

Same backend for mobile and web

In the past, developers made separate backend routes for websites and mobile apps. This is because, the API for the websites usually returned HTML, containing frontend UI and data, while the API for the mobile apps returned XML, containing only data. This was inefficient as updates to the backend had to be done in two places.

The advent of serverless helped this matter. The web frontend app takes care of its UI without depending on the backend engine. As the cloud/serverless functions return only necessary app data, mobile apps can now call the cloud/serverless functions just as the web frontend does. So we end up with the same backend for both mobile apps and websites.

The returned data tends to be in JSON form or Map types. Nowadays, both web frontend and mobile apps can understand JSON. JSON is lighter and more readable than XML.

Security

Serverless is secure. You will tend to use HTTPS to send user authentication-related requests. The static website hosting is not an open backend engine that can take file uploads nor have a vulnerable SQL database. As such, there is no danger of shell files nor SQL injections. Even if shells get uploaded, they technically can’t be executed as static hosts just don’t permit any such executions. Your files will always be available just as you deployed them.

Separation of Concerns

You can separate authentication, database, file storage, advertisements, and other backend services across various functions. This enables you to update or make changes to a particular service without updating the entire website. Also, if any of these backend services or cloud/serverless functions break, has a vulnerability, or is maliciously attacked, it is not your entire product deployment that will be in the mud.

Server-Side Rendering (SSR) is available

The name seems to contradict what we’ve been saying but the details will explain. Search Engines like Google index websites out there and return them ranked in order of quality when users search. The process of improving the website’s contents to ensure it ranks high in search results is known as Search Engine Optimization (SEO).

Behind the scenes, search engines have robots that crawl the internet and save all that data. They can read HTML file contents and understand website content. These bots, however, don’t execute JavaScript. Static websites built with plain JavaScript and dynamic websites collaborate with SEO properly. The bots can read them.

But then, static websites built from JavaScript frameworks need browser execution of JavaScript to display data. As the bots don’t execute JavaScript, they don’t find any website information on those websites built with JavaScript frameworks. This could cause a problem since SEO is important for businesses and for the discoverability of websites and blogs.

This is where Server-Side Rendering comes in. It's a feature from JavaScript frameworks that provides the executed build but this time as partial HTML with default data. This pre-rendered HTML can be hosted in cloud/serverless functions. As such when the bots try to visit the website, they first see this data instead and hence saving the day.

But in the browser, the browser first renders the pre-compiled HTML. Then it will gradually complete the loading of the UI asynchronously in the background, just as the framework instructs. Angular SSR, React DOM Server, Vue SSR, are examples of Server-Side Rendering.

… not always serverless though

Having understood serverless and its advantages, it is worth noting that serverless doesn’t work everywhere. Some products just can’t permit serverless architecture like controlling subdomains from the same backend engine or within-company sites not available to the internet.

Also, static hosting is not a good fit for a website where the majority of its content and UI will frequently be updated. This is because there will be a need to update the frontend and redeploy every time such updates are made. Furthermore, building a CMS (Content Management System) like WordPress with monolithic backends, like PHP, is better and easier than with static hosting.

Of course, we don’t expect the serverless type of microservices architecture to be a one-fits-all backend, but we are sure that the architecture fits its purpose well when used.

Keep Deploying

Serverless is one of the ways you can deploy applications. You build awesome apps and you should make them live. To the showcasing of your abilities, keep deploying what you’ve built.

Understanding Serverless Microservices Backend Architecture was originally published in keepdeploying on Medium, where people are continuing the conversation by highlighting and responding to this story.

Precious Ngwube, a member of our core team, came up with the idea of a 4-week Javascript series. On planning in a core team meeting, we sought out to 6 weeks instead. The first four weeks were for learning, while the last two were for community building.

Emmanuel Chukwuemeka (Officialemeka) was the lead for design in our GDSC. He suggested the addition of UI/UX design as a learning track to the program. We then named the event: DES & DEV Bootcamp (… DESign and DEVeloper).

At that time, I doubled as both GDSC lead and Genesys Campus Club lead in AE-FUNAI. As a result, I organized the series in honor of these two brands (GDSC and Genesys). Hence, promotions of the event included logos of both GDSC and Genesys.

Planning

We had meetups every Saturday during the six weeks of the Bootcamp. The first four weeks entailed intensive learning. During this time, participants completed small projects individually. They submitted their projects by each meetup. In the last two weeks, participants built projects in teams, which they showcased on the demo day.

Planning and promotions took us three weeks, making the Bootcamp start by the third Saturday of April. We first chose Convocation Arena as the event venue. Victor Amaechi, Ephraim Leo, and I designed the flyers we used for promotions across the Bootcamp. Jennifer Mbuton, Emere Michael, and Victor alternated the job of moderator during each Saturday.

Michael and Victor took care of promoting the Bootcamp. They broadcasted the event online and offline. All promotions included a central call-to-action: the event registration form at https://bit.ly/desdev21 (it’s, of course, closed by now). I stopped the form from collecting responses by the third week of learning. We recorded 252 responses at this closure. Unarguably, Michael and Victor’s efforts reaped great fruits.

Officialemeka was in charge of the design track. He curated content and defined deliverables of participants in design. Specifically, he created an notion.so board to guide the learning of design participants. Obinna Ukoha (Obisco) was also a design mentor. He, together with Officialemeka, helped designers during unblocking sessions on the Saturday meetups.

Emmanuel Uchenna (Eunit) was in charge of the web developer track. Ihechikara, Joshua Akachi, and I were the other web development mentors. We assisted web development learners during the Bootcamp. They carried out and submitted tasks assigned by Eunit each week.

As students, we couldn’t meet with learners every day. We gave participants resources, to learn from during the week. We assisted them with learning in Whatsapp groups and on Saturday meetups. Each Saturday meetup had its separate agenda. Most of the time, it involved unblocking sessions, solving difficulties in participants’ learning journey. The following are what happened during each meetup.

Intro Meetup — Sat. 17th April 2021

Check out the pictures of the event at https://gdsc.community.dev/e/mc6aun/

The day’s program involved an introductory session and then a parallel session. I was on stage during the first session. Initially, I described what communities programs were and spoke on GDSC and Genesys. I then explained the Bootcamp’s structure, what we expected of the participants, and what the participants expected from us. You can check out the following slide.

We separated the audience in two. On the right were web development participants, while on the left were UI/UX design participants. Eunit and Officialemeka addressed each group, respectively. They introduced the objectives and demands of each learning track. They, together with other mentors, assisted the participants in setting up their development environment (for developers), and Figma accounts for UI/UX designers.

We were surprised by the number of attendees. We had up to 80 people in attendance. This Bootcamp was the first in-person/physical event we publicized this much. Our promoters did their job well (Thanks to Michael and Micode). Asides from their presence, the commitment of these was also mind-blowing. They promptly followed up with the event. Those who didn’t have laptops paired up with those who had. We were impressed.

We had some challenges with the projector and with power. The person who delivered the projector to us forgot to bring the power cable of the projector. Consequently, we couldn’t project the slides during the event. Concerning electricity, I thank Festus Ali, Onyinyechi Gilbert, and NFCS for providing us with generators. As of the Bootcamp, the school had not yet powered Convocation Arena, so these generators helped us. We provided fuel for them.

Google Forms was also part of the “challenges” story. We created a Google Form for collecting submissions of individual projects across the weeks. However, Google Forms kept on blocking the form, that the form violated their policies. The fields in the form were: name, email address, phone number, learning track, and submission link. We didn’t know which policy we violated.

This blocking forced me to create a custom submission form. We used it to collect participants’ submissions across the Bootcamp. I built the frontend of the form with HTML, CSS, and vanilla JavaScript (without any helper libraries or frameworks). I then made the form to submit to a Google Sheet we had set for that purpose. That way, we could monitor submissions.

At the end of the intro meetup, we took a group picture. The participants went home, and we expected to submit what they had built before the weekend. UI/UX design participants had to replicate the Google Search page. Web development participants were to develop a simple portfolio for themselves.

Week 1 — Sat. 24th April 2021

Check out the pictures of the event at https://gdsc.community.dev/e/mwc8k8/

The day’s program had only one activity: grouped learning. Learners clustered around mentors and followed along on how to carry out the task they were to submit. We had new members. Some persons from the previous week didn’t attend. The meetup was still at Convocation Arena. Festus and Gilbert still helped us with generators. We didn’t bother getting a projector, and we didn’t get any again till the demo day.

Feedback from learners made us understand that clustered learning was helpful. Participants explained that the grouped learning provided some personalized experience, given the community. We took pictures, posted them on social media, and rewarded those with the highest tweets. By the next week, UI/UX designers were to submit the landing of a restaurant app, while web developers were to submit a countdown timer built with JavaScript.

GDSC AE-FUNAI on Twitter: "pic.twitter.com/0NtUoswrOy / Twitter"

pic.twitter.com/0NtUoswrOy

Managing the Bootcamp was demanding to the core team members and me. I got more persons into the core team to help various sectors. We had a core team meeting on Monday evening after week 1. There, we discussed and made plans towards [demo day](get-the-link). We also set the day’s program for week 2’s meetup. I motivated everyone to keep volunteering as balancing academics and sacrificing for the Bootcamp wasn’t easy on both mentors and other non-technical core team members.

We changed the venue of the meetups to [Faculty of Humanities](get-the-link). Wait why? Well, because of electricity; so that we won’t spend on fuel any longer. After all, other organizations in school had started using Convocation Arena on Saturdays for their events, so we meuved.

Week 2 — Sat. 1st May 2021

Check out the pictures of the event at https://gdsc.community.dev/e/m6xbzq/

This Saturday was a little different. Eunit spoke on “Documenting one’s tech journey”, and got participants to write their stories on Medium. Below are some stories from Community members, please read them:

• Chinwendu Onyeani: My Journey to DESIGN
• Faith Olohijere: Being A Designer
• Echetanna Nwankwo: I’m enjoying this UI/UX design journey …
• Vinny Vics: My Tech Journey
• …

Collins Anudu guided the audience on registering for GitHub Student Developer Pack. Jason Anosike guided the audience on registering for the Google Africa Developer Scholarship. We equally continued the day with unblocking sessions and clustering mentors and learners together.

We modified the submission form to collect everyone’s Medium story. We stopped submissions as participants were not following up on the homework pattern we had designed. We took community pictures and ended the meetup.

Week 3 — Sat. 8th May 2021

Check out the pictures of the event at https://gdsc.community.dev/e/mpk3hr/

We continued week 3’s meetup in one of the halls in the Faculty of Humanities building. We had just one agenda for the day: clustered learning/unblocking sessions. Participants by this time had made many friends in the community. Those to meddle/learn with were no longer an issue. People learned more stuff. We had new participants who joined the program given that their friends had invited them, and they’ve been hearing about DES & DEV on campus.

I want to especially appreciate our mentors at this point. They technically were so involved in helping the learners that they didn’t have time for themselves. This is because participants met the mentors at other times during the week, not just on Saturday meetups. It’s not easy to volunteer! Thank you mentors of DES & DEV.

Obumuneme Nwabude on Twitter: "Mentoring and Organizing is beautiful when the participants are following up and making progress. Today's workshop (Week 3) involved unblocking sessions and clustered learning.Come for our demo day on May 29th where we'll showcase what we've built 😎#weAreGenesys#GDSCAEFUNAI pic.twitter.com/Lbvn4rvkEj / Twitter"

Mentoring and Organizing is beautiful when the participants are following up and making progress. Today's workshop (Week 3) involved unblocking sessions and clustered learning.Come for our demo day on May 29th where we'll showcase what we've built 😎#weAreGenesys#GDSCAEFUNAI pic.twitter.com/Lbvn4rvkEj

Week 4 — Sat. 15th May 2021

Check out the pictures of the event at https://gdsc.community.dev/e/mpxpeu/

The 4th Saturday of learning had come. I started feeling a little fulfilled that the Bootcamp had been up for a month and activities were progressing in peace. No violence. No casualties. Well, such peace was till the Bootcamp ended. Thank God.

We had reduced attendees this Saturday. Churches that use the halls in Humanities Faculty disturbed our meetup as they had some programs that day. Consequently, we held our meetup for only half as much of the time we normally have our event.

We were entering the two weeks of community building. We attempted grouping participants into teams of Design and Web Developers. The grouping had flaws because some members were absent. We called for unscheduled meetings during the week to get participants ready for demo day.

Unscheduled Meetings & Demo Day Rehearsals

On the next two Saturdays, 22nd and 29th May, we (community members) met. But this time, our meetings were not publicized and we were focused on what each team was to build and how they were to demo on the demo day.

We reviewed the teaming, remixed participants, and analyzed the products been built. Teams prepared and rehearsed their presentations. We aided/motivated participants and took more pictures.

We had more time (an extra week) for the community projects because we postponed the demo day. We postponed the demo day to Saturday 5th June (instead of 29th May) as a result of Biafran insecurities in the South East (of Nigeria) — interstate movements were not permitted. It gave us more time to rehearse and plan better for the demo day in all ramifications.

Bootcamp DEMO Day 🥺😎🥳🎉🎉

• There was food and drinks.
• Jerry Uke spoke on “Community Advocacy”.
• We had a mini-hackathon.
• Demoed 6 community projects.
• Awarded prizes.
• There was food and drinks.
• …

Demo Day is worth its own story.

From when I became GDSC Lead, I had always wanted to organize a demo day. I believe that showcasing what we build helps in maintaining the community spirit. Seeing a demo day come to life gave me some unforgettable joys 🙈.

I was happy on Demo Day because, in totality, we had achieved more community members in our school, created more awareness for tech, and had organized a great event. I was overjoyed because the Bootcamp had finally come to an end (couldn’t wait for this) as I could now rest from weekly consecutive meetups.

Up Next: Demo Day

Please read about the Bootcamp DEMO Day at the following:

About 2021 DES & DEV Bootcamp was originally published in gdscaefunai on Medium, where people are continuing the conversation by highlighting and responding to this story.

School had resumed. Lectures had began. Friends met each other 🥰. Everyone felt the long one-year holiday (due to the COVID19 lockdown and ASUU strike. Google had announced that registrations for the 2021 Solution Challenge were open 🥳.

Planning

I met with the core team and we discussed holding an In-Person/Physical Solution Challenge Info Session. The aim was to sensitize for the 2021 Solution Challenge in our community, drive registrations, and follow up participation.

For the venue, we chose Mercury Relaxation Centre. It was a new eatery in perm site and was close to Agric Audit. We chose it because it has a wide space outside (ventilated for the meetup). The event held on Saturday, 20th February.

We scheduled the event to start at 10 am but began by 1 pm. The lateness was due to some members coming late, … we are sorry 😕.

Be Techie

We began with Precious Ngwube (better known as “Nwoke Nnewi”), a software developer, speaking on Be Techie.

He told his story about how the first time he got to Andela’s office in Lagos. How that experience exposed him to tech communities and volunteering. He spoke on collaboration, open-source internships, digital marketing, and technical writing: all as activities one can do in the tech space. His speech was the best fit for the first physical meetup we had in our community, since its inception. The content of his talk is highlighted in the slide below.

I can’t exclude the fact that Nwoke Nnewi’s talk was motivated by Aniedi Udo TEDx talk in Port Harcourt, where he spoke on “Bridging the gap between industry and academia”. Thanks, sir Aniedi. You can find Aniedi’s TEDx talk on YouTube at https://youtu.be/bneP1GxUiUE

Barter App Giveaway

Victor Amaechi was the Flutterwave ambassador for our school, for the Barter App. In light of partnership and community spirit, Victor had a short session, where he explained about Barter, got the community members to install the app, and shared gifts (money) with them through the app.

Speaking on Solution Challenge

2021’s Solution Challenge, aimed at solving (with software), any or a combination of the 17 United Nations Sustainable Development Goals (UNSDGs). It was a global competition where teams with a maximum of 4 members were to submit their solutions. Participants were all DSC members, irrespective of the institution the student was attending.

The competition expected that the solution must have been tested. That it already had an iteration/modification based on user feedback. And that the code be available (for grading) through any cloud-hosted version control system (like GitHub, GitLab, or BitBucket).

The 2021 Solution Challenge involved using at least one or more of the many Google Technologies to build solutions. The submission deadline for the Solution Challenge was 31st March. After that date, submissions were to be graded by Google according to a preset judging system.

The top 50 teams were to emerge as winners and were to be announced by May. These winners were to continue building and from them, the top 10 finalist teams were to be announced. The best 3 teams were to be selected from these ten as final winners of the 2021 Solution Challenge. Rewards for winners included mentorship from Google, Pluralsight subscription, swags, Chromebooks, etc…

I spoke on the Solution Challenge and got the attending members to register at goo.gle/solutionchallenge (the registration website). In turn, they received their google.dev badge as registrants of the 2021 Solution Challenge. Below is the slide I used, it contains more info about the 2021 Solution Challenge.

I like the 2021 Solution Challenge because we were expected to submit at least a Minimum Viable Product of whatever solution we chose. With this, we did not need to make the solution perfect. The solution just needed to have the minimum features that will make it usable. As such, one could keep building on the solution even after submitting it.

I also like the Solution Challenge because it focused on the UNSDGs. So while getting community members to use their technical skills for great rewards, the challenge made them solve our locality problems. After all, that’s what DSC is out for 😉😎.

The meetup was all fun.

We had varying sessions of fastest finger giveaways for airtime (recharge card pins). We networked with each other and took many pictures. We had a social media competition that involved having the highest reactions on your tweet/post about the event. Treasure won the social media competition and went home with her prize.

Treasure🎀 on Twitter: "#DeveloperStudentClubs #DSC#DSCAEFUNAI pic.twitter.com/PeWmySPQMA / Twitter"

DeveloperStudentClubs #DSC#DSCAEFUNAI pic.twitter.com/PeWmySPQMA

We also had a Kahoot game where members played competitively on simple quiz questions about DSC and the event. The Kahoot entertained everybody. You needed to see the smiles and jumps when people ranked highest per round of the ten questions 😍. Out of the 20 attending members, Victor came third, Precious second, and Leo first. They all went home with their prices 🥳.

ecorun.com.ng

The meetup drew to an end. We were to go and start building for Solution Challenge. Just before we closed, Joshua Akachi and Victor Chukwuebuka marveled us all with a demo of a product they have built for the use of everyone. In a nutshell, Ecorun is an e-commerce and social media in one place. Do sign up there today!

Ecorun

Know more about what happened during the 2021 Solution Challenge Meetup at https://dsc.community.dev/e/m8tk74/

Follow-up Workshop

To help the community members in building for the Solution Challenge, we organized a workshop where we told them more about the Solution Challenge. We compared everyone’s skills and teamed up members. We followed them up later towards building for the Solution Challenge. We made sure that only those who consented and were willing to participate were put in teams. The workshop held on Wednesday, 3rd March from 5 to 6.30 pm (after lectures/classes).

Know more about what happened during the workshop at https://dsc.community.dev/e/m872ak/

My take-home

Leadership is beautiful when people are supporting you. It’s one thing to have a good core team, it’s another to have them helping out in various tasks. Across the events, the core team managed different activities so well. As such, we recorded no failures nor disappointments. Thanks, guys!

Next steps

There was academic pressure on all of us. Courtesy of the long time we spent at home, the school had to rush activities to catch up with the academic calendar. We would have lost a session if not for the rush. Lectures were compressed. Exams were being written in March (at the peak of Solution Challenge). The follow-up was effective but we didn’t get to complete/submit our solutions, because we could not withstand the academic pressure.

Notwithstanding, we have started planning towards having a Web Developer Bootcamp on campus in April and May. RSVP (indicate your attendance) for the event at https://dsc.community.dev/e/mc6aun/

#DeveloperStudentClubs #DSC #SolutionChallenge #DSCAEFUNAI #AE-FUNAI

2021 Solution Challenge was originally published in gdscaefunai on Medium, where people are continuing the conversation by highlighting and responding to this story.

On Tuesday, 1st October (independence day), 2019, we, trainers on “Google Digital Skills for Africa” for Konverge Media, in Ebonyi state carried out our own #DigitalNigeria training at Clevero Hotel, Abakiliki.

https://instagram.com/p/B3FIAfyAPg1/

Missing my would-have-been-first TEDx

When we were done with the event, while parking up, boss Emeka Odibeli who just led the #DigitalNigeria invited me for TEDx Abakiliki that held on Saturday, 5th October, just four days later. He was a speaker at TEDx Abakiliki 2019. I was reluctant and unwilling to attend. This was for two reasons. First, I wanted to rest that weekend. I was previously involved in many Google Digital Skills for Africa trainings and a break in events did me good. Second, I did not know about TED at that time and hence could not make it a priority. Boss Emeka noticed my unwelcoming face and told me: ".. even if you don’t want to attend, attend because I will be speaking that day." Yet, I fall hands. My first reason above won the battle.

Come Saturday, TEDx Abakiliki 2019, was live in town while I was in school (I obviously did not attend). I shared the event’s flyers and pictures on my Whatsapp status. Anchi wanted more details about the event. He knows what TEDs are and was marveled to see me share/attend one. His joyful surprise turned to dismay and madness when he discovered that I was not attending and was doing nothing in my room. Anchi made me feel how bad it was for me to have missed TEDx Abakiliki 2019. That transport from school to town was just 200 naira and the event was FREE. That many persons, himself inclusive, will want to attend TEDs but can not and there was I.

Anchi later explained to me what TEDs are. He referred me to ted.com and Youtube. I checked out the resources and coupled with Anchi’s reaction, it dawned on me what I had lost. I had missed featuring in many photos I would have appeared in. I had missed taking pictures I would have taken. I had missed the experience. I had missed meeting people. I had missed the story I would have told. Above all, I had missed the first-hand ideas shared by that day’s speakers. I from then resolved to attend TED/TEDx events whenever/wherever I can.

Getting to know TEDx Ikenegbu

Early March this year, someone shared TEDx Ikenegbu’s flyer in a Whatsapp group that I am a member of. I visited the tedxikenegbu.org site as on the flyer and visited all its social media links from the site. (The online presence of entities make it easy to know about them). What attracted me and made me hungry to attend this TEDx was a particular speaker: Sir Jude Nnam. He is an ancestor of music (He is just so good at everything about music) and is someone I will like to listen to more often. The event’s ticket cost 3000 naira and the event was to hold on Saturday, 4th April.

I do not live in Owerri where one could find physical adverts for the event. The event site and online info were not enough for me. I wanted to feel the TEDx vibe, wanted more information, and wanted to be receiving updates on the event. This want made me contact and keep in touch with Martin Uwakwe, licensee of TEDx Ikenegbu. Through him, I got to know about the shutdown of the event, due to COVID19. I had not bought my ticket by then.

Post COVID19

The COVID19 pandemic later eased out and still through Martin, around November, I got to know about TEDx Ikenegbu’s new date. The TEDx event was now to hold on Saturday, 12th December. All the speakers were retained. I purchased my ticket three weeks earlier and could not wait for the event to hold. I had high expectations, I mean all the stories Anchi had told me and all the recordings on Youtube. Not just that, it was the first TEDx in Owerri. I was expecting Sir Jude Nnam.

Preparing to attend

In the spirit of sharing ideas, I got in touch with my friends that live in Owerri to inform them about the event, and possibly get them to attend. Only two persons out of the twenty I reached out to, knew about the TEDx event. Others were like me when Anchi first shouted at me 🤣. In other words, they did not know what was TED. I was their Anchi and taught them about it. However, none of my friends in Owerri attended 💔. Maybe because it was not a priority to them too, and the event came with a ticket cost, unlike Abakiliki’s that was free. I basically attended alone.

I was living in Awka at that time, and it was two hours journey to Owerri. The event was to start at 9 am and end by 3.30 pm. I had high expectations and did not want to come late for the TEDx event or miss any beginning parts. I sought means to sleep in Owerri on Friday, to be sure I was at Benchmark hotels (event’s venue) on time, but they did not work. I ended up coming to Owerri very early from Awka that Saturday morning. I had prepared so well the previous night that by 5.30 am, on Saturday, I had left home for the park.

I was disappointed

You needed to see me rush, thinking that the event must have began 🤦‍♂️. I arrived at the venue exactly at 8.55 am and was shocked that many things were still being prepared. The hall was empty, attendees and speakers had not yet come. The organizers were busy putting things in order. Lighting, sound, and the hall’s decoration were being set. Nobody stopped/welcomed me at the entrance at this time 💔. I was angry.

I greeted Martin and tried having a chat but could not because he was busy. Many were reaching out to him for important things. I angrily left the hotel and strolled its streets. Later found a restaurant and had something to eat. I delayed outside to try to calm down but it did not work. I returned to the venue an hour later.

This time around, I was stopped by the ushers: they wanted to register me. The registration process entailed identifying that one had purchased the event’s ticket and giving the attendee event “properties”. Given that I registered online, I could not provide a physical ticket. The ushers searched my name on the laptop they had and approved my registration. I was given a jotter, pen, and an attendee tag. The tag had my name printed on it.

My name was wrongly spelled (making me angrier). I was asked to wait and was kept standing without being attended to for a long time (increasing the anger) 💔💔💔. I later entered and got a seat. This first bad impression of TEDx killed the vibe I had. It made me not to make new friends there, besides the ones I knew/invited did not come.

Parts of the hall’s setup were complete. The hall was a tenth filled with attendees and Sir Jude Nnam had come. I chatted up Anchi and Okezie and shared my dismay with them. They consoled me and explained that the event’s speakers will meet my expectations. But omo, the music in the hall was so loud, I could not bear it, I had to walk out again. I snapped pictures on the TEDx Ikenegbu board.

I stayed outside till the event began around 11 am (out of anger). I then imagined if I had slept in Owerri to meet up with time just to face such disappointments, the anger would have been more than me. Besides, I had sacrificed other endeavors to attend this event and the event started late. Another source of grief was the fact that, if the event began late, it will end late. I was to go back to Awka that very Saturday and will not like to go home when places are dark. I got better consolation after speaking with Prisca Naya. She was among the team organizing and she really calmed me down. She corrected my name on my name tag 🤩.

TEDx Ikenegbu 2020 was awesome

Uzodinma Akalonu, the MC, did his job well. He kept using the TEDx event’s theme: “A New World”, in almost all he said. I liked the way he introduced and appreciated each speaker. There was this sticking-to-the-theme (“a new world”) by all speakers, irrespective of the diversity of discipline from which they spoke. Each speaker was being awarded a TEDx Ikenegbu branded pillow after their speech.

It was unfortunate that there was a power outage at some point. It lasted for three minutes and was in between a speaker’s speech. We had a break after seven speakers spoke. Water was shared while food came later. I sat on stage while it was clear, and was snapped there by Miriam (whom I sat next to). Thank you, Miriam! I also had a little convo with Sir Jude Nnam, during this break, and believe me, that felt good 😍.

Still, during the break, people wrote and signed on the big backdrop, outside the hall, set aside for that purpose. They wrote about what a new world meant to them. They equally took pictures there. I got a marker and expressed myself. I wrote: “NEXT TIME, START EARLY”. 🙄

The TEDx event was good. The organizers and team members put in much effort to make the event work. Notwithstanding the late-starting, every other protocol was properly set (except the food vendor that delivered late too). Listening to the speakers appeased me as Okezie mentioned that it would. Just that how I first felt is part of my story. It seems only I felt that way. Maybe because I might have over expected. Besides, this was the first TEDx Ikenegbu. Dear organizers and team members, you did a great job. Kudos!

After the break, there was a Kahoot game on questions about Imo state and details on the TEDx event we were attending. I took part and was nowhere near to the leaderboard’s top. I sat at the hall’s left periphery and could not see the slide which was projected to the left side of the stage. It made no difference. After all, I do not know much about Imo state. About sixty persons participated and it was really competitive. The winner, Emma was awarded a TEDx Ikenegbu branded pillow.

The Speakers

This is the best part of the story. It is why we all came. Great speakers from here and there. The claps after each were much. The first speaker, Chika Jones did a good opening with his poem performances. In fact, below is each speaker, and an attempt to mention in one sentence what I understood from each. They said a lot of unique things and told a lot of stories, such that, no summary will do justice to what they shared.

1. Performance poet, Chika Jones: From now on, let our conversations be with purpose.
2. Lawyer, Victoria Ibezim: Empower the woman, and she will build your nation.
3. Filmmaker, Ekene Mekwunye: Let us, in our films and stories, show a nation we want.
4. Life coach, Ritchie Felix: Prepare yourself for a more digital and connected economy.
5. Gynecologist, Chito Nwana: Speak up, share your story, and embrace mental health.
6. Breast cancer survivor, Betty Anyanwu-Akerodolu: With the right thing done at the right time, breast cancer will not kill its patients.
7. Writer, Ebubechukwu Ibecheozor: Fear, when harnessed properly, can make us do the right thing.
(after the break and Kahoot game)
8. Financial coach, Hector Okechukwu: Long-term vision, business education, social capital, and better cultures will help reduce the number of failing businesses in Africa.
9. Clinical prosthetist, Victor Anukam: When next you see a differently-abled (instead of disabled) person, think about their capabilities.
10. Software Developer, George Iwu: Given that digital devices and artificial intelligence will soon take over most work, harness those human skills that will be in need in the nearest future.
11. Music “Ancestor”, Sir Jude Nnam: All things shall perish under the sky, music alone shall live never to die.
12. Gender equality activist, Solomon Buchi: Dear patriarchy, rest in peace.

Forgive me!!! It is improper to have reduced fifteen-minutes mind-blowing talks to one sentence each. The talks were very rich. Besides, I have been writing from my own perspective. To make up for my offense, I wrote in greater detail about TEDx Ikenegbu, together with the videos of each speaker. There, I told the story of the event and not my own story. Please read it at https://obumnwabude.medium.com/tedx-ikenegbu-6a40d7ec7c02

Sir Jude Nnam

He is commonly called “ancestor”. He has great prowess in anything music. Remember, he is the speaker I wanted to listen to. I gave more focus during his time on stage than during others. It was good as he was last but one speaker. It made me pay attention to those who spoke before him. Otherwise, I might have lost focus in the TEDx event, given that my desire would have been satiated much earlier.

He was on stage with a piano and he sang thrice. He started his session by singing: “All things shall perish under the sky, music alone live never to die”. His talk was on: “Music composition in 10 minutes.” He explained a fact. That we in Africa, we all actively participate in music. That everybody has music potential. He also taught that we can use music to fight stress. There are many other things he shared.

“Be open to every genre of music”

“Be able to play an instrument”

“Write music from your heart”

“Music theory will help you write down the notes you compose”

“Find a group where you can express your music”

“PRACTICE! PRACTICE!! PRACTICE!!!”

He engaged the audience in singing and harmonizing a very short piece. He later told his story of how he composed “My Story” on a sickbed in 2003 with a hanging leg. The song is at https://www.youtu.be/aLhMgFL14nI. Thanks, sir for the inspiration. What I took home was I need to give music time, which is something I would do. After all, for a new world, it is clear that we will all need music 😎. When leaving for my way back to Awka, he himself bade me bye 🥺.

What really is TED?

TED is from Technology Entertainment and Design. Today, it covers almost all topics. It is devoted to spreading ideas. TEDx events are independently organized. TED events that help share ideas in communities around the world. I missed TEDx Abakiliki in 2019, and I’m delighted to have attended my first TEDx event: TEDx Ikenegbu 2020, which has done justice to the spirit of TED and sharing ideas. I remain ever hungry to attend TED/TEDx events whenever/wherever I can.

Thank you!

Know exactly what happened during TEDx Ikenegbu: A New World at https://obumnwabude.medium.com/tedx-ikenegbu-6a40d7ec7c02