Forem: Damilare Osibanjo

Why I Built dd-tinylog: A Lightweight Logging Library Made for Speed and Simplicity

Damilare Osibanjo — Wed, 19 Nov 2025 20:44:53 +0000

The Core Problem: Logging Has Become Too Heavy

In many Node.js projects, logging libraries try to handle too much at once:

complex configuration files
confusing APIs
nested options that make setup slower than writing your own wrapper
blocking writes that slow down the event loop
inconsistent performance between development mode and production

I wanted to create a logger that didn’t feel like a burden. You should be able to add it to a project quickly and rely on it without thinking too much.

GitHub Repository: https://github.com/Dev-Dami/tini-log

The Philosophy Behind dd-tinylog

1 . It is Lightweight
Minimal overhead. Fast defaults. Async transports avoid blocking.

2 . It is Flexible
Use text or JSON, choose timestamps, customize prefixes, and change log levels on the fly.

3 . Making Simple Structures
Child loggers offer clear separation between modules, requests, or components.

Real Usage Example

Installation

npm install dd-tinylog

Simple Use of logger

import { Logger } from 'dd-tinylog';

const logger = new Logger({
  level: 'info',
  async: true,
  colorize: true,
  transports: [
    { type: 'console' },
    { type: 'file', options: { path: './logs/app.log' } },
  ],
  prefix: '[My-App]',
  timestamp: true,
});

logger.info('Server started');
logger.warn('Low disk space');
logger.error('Database error', { code: 500 });

Child Loggers

const requestLogger = logger.createChild({
  prefix: '[Request-123]',
  context: { requestId: 'req-123' },
});

requestLogger.info('Processing request');

This keeps logs organized without needing separate logger files or duplicated configuration.

Where Does This Library Fit

Web servers and APIs
CLI tools
Background workers
Microservices
Development and testing

Regardless of the environment, the goal is the same: keep logs flowing without slowing everything else down.

Building a Modular Search Engine: The Struggles I’m Still Facing

Damilare Osibanjo — Sun, 14 Sep 2025 23:09:09 +0000

So I had this painful idea: “Let’s build a search engine from scratch. How hard could it be?”

Turns out… it’s very hard.

I’m still deep in the process, but I thought I’d share the roadblocks, mistakes, and ongoing headaches of trying to piece together a crawler, parser, indexer, and frontend into something that kind of works like Google, but much worse.

The Architecture I Thought Made Sense

I wanted the project to be modular so each part could work independently and maybe even scale on its own. Here’s the rough breakdown:

Crawler (Python): scrapes web pages.

Parser (Go): extracts useful HTML/text.

Indexer (Go): builds the search index.

The Search API (Python): Query Handling

Frontend (Vue.js): where users type queries.

Database (PostgreSQL): keeps it all together.

Sounds clean, right? Reality check incoming:

The Crawler (Python)

Expectation: “I’ll just use requests and BeautifulSoup. Easy.”
Reality:

Handling robots.txt is more complicated than I thought.

I ran into infinite loops (crawling the same site repeatedly).

Some pages block crawlers unless you spoof headers.

There’s also rate limiting…I once brought down my own WiFi.

I realized that crawling is a deep pit of edge cases. Suddenly, I understood why companies spend millions just to maintain crawlers.

Parsing in Go

Why Go? Honestly, I wanted better performance and concurrency.

Struggles:

Parsing HTML in Go is not as simple as in Python.

The libraries feel basic, which is great for speed but not for ease of use.

Dealing with broken HTML is a nightmare because the web is messy.

Also, constantly switching between Python and Go is tiring.

Indexing in Go

I thought this part would be fun. Instead, I faced:

Tokenization across different languages. Do I really want to support Japanese search right now? Nope.

Efficiently storing inverted indexes.

Designing queries that don’t lead to full-table scans in PostgreSQL.

It turns out that writing a search engine involves reinventing many wheels that ElasticSearch solved years ago. But hey, it’s a learning experience, right?

The Search Query Handling

This is where I’m currently stuck.

How do I balance relevance scoring?

Should I use TF-IDF, BM25, or just return whatever matches?

Pagination seems straightforward until you realize that queries need to stay consistent across refreshes.

On top of that, I chose to use FastAPI for the search endpoint because it’s fast and modern. The reality is:

Writing routes is fine, but managing async and sync code with my Go indexer is confusing.

Every small change means I have to restart everything just to check if my API still communicates with the index correctly.

The documentation makes it look simple, so when I encounter real-world problems, like CORS issues, JSON serialization quirks, or blocking DB calls, I just sit there staring at the screen.

Right now, search results are random at best. If you search for “Python,” you might find blog posts about cooking. I’m calling it creative search.

Frontend with Vue.js

Honestly, this has been the easiest part. Vue makes building the search bar and results page feel good. The struggle is all in the backend right now.

The frontend does show how poor the backend is. Nothing is more disheartening than entering a query and seeing your own project fail.

PostgreSQL Adventures

I love Postgres, but:

Deciding what should go in the database versus what should stay in-memory indexes has been tricky.

I’ve had to reset and rebuild my schema about ten times.

Full-text search in Postgres is decent, but combining it with my custom Go indexer is confusing.

What I’ve Learned So Far

Search is hard. Really hard.

Premature optimization kills momentum. I probably didn’t need Go for parsing and indexing yet.

The web is chaotic. Crawlers reveal just how broken many websites are.

It’s okay to stand on the shoulders of giants. ElasticSearch, Solr, Meilisearch, they exist for a reason.

Still Struggling With…

Making indexing fast enough without consuming too much memory.

Relevance scoring that doesn’t feel random.

Keeping modules communicating with each other smoothly (Python to Go to Postgres to Vue).

Motivation, honestly. Sometimes I question if I should’ve just built a to-do app.

Closing Thoughts

Even though it’s frustrating, I’ve learned more about how search engines actually work in the past weeks than I ever did while just using them.

If you’re considering building one yourself, do it for the learning experience, not just for the final product. Or at least, don’t expect to outdo Google with just a weekend hackathon effort.

APIs 101: What They Are and Why They Matter

Damilare Osibanjo — Sun, 07 Sep 2025 09:30:03 +0000

If you’ve been involved in software development, you’ve likely heard the term API mentioned often. But what is an API, and why do developers depend on them so much? Let’s explain it.

What is an API?

An API (Application Programming Interface) is like a contract between two systems. It defines how they can communicate, what requests are allowed, what responses to expect, and what rules everyone must follow.

Think of it like ordering at a restaurant:

The menu is the API.
You (the client) tell the waiter what you want by pointing to the items listed (making a request).
The kitchen (the server) prepares the food (processing the request).
The waiter brings it back to you in the agreed format (the response).

Without APIs, apps would be like isolated islands, with no way to share data and no way to integrate.

Real-World Examples

Weather Apps: They pull forecast data from weather APIs instead of collecting it themselves.
Payment Processing: Services like Stripe, PayPal, or Square provide APIs, so you don’t need to create secure payment systems from scratch.
Social Logins: The “Sign in with Google” option works because your app can communicate with Google’s authentication API.

REST, GraphQL, and Beyond

Not all APIs are the same. Some popular types include:

REST APIs: The most common type. They use HTTP verbs (GET, POST, PUT, DELETE) to perform actions.
GraphQL: This lets clients ask for exactly the data they need, which reduces over-fetching.
gRPC: A high-performance option that uses Protocol Buffers, which is great for microservices.

Each has its strengths, and the right choice depends on your project.

Why Developers Love APIs

Reusability: You can use existing services instead of reinventing the wheel.
Scalability: APIs allow different parts of your system to communicate without being tightly linked.
Innovation: APIs create new opportunities. For example, open banking APIs have enabled entire industries of fintech startups.

How to Get Started with APIs

Pick a simple API: Try a public one, like the PokéAPI.
Make a request: Use tools like curl, Postman, or even your browser.
curl

https://pokeapi.co/api/v2/pokemon/pikachu

Inspect the response: You’ll usually receive JSON that you can parse in your app.
Experiment and build: Add it to your project and see how it fits.

Final Thoughts

APIs are the glue of modern software. Whether you’re building a side project, integrating payments, or setting up microservices, understanding APIs will enhance your ability to build.

So next time you’re coding, ask yourself: Do I need to create this from scratch, or is there an API that already solves this problem?