IGAQ 🏳️‍🌈

I Got A Queery (IGAQ) provides a safe space for the members of the LGBTQ+ community to ask questions, share stories, and read resources about all things LGBTQ+.

Event-driven Architecture
Serverless Functions
Styled Components
Material UI

Summary ✨

I Got a Queery is an `inclusive` platform for the `LGBTQ+` community, providing a `safe space` to ask questions, share stories, and access resources. As a Full-Stack Web Developer, I developed the backend API, integrated frontend and backend, and mentored my team in new technologies. Key challenges included learning Neo4j quickly, utilizing an auto-moderation service, and balancing mentorship. Despite these obstacles, the project was successful, and I learned valuable lessons about fostering growth within a team and the importance of giving teammates space to learn and contribute.

Details 🔎

I Got a Queery provides a safe space for the members of the LGBTQ+ community to ask questions, share stories, and read resources about all things LGBTQ+.

It is a solution that addresses the members of the under-represented community. In its core, IGAQ prevents bad actors from any verbal abuses or hate speech.

You can checkout the Wiki for more information and mockups about the solution.

It was an absolute joy to be a part of a team of self-driven people who, regardless of how busy their schedule was, managed to deliver a huge contribution to the project and spread positivity and kindness. I got inspired by their work and attitude.

My role 🫡

As a Full-Stack Web Developer, my role was to architect and develop the backend API of the platform as well as organizing and planning the integration between the frontend and backend.

I researched, experimented, and learned about `Neo4j`, which is a No-SQL graph database. Then I implemented it in the backend in a Type-safe manner.

I also mentored my team by guiding them to learn and use new technologies and frameworks such as `NestJS` (a `Node.js` framework), `Next.js` (a React framework), `React`, and `Neo4j`.

Challenges 🥵

There were three significant challenges that I faced during the development of this project: Neo4j, Auto-Moderation of hate speech, and mentoring.


Since we were working in a fast paced environment, I had to learn `Neo4j` as quick as possible and start designing data models and implementing it in our backend.

Also, at the time, `Neo4j` was a new technology and there weren't enough resources and libraries (OGMs), hence finding the right approach to query the data was challenging enough to require trial and error experimentation to come up with the right solution.

Due to the immaturity of Neo4j OGM libraries available for Node.js, I had to come up with a Type-safe and clean solution to handle Neo4j models and queries.

Overall, I believe we did a good job on working with Neo4j, but as in every project, I realized we could've implemented it in a more efficient way. For example, designing and working with more than just 1 Graph Modelings, which could've a significant benefit on our overall query performance.

Implementing the Auto-Moderation for hate-speech

This is the core feature of the platform and as a team, we put all of our attention to achieve this.

At the time we were developing this project, we didn't have access to the fancy ChatGPT 3.5 LLM. So, we had to find a third-party API that provides the most accurate text-moderation services.

We researched and discovered a few decent services, and took us a significant amount of time to carefully chose the one that was the most accurate and stable among others.


I didn't have much mentoring experiences before, and during the times I had the chance, I'd always tried to experiment and see the result of my decisions and actions at the end of each project. Same went for this project and I had to try new approaches and correct my past mentoring mistakes.

For example, I decided to give a lots of space to my teammates on doing their tasks and don't take the mentoring as an excuse to jump in their work. But, the challenging part was that I still didn't know where the balance point is, so I sometimes ended up not being there for my team when they wanted me to be.

Thankfully, my experimentation had a fairly positive result and I learned a lot from this experience.

Takeaway 📖

Besides the technical skills that I learned and experimented with in this project, I believe the most valuable lesson would be: Every team-member can learn and contribute to the project, if they were given enough space to grow.

I think it's a good practice to avoid jumping in as much as you can until it is absolutely necessary and the deadlines are not going to be met at all. This also requires you to maintain a balance of not reaching for over-qualification so that people are not under too much pressure.