DEV Community: Isaac Shosanya

Luminary: End Of Sprint

Isaac Shosanya — Sat, 28 Mar 2026 10:11:33 +0000

What a month it has been, building out a product isn't as easy as it may seem, but we did it and pulled through. For those of you that haven't been following this series what we we are building Luminary

What is Luminary and what problem does it solve?

For a large part of our history women have been under represented, marginalized and have had their voice taken away from them, we've had the great works done by amazing women around us fall on deaf ears or not even come to light, so that's why we're building luminary for the women. To give a women a platform to have their accomplishments and contributions seen and heard.

The sprint in review

First of all I really want to thank everyone that contributed to the project during this sprint cause in it's own way it's been brutal but fun seeing the project take shape, from an idea that was on paper to something that worked but was incomplete to now a project that's complete but breaks from time to time, It wasn’t a perfect or linear process, but we’ve learned a lot from bugs to the miscommunications we found a way to bring it all together. Now, Luminary has become a brainchild for each member of the core team, and a project we’ve all genuinely loved working on.

What's next

For Luminary, it’s only up from here. We have more features planned, such as:

Allowing people to contribute additional information to a nomination
Providing suggestions for users who want to nominate someone who has already been nominated, so the nominee’s data can be auto-filled
Refining the consent workflow and making it more secure
Migrating the website from basic HTML, CSS, and JavaScript to React, and upgrading the backend to meet better standards

And that’s just the beginning. Hopefully, we’ll have another sprint soon to bring in fresh ideas and keep improving. You can also contribute to the project by raising issues, fixing bugs, or suggesting new features. It’s open source—so feel free to go crazy.

Personally, I’ll be contributing a lot to Luminary in my spare time, while also working on my many unfinished side projects and continuing my learning journey ( Still got top 1% aspirations ).

Shout out the team

I want to give a big shout out to these guys cause they really carried the project like their life depended on it and I'm grateful to have worked with people as amazing as they are;

Ramnan Ramyil ( Project Lead )
Awoyemi Abiola ( Project Lead )
Daniel Chisom ( Engineering Lead )
Micheal Omonedo ( Design Lead )
Ui/Ux Designer ( Ariyo Taiwo )

For those interested in checking out Luminary for those interested to pushing the project further check out the github

Thank you all for listening to me these past few weeks, cheers to many more of these.

Luminary: Week 3 - Bringing it to Life

Isaac Shosanya — Sat, 21 Mar 2026 10:58:22 +0000

So welcome back to my weekly update on the luminary project if you don't know what luminary is well, probably go read my last two articles but for those of you too lazy for that (side-eye). Luminary is an open source platform with it's main purpose to bring women and their accomplishments to the spotlight, it's a directory of the contributions and achievements of exceptional women. Now that we are up to speed into the thick of it we go ( who remembers that song from the movie )

My Contributions This Week

This week was honestly a tough one for me. I had to step in and handle most of the backend work since the backend lead was dealing with some personal issues. It wasn’t something I felt fully prepared for at first, but I stepped up and made sure things kept moving regardless.

Here’s what I worked on:

Remodeled the database schema to better support the nomination workflow and improve overall structure.
Implemented authentication and authorization flows for admins, covering actions like approving, rejecting, and suspending nominations.
Built out the nomination endpoints, handling the full flow from submission to admin review.
Developed an upload endpoint to support image uploads as evidence for nominations.
Reviewed and merged pull requests from other team members to keep development moving forward.

It was a stretch week for me, but also one where I had to take ownership and deliver beyond what I initially thought I could handle.

Technical Decisions I Made This Week

I had a number of decisions to stew about through out this week. The main ones were around whether to stick with Supabase or move to a dedicated PostgreSQL instance, and whether to use Supabase Storage or Cloudinary for handling media uploads, along with a few smaller things along the way.

For the database, I decided to stick with Supabase. The biggest factor here was speed. Using a managed service allowed us to keep things moving without getting bogged down setting up and maintaining individual pieces of infrastructure. At this stage of the project, getting things delivered matters more than finding the absolute optimal architecture. That said, the way things are structured right now still gives us the flexibility to move to a dedicated PostgreSQL instance later if and when we outgrow Supabase.

For media storage, I went with Supabase Storage (buckets) over Cloudinary. This was mostly a decision driven by continuity and time constraints. Since we were already within the Supabase ecosystem, it made more sense to avoid introducing another external dependency just for uploads, especially with tight deadlines. It kept the setup simpler and reduced the overhead of managing multiple services.

Overall, most of the decisions this week came down to a balance between speed, simplicity, and leaving room to scale when necessary.

Reflections

This week hasn’t really been my best, if I’m being honest. I’m proud of what I was able to get done and how far I pushed the project forward, but at the same time, I can’t shake the feeling that I could have done more and left things in a much better place.

That said, getting the project into a stable, workable state was a big win for the team, especially given the circumstances. Stepping up and making sure things didn’t stall is something I don’t take lightly, and I’m proud I was able to contribute to that.

Shout-out to the Team

Finally, a huge shout-out to my teammates. This project — and this article — would not be complete without their contributions.

Product Lead 1: Ramnan Ramyil
Product Lead 2: Awoyemi Abiola
People Manager: Emmanuel Dania
Engineering Lead: Daniel Chisom
Design Lead: Michael Omonedo
Volunteer (UI/UX): Ariyo Taiwo

You can follow the development progress here: GitHub repo

Check out the live site here: luminary

Luminary: Week 2 — Building the Core

Isaac Shosanya — Fri, 13 Mar 2026 22:53:54 +0000

Welcome back to another week of work on the luminary project, for those of us who are new here, welcome again and you might ask;

What is Luminary

Luminary is an open-source platform created to celebrate and recognize women for their achievements and contributions to society. The platform aims to highlight women making an impact across different fields, giving them a place where their work can be acknowledged, discovered, and shared with a wider audience.

The project is being built collaboratively by contributors across multiple roles including frontend, backend, and design, with a focus on creating a scalable and accessible recognition platform.

What I worked on this week

This week my work focused largely on maintaining the codebase and building core backend infrastructure. As the Lead Maintainer, part of my responsibility is ensuring the project remains stable and contributor-friendly while also stepping in where technical gaps exist.

This week I also filled in as the Backend Lead, helping to establish the foundational backend architecture for the platform.

Here’s a breakdown of the main tasks I worked on:

Set up and configured the initial deployment for the project website → https://luminary-for-women.netlify.app/
Began building the backend service for Luminary
Refactored sections of the codebase to support proper deployment and project structure
Implemented API endpoints for:
- Submitting a nomination for a woman
- Searching through the nominated women directory
Designed and structured the database schemas required for the nomination system
Coordinated repository maintenance tasks to ensure the project remained organized and contributor-friendly

Technical Implementation Breakdown

The Luminary backend follows a Node.js + Express architecture, providing a RESTful API layer that communicates with a PostgreSQL database managed through Supabase.

The overall architecture currently looks like this:
Frontend

Static frontend deployed on Netlify
Responsible for displaying nominee profiles and handling nomination submissions Backend
Node.js server using Express
Handles API requests, nomination submissions, and directory queries
Acts as the middleware between the frontend and database Database
PostgreSQL database managed through Supabase
Stores nomination records, nominator information, and nominee profiles

Database Design

To support the nomination workflow, I designed schemas for three main entities:

Nominee (Woman)

Represents the woman being recognized on the platform. This includes information such as:

Name
Field or area of contribution
Biography or impact description
Additional metadata related to recognition

Nominator

Represents the individual submitting the nomination. This allows the platform to track who submitted a nomination while also enabling potential moderation workflows.

Nomination

Represents the actual contribution or recognition entry. This acts as the relationship between the nominator and the nominee, capturing details about the achievement or impact being recognized.

Challenges I Encountered

One of the main technical challenges this week involved deployment issues with Netlify.

Initially, the project structure placed the index.html file inside a pages directory, which prevented Netlify from correctly detecting the entry point for the site. Since Netlify expects the entry HTML file to be at the root of the published directory, this caused the deployment to fail.

To resolve this issue, I had to refactor the structure of the application, moving the index.html file to the base level of the project and updating the directory structure accordingly. This ensured that Netlify could properly identify the entry point and serve the application without errors.

Although this required some restructuring of the codebase, it ultimately resulted in a cleaner and more deployment-friendly project structure.

What I Learned This Week

This week gave me deeper experience in a few areas:

Handling deployment constraints when hosting static frontends
Managing project stability while coordinating contributions as a Lead Maintainer

Team & Contributors

Luminary is a collaborative effort, and a lot of incredible people contributed to the progress made this week. It’s been great working with a team committed to building something meaningful and impactful.

Contributors

Isaac Shosanya — Lead Maintainer
Ramnan Ramyil — Project Lead
Awoyemi Abiola — Project Lead
Daniel Chisom — Engineering Lead
Micheal Omonedo — Design Lead
Ariyo Taiwo — UI/UX Designer

Collaboration has been key to moving the project forward, and it’s exciting to see the platform gradually take shape.

You can follow the development progress here:

Project Repository

And you can explore the live deployment here:

https://luminary-for-women.netlify.app/

Luminary: The Setup

Isaac Shosanya — Sat, 07 Mar 2026 09:06:03 +0000

As it's women's month, me and a group of other wonderful developers were tasked with building something for women and for the open source community and we decided on Luminary

What's Luminary ?

Or rather, what will Luminary be? — since the project is still evolving.
Luminary will be an open-sourced, community-driven directory and news platform that spotlights impactful women who are driving change across different fields. The goal is to create a space where stories, achievements, and contributions of women can be documented, shared, and discovered by others.

The Setup

This week our primary focus was laying the foundation of the project. My specific responsibilities involved maintaining the repository, setting up the open-source structure, and contributing to the landing page.

During this phase we:

Outlined the core requirements for the Luminary project
Set clear goals and responsibilities for the core members of the team
Established a design system in collaboration with the design team and their requirements
Built out the landing page, including a section highlighting all project contributors
Chose the initial tech stack for development

For the frontend, we decided to start with HTML, CSS, and JavaScript, with plans to migrate to React as the project scales.
For the backend, we chose Node.js with Express to power the API and application logic.

This approach allows us to move quickly in the early stages while still leaving room for the project to grow into a more structured architecture later on.

Contributors

Some other really great people worked on this too:

Isaac Shosanya ( Lead Maintainer ): I was tasked with the open source repository setup; including reviewing pull requests and documenting a standard every contributor will follow for the project, I also contributed to building out a section on the landing page.
Ramnan Ramyil ( Project Lead )
Awoyemi Abiola ( Project Lead )
Daniel Chisom ( Engineering Lead )
Micheal Omonedo ( Design Lead )
Ui/Ux Designer ( Ariyo Taiwo )

Lessons Learned

As the lead maintainer, one of the biggest lessons I learned was how important clear standards and structured workflows are in open-source collaboration. When contributors come from different backgrounds and experience levels, having well-defined contribution guidelines, coding standards, and a clear chain of command makes the entire development process much smoother.

Establishing these structures early helps contributors understand how to contribute, where decisions are made, and what expectations exist within the project. It also makes reviewing pull requests, resolving issues, and coordinating contributions far more efficient.

This experience pushed me to dive deeper into how successful open-source projects are organized and maintained—from documentation and repository structure to contributor management and review processes. Seeing how these systems enable collaboration at scale has been both fascinating and inspiring.

Overall, working on Luminary has been a really eye-opening experience, and contributing to an open-source initiative like this is something I would gladly be a part of again in the future.

Case Study of Valentines Day Project

Isaac Shosanya — Fri, 20 Feb 2026 14:25:50 +0000

Problem Statement

Over the past few weeks, I had a task to complete for rise academy and the task was to build something that "shows love or expresses love to someone" cause it was valentines season.

Solution Design

The goal of this application was to lower the barrier to emotional expression for users who struggle with creativity, or intentional with romantic gestures while still delivering an experience that feels thoughtful and meaningful to the recipient.

Feature Logic

The product is designed as a single-page web application to keep the experience lightweight, and emotionally focused. The feature set mirrors the natural progression of how peoples typically express affection:

Poems: This section serves as the emotional entry point. Poetry is a universally accepted medium for expressing love, even when it isn’t personally written. Including poems allows users to communicate depth of feeling without having exceptional writing skills.
Reasons Why I Love You: This section adds specificity and personalization. While the poems establish emotion, the “reasons” section grounds that emotion in tangible affirmations helping the recipient feel seen and appreciated. Even when generalized, these statements are relatable enough to feel intentional.
Virtual Gift: The virtual gift functions as a symbolic closer to the experience. It introduces an element of surprise and playfulness, reinforcing the idea of giving something even in a digital form rather than just saying something "No body likes people who are all talk and no substance ".

Flow Design

The application follows a linear, scroll-based flow, guiding the user through an emotional narrative:

Warm emotional introduction (Poems)
Personal reinforcement (Reasons why I love you)
Memorable takeaway (Virtual gift)

Why I Chose This ?

The solution prioritizes accessibility over perfection. It acknowledges that not every user is highly expressive or intentional, but still deserves a way to show care. By abstracting effort into a clean, emotionally structured experience, the application transforms minimal user input into maximum emotional impact.

Ultimately, the design ensures that even a “lazy” act of sharing the page can still result in a genuine “aww” moment for the recipient.

UI Design System

The design of the application is intentionally simple, emotional, and universally romantic. The design system focuses on using color and typography to evoke warmth, affection, and intimacy.

A centralized design system was created and documented externally to ensure visual consistency across the application and to allow for easy iteration and scalability, you can have a look at it here.

Color Palette

The color palette is anchored by a bold crimson red, supported by neutral tones for balance and readability.

Primary Red (#c8102e) Acts as the emotional core of the application. It is used for key highlights, accents, and moments that require emotional emphasis.
Neutral Background (#f5f5f5) Provides a soft, calm canvas that allows emotional content to breathe without visual noise.
Black & Dark Grey (#000000, #333333) Used for body text and structural elements to maintain clarity, contrast, and accessibility. #### Typography The typography system pairs expressiveness with clarity:
Heartland Used for headings and key emotional phrases. Its hand-drawn, playful nature mimics handwritten love notes, adding personality and warmth to the experience.
Oswald Used for body text and supporting content. Oswald’s clean, modern structure provides readability and contrast, grounding the emotional display font and preventing the interface from feeling overly decorative.

Why I Went With This Emotional Design

The application is designed specifically for the month of love, a time associated with romance, vulnerability, and emotional expression. The aesthetic choices reflect this.

Crimson Red was chosen as the dominant color due to its strong association with love, desire, and affection. However, rather than using multiple vibrant colors, the design relies on a simple color scheme to keep the focus on the message rather than the interface.

The handwritten display font reinforces intimacy and sincerity, while the structured sans-serif body font ensures the experience still feels polished when the content itself is simple.

HTML & Structural Approach

The Application was structured with semantic HTML in mind to ensure accessibility, readability and best SEO practices. Given the product is content heavy keeping to semantic HTML provides the best experiences for both the users and the developer

Semantic HTML decisions:

Using <header>, <main>, <section>, and <footer> elements to clearly define the page layout and content hierarchy.
Structuring each major feature (Poems, Reasons Why I Love You, Virtual Gift) as its own <section> with descriptive headings.
Maintaining a logical heading order (<h1> → <h2>) to improve screen-reader navigation and search engine understanding.
Using <button> elements for interactive actions instead of styled <div>s to preserve keyboard accessibility.
Providing meaningful alt text for decorative and symbolic imagery where applicable.

CSS Architecture

The CSS architecture was built around reusablility through strong emphasis on design tokens and layout techniques.

CSS variables

My css variables were defined at the root level to centralize control over the design system:

:root {  
  --background-color: #f5f5f5;
  --text-color: black;
  --primary-color: #c8102e;
}

Layout Strategy

I used mainly flexbox for the flow of the application, mainly because the content of the website is vertically stacked

Reflections

This project was completed within a limited time-frame due to personal constraints, which influenced both the scope and depth of the final implementation. While the core idea and execution successfully communicate the intended emotional experience, there are several areas I would expand on if given more time.

Future Improvements

Added Personalization: A key improvement would be the introduction of personalization features. Users would be able to access a simple dashboard to customize content, such as names, messages, and selected sections, personalizing the experience specifically to their loved one. Once configured, the users would generate a unique shareable link that leads to a personalized version of the page, increasing emotional impact and user ownership.
Expanded Content: The current version prioritizes structure and emotional flow, but the content on show is intentionally minimal. In a future iteration, I would expand the content by adding features such as an image gallery, a dedicated letter-writing section, or additional curated messages. This would allow users to express affection in multiple formats while keeping the experience engaging.
Enhanced Animations and Visual Polish: While the styling is clean and functional, additional polish could elevate the experience. Subtle animations, transitions, and micro-interactions would enhance the user experience

Link to live site: https://on-the-basis-of-love.netlify.app/

A Beginner’s Guide to Open Graph: Making Your Links Share Better

Isaac Shosanya — Fri, 12 Dec 2025 13:42:09 +0000

What is Open Graph?

Open Graph is an Internet protocol used to standardize how metadata describes the content of a web page when its URL is shared, either among individuals or across social platforms. It allows you to provide various types of information, from the page title to the images or videos displayed on the site.

Why we need it?

Content needs to be shared and engaged with. Providing rich previews when a link is shared significantly improves engagement because users get more context about the page beyond a plain URL. A well-structured preview increases clicks, trust, and visibility across platforms.

Setting up open graph

There are few basic meta tags that we should start with;

og:title The title of the webpage shown in the preview card. This is typically the same as your <title> tag.
og:type Describes the type of content. "website" is the general default if none of the specific types apply.
og:image The image displayed in the preview card. Use a high-resolution image with a minimum size of 300×300px for better compatibility.
og:url The canonical URL of the page being shared. Now how do we use the tag in our websites well, it's metadata so we should have them in the <head> tag and the properties set in the <meta> tags see below as reference.

Plain HTML

<html>
    <head>
        <meta property="og:title" content="Isaac Shosanya - A software developer" />
        <meta property="og:image" content="https://example.com/1" />
        <meta property="og:url" content="https://isaac.com" />
        <meta property="og:type" content="website"/>
    </head>
    <body>
        <h1>
            Hey there
        </h1>
    </body>
</html>

Next.js

export const metadata: Metadata = {
  title: siteMetaData.title,
  description: siteMetaData.description,
  creator: "Isaac Shosanya",
  publisher: "Isaac Shosanya",
  openGraph: {
    title: siteMetaData.title,
    description: siteMetaData.description,
    url: siteMetaData.url,
    type: "website",
  },
};

Some social sites have their own specific meta properties they use, and you should look through their documentation for more insight into how to make certain things function on specific platforms.

Twitter: https://developer.twitter.com/en/docs/tweets/optimize-with-cards/guides/getting-started
Facebook: https://developers.facebook.com/docs/sharing/webmasters/
LinkedIn: https://www.linkedin.com/help/linkedin/answer/46687/making-your-website-shareable-on-linkedin?lang=en
Open Graph Official Docs: https://opg.me
Next.js Open Graph Docs: https://nextjs.org/docs/app/api-reference/file-conventions/metadata/opengraph-image

These examples represent just the basics of Open Graph. There’s a lot more you can do with the protocol, and it's worth experimenting with additional properties to create richer and more engaging previews.

Reference article: https://www.freecodecamp.org/news/what-is-open-graph-and-how-can-i-use-it-for-my-website/

Full-Text Search: A Practical Guide for Node.js, TypeORM & PostgreSQL

Isaac Shosanya — Sun, 16 Nov 2025 16:47:12 +0000

Full-text search is a technique used to analyze strings, documents, or entire database columns to deliver flexible and intelligent search results. Instead of relying on string matching, full-text search looks at context, synonyms, and word variations.

So while a regular SQL query might match only "run", a full-text search can also match "running", "ran", or "runner" depending on the configuration.

Full-text search is supported by many databases including PostgreSQL, MySQL, MongoDB, and specialized engines like Elastic-search and Meilisearch.

In this article, we focus on PostgreSQL full-text search using TypeORM + Node.js.

Benefits of full-text search

Search Large Bodies of text quickly: If you have large text fields, like blog posts, recipes, product descriptions, or comments, full-text search lets you efficiently check which documents contain certain keywords.

Example: Search for "chicken" → return all recipes that mention chicken anywhere in the text.
Better and more flexible search results: Full-text search handles imperfections in queries:
- Typing "run shoes" can still match "running shoes"
- Searching "comput" can match "computer" and "computing"
This dramatically improves user experience on e-commerce, blogs, dashboards, and enterprise search tools.

When to use full-text search?

You want flexibility, not exact matches; Searching products, users, notes, events, or blog posts where partial matches are okay.
When you want to index large bodies of text and return results based on if a certain word or keyword is contained within that body of text ( returning a list of recipes that contain chicken).

Setting up full-text search in typeorm + postgres + nodejs

Below is an example using a simple Recipe entity that supports searching on both the name and description fields.

Create the Recipe Entity

@Entity()
export class Recipe {
    @PrimaryGeneratedColumn()
    id: number;

    @Index({fulltext: true})
    @Column("varchar")
    name: string;

    @Index({fulltext: true})
    @Column("varchar")
    description: string;
}

Query the database using a the typeorm query-builder to return data based on the provided search query

async function searchRecipes(searchQuery: string) {
  return dataSource
    .getRepository(Recipe)
    .createQueryBuilder("recipe")
    .where(`
      to_tsvector('english', recipe.name || ' ' || recipe.description)
      @@ plainto_tsquery('english', :query)
    `)
    .setParameter("query", searchQuery)
    .getMany();
}

In raw SQL this would look something like this

SELECT *
FROM recipe 
WHERE to_tsvector(name || " " || description) @@ to_tsquery("Chicken");

This will then return all the recipes with chicken in it’s description or name