zenionyx

[zenionyx]

projects/making-apis/log-1

I started the project around 10:30am.

The first API I wanted to build was something static — minimal, requiring little to no updates. I decided on an API that holds a collection of all 37 miracles performed by Jesus Christ during his life on Earth, based on the accounts in the Bible. It felt like a good, contained dataset to begin with.

This was also my first time properly using Express.js. I don’t fully understand it yet — but I’m learning by doing. I structured the project with an app.js file, a separate JSON file for the data, and a routes.js file for handling the endpoints.

After some refactoring and inserting the full list of miracles into the JSON file, the next challenge was deployment. I Googled around and found Render.com, which allows you to deploy a live API for free. I also came across RapidAPI, where developers can list their APIs as products — but for now, I just want it working. Not monetised.

After some trial and error, it’s live on Render. The data loads, the endpoint works, and I can fetch it. It’s simple, but it works. That was the goal. I finished today's task at 3:15pm.

I haven’t listed it on RapidAPI yet. I’d like to design and upload a small landing site for it first — that part, the UI, is what I enjoy most. I also want to test it inside a separate project, fetching from the live version instead of localhost.

But that’s tomorrow’s task.

Thank you for reading. More soon.

[zenionyx]

projects/making-apis/init

One of the weaker points in my skillset has always been creating APIs.

In my day-to-day work, I rarely need to write them from scratch. Most of the time, other team members handle the API side — creating endpoints, managing requests, integrating services. I’ve mostly avoided it. For a while, I wasn’t sure why.

Eventually I realised it was because I didn’t fully understand them. I knew how to use APIs. I didn’t really know how to build them. And that gap quietly stayed there, unaddressed.

So I’m going to try filling it.

The plan: create five APIs from scratch over the next two months. Small ones.

I’ve seen people build and ship APIs in a weekend, publish them to marketplaces like Rapid. Others take weeks or months to polish something more complex. I’m not aiming for anything massive — I just want to build a few clean, functional ones end-to-end.

That’s the goal.

Thank you for reading. More soon.

[zenionyx]

blog/developer-vs-engineer

I don’t love Software Engineering.

I trained as a Software Developer. That’s what I enjoyed then, and it’s still what I enjoy now. My previous role was Web Developer. I liked it. My current title is Software Engineer — and I don’t enjoy the “engineering” part.

I don’t aspire to architect systems. I’m not aiming for infrastructure mastery or microservice design. I like building things and then moving on. My brain works in tasks. In quests. A feature is a problem; I solve it and move forward. That’s the rhythm I understand.

When the conversation shifts to CI/CD pipelines, scalability, deployment pipelines, I disconnect. It’s not just disinterest. There’s an expectation in tech that every developer should eventually care about “the bigger picture.” But not everyone wants to be two roles in one.

I prefer tickets that ask for new components, new features, fixes with visible outcomes. That’s where I focus. That’s what feels good. I see other engineers talk deeply about pipelines and system stability — and I respect it — but it’s not for me.

What I enjoy is turning design into reality. From idea → interface → interaction. That’s the role I want.

And that’s why I prefer being and being called a 'Software Developer'.

[zenionyx]

project/bokbi/log-1

One part of building Bokbi that I’ve been avoiding — or at least delaying — is the landing page.

Whenever I begin a new project, I tend to focus on the internal experience: the parts that matter once the user is already inside. Logged in. Actively using the thing. That’s where I naturally gravitate. The dashboard. The form flows. The tagging systems. That part makes sense to me.

But the landing page is different. It has to explain. It has to invite. It’s for people who haven’t used the app yet — who don’t already understand the problem it’s solving. That shift in mindset has always been more difficult for me.

The issue isn’t really the wording. I know what Bokbi is, and I can describe it. What’s more challenging is the design — how to build a landing page that suits the nature of this project. Something niche, fandom-adjacent, personal — but still clear, clean, and easy to understand.

The image above is an early mockup of the landing page. It’s not even close to the final design — honestly, I find it a bit ugly. But for now, it serves its purpose: explaining what the app is and who it’s for.

At the moment, I’m drawing inspiration from Vercel’s “v0” and collecting visual references on Pinterest. I’m not just looking at aesthetic direction, but also page structure and content hierarchy.

I’m turning my focus to that page. My goal is to complete a first proper version of the landing by the end of the week. Even something minimal — just a space to introduce Bokbi, outline its purpose, and set the tone.

It doesn’t need to be final. It just needs to exist.

Thanks for reading. More soon.

[zenionyx]

project/bokbi/init

Bokbi is a web app I’m building — a reading tracker for multi-source, non-standard content. It’s meant for people like me who read across fanfiction sites, manga aggregators, webtoons, and random webnovels, and have no centralized way to track any of it.

I started this project for personal use. I’ve tried using spreadsheets, Notion templates, even dedicated apps — but nothing really worked. Most of them are too rigid, or only support one kind of content. I wanted something that let me track everything I read, no matter where it came from. So I began designing my own.

I have bought a domain for it and right now, I’m working in Figma — building out the main screens of the app: → A library/dashboard → The “Add a Story” flow → Story detail pages (with tags, notes, reading status)

I’m holding off on coding until the core UX feels solid. I want to know how I want it to function before I worry about implementation. I’m also spending time doing research — looking at how other people manage their reading across platforms, and what features are actually useful in practice.

This is the first time I’m developing something that feels like it could be useful beyond just me. Which is exciting and weird. I'm primarily a frontend dev, so the backend side of things will be a stretch — but I want to learn.

Bokbi is my main focus at the moment. I’ll be documenting its progress here.

Thanks for reading. More soon.

[zenionyx]

✶ About This Blog

A development journal. A digital reliquary. This is where I document what I build — mostly for myself, but you’re welcome to linger. I am Frontend-focused but learning Backend.

✟ Current Project(s):

"Bokbi" : { "type": "web app", "description": "a reading tracker for multi-source, non-standard content.", "status": "designing UI on Figma" }

"Steam Profile Inspired Portfolio" : { "type": "website", "description": "a portfolio page that looks like Steam's User Profile", "status": "Planning" }

✟ Expect:

programming logs (front-end focused)

design ideas + iterations

project updates

No fixed schedule. Just progress.