DEV Community: Hena Suvarnan

Getting Started with GoFr: A Developer's Review & Tutorial

Hena Suvarnan — Sun, 31 Aug 2025 04:34:38 +0000

If you have ever developed microservices in Go, you understand the headache—configuring structured logging, dealing with configs, databus wiring, graceful shutdowns, and so on. That's where GoFr steps in: a minimal yet robust Go framework that helps make developing scalable microservices simpler, quicker, and neater.

In this article, I'll describe my experience trying out GoFr, lead you through a brief tutorial, and provide my honest opinion of where it excels.

???? Why GoFr?

GoFr is more than "yet another Go framework." It includes sane defaults, opinionated layout, and developer-centric tooling that assists you in:

✅ Rapidly bootstrapping services with pre-spieced modules.
✅ Have databases (MySQL, PostgreSQL, MongoDB, Redis, etc.) supported out of the box.
✅ Use standardized logging, config management, metrics, and health checks.
✅ Write cleaner, testable Go code thanks to its focus on dependency injection and interfaces.
✅ Follow best practices without reinventing the wheel.
Basically, GoFr is like having a well-organized toolbox that prevents the “spaghetti code” problem when your service grows.

⚡ Setting Up GoFr

First, install GoFr:


go get github.com/gofr-dev/gofr

Now, create a simple main.go:


package main
import (

    "context"
    "github.com/gofr-dev/gofr/pkg/gofr"
)
func main() {

    app := gofr.New()
// Define a simple route

    app.GET("/hello", func(ctx *gofr.Context) (interface{}, error) {
        return "Hello, GoFr!", nil
    })
    app.Start()

}

Run the app:


go run main.go

Visit http://localhost:8000/hello → ???? You’ll see "Hello, GoFr!".

That’s it—you just built your first microservice with structured logging, graceful shutdown, and config loading already wired in by GoFr.

???? Testing with GoFr

One of the best things about GoFr is its testing philosophy. It encourages you to maintain 100% test coverage for new code. Tests come naturally because of its minimal interfaces:


func TestHelloRoute(t *testing.T) {
    app := gofr.New()
    req, _ := http.NewRequest("GET", "/hello", nil)

    res := httptest.NewRecorder()
    app.ServeHTTP(res, req)

    assert.Equal(t, 200, res.Code)}

assert.Equal(t, `\"Hello, GoFr!\"`, res.Body.String())

Boom ✅ Simple, clean, testable.

???? Working with Databases

GoFr has support for multiple databases built in. For instance, with MySQL:

db := app.DB("mysql")
rows, err := db.Query("SELECT * FROM users")

Configs are injected via environment variables, so you don't hardcode credentials. Your app is production-ready on day one.

???? My Honest Thoughts

After experimenting with GoFr for a couple of days, here's my quick summary:

Pros:
???? Lightning-fast setup.
- ???? Integrated tools (logs, configs, metrics) save so much time.
- ???? Multiple DBs & services supported (Kafka, Redis, etc.).
- ✅ Testing-first approach feels invigorating.
Cons:
- Still in development—community smaller than the giants like Gin or Echo.
- Some functionality needs Docker setups (good for consistency, but bulkier for newbies). But overall? If you're developing production-grade microservices in Go, GoFr is definitely worth a look.

Final Thoughts

GoFr strikes a nice balance—it's opinionated enough to provide you with structure, but loose enough to allow you to do things your own way. If you're sick of wiring up the same boilerplate in each new service, GoFr will change your life.

Try it out here: https://gofr.dev

Happy coding! ✨

Wrestling with GitHub: How My Book App Project Nearly Drove Me Nuts (But Actually Taught Me a Ton)

Hena Suvarnan — Tue, 22 Jul 2025 18:22:18 +0000

So, what’s this project about? Well, I dove headfirst into the GTech µLearn GitHub Enablement Challenge and—because I like to make my life harder—decided to build a Book App from scratch. The twist? I forced myself to use Git and GitHub like a “real developer.” Branches, staging, pull requests, the whole nine yards. I basically wanted to stop being that person who claims they know Git but panics at the sight of a merge conflict.

What was I really fixing here? Honestly, it was my total lack of hands-on Git experience. I mean, I study Computer Science (BTech gang rise up), and everyone keeps yapping about how Git is “essential.” But using it for actual project management? That was new territory for me. My goal: build something that works, and actually use Git properly throughout.

So, how’d I go about it? Broke it up into bite-sized chunks because, let’s be real, trying to swallow the whole cake at once is a recipe for disaster. First, I got cozy with the basics—add, commit, branch, merge, pull request (the usual suspects). Then, I mapped out what this Book App was even supposed to do. Set up my repo, got my local dev environment rolling, and decided every feature gets its own branch (shoutout to add-books and delete-books branches, MVPs of the project). Committed early, committed often. Tried to keep messages clear but, hey, sometimes “fix stuff” is as descriptive as it gets at 2 a.m. Managed everything with pull requests, just to pretend I had a team and wasn’t yelling at myself in the comments. Oh, and I gave myself a 7-day deadline for dramatic tension.

Action plan? Looked something like this:

Day 1–2: Set up repo, mess around with branching until something worked.
Day 3–5: Churn out the main features—add, view, delete books. (Delete was weirdly satisfying.)
Day 6: UI panic mode, aka “make it look less ugly and squash bugs.”
Day 7: Pray. Review everything, merge, submit the final PR, and hope for the best.

Kept a checklist in Notion because if it’s not in Notion, did it even happen?

Success criteria? Simple-ish:

Book App works. You can add and delete books without the thing catching on fire.
Every feature has its own branch and readable commit history (well, mostly readable).
Code isn’t a dumpster fire, and maybe there are comments.
Pull request goes through without the repo melting down. When all that happened, and the app ran smoother than my morning coffee, I called it done.

So, how’d it actually go? Honestly? Way better than expected. I learned more in that week than the last two months of pretending to “study” Git. Sure, my first few commits were chaos, and I totally forgot to branch before coding once (never again), but I fixed it. Merge conflicts? Nailed it. Eventually.

Wins:

Having an action plan kept me from spiraling.
Branches made my life 100x easier.
I can now handle merge conflicts without rage-quitting.

Could’ve gone smoother though:

Maybe I shouldn’t have left UI design ‘til the literal last day. Rookie move.
Forgot to write a README at first (cue facepalm). Added it later, don’t worry.

All in all, I survived, learned a ton, and now Git doesn’t terrify me. Well… not as much, anyway. It's all about the efforts anyway right?....well, I hope so....

From Little Kites to Tech Wings: How 8th Grade Changed My Life

Hena Suvarnan — Thu, 10 Jul 2025 02:17:13 +0000

In 8th grade, life thrust me into a new chapter — literally. I had just switched from a CBSE school to a government school after 7th grade. And now, if you've ever changed like that, you will understand what I mean when I say culture shock. It all seemed new — from the classroom vibe to the manner in which people interacted and related. It was intimidating initially, and for a time, I was the square peg in the round hole. But one thing I was certain of: I needed to make do. I needed to get along.

Next was the school club registration day — an annual tradition in which each student was required to be a member of at least one after-school club. I recall reading through the list of clubs as if studying a menu for a new restaurant. Nothing resonated. until I read "Little Kites."

That title immediately caught my attention — light, carefree, and promising something different.

Little Kites ended up being so much more than I ever could have envisioned. It was a technology club run by enthusiastic instructors who served as mentors, not simply teachers. We lingered after school for what we termed "training sessions," which were actually just the most awesome technology workshops you could possibly attend at that age.

There is where I gained access to tools and platforms such as Scratch, TupiTube, Blender, and a whole universe of easy-to-use animation and coding tools. For the first time ever, I wasn't merely a passive consumer of technology — I was making things with it. That latent spark of interest I'd had in tech suddenly ignited. Looking back at it now, it was actually pretty fun tho.

One of the most exciting highlights? I was chosen for a sub-district bootcamp! And although the sessions were eye-opening and the workshops motivating, let's keep it real — the grub was an entire spectacle in itself (iykyk). The camp housed enthusiastic kids like me from different schools, and I finally felt part of a tribe of tech aspirants. There, I got to meet some cool friends too!

In retrospect, I can see how crucial that club was in determining my path. That single decision — to join Little Kites — was the starting point for my present trajectory. Fast forward a couple of years, and here I am, studying BTech in Computer Science, chasing the dreams that were sown and nurtured during those afternoon hours.

It's ironic how something that began so "little" ended up becoming so life-altering.
So yeah — Little Kites weren't so little after all. They were my wings.

Blog Post: Hydrolumos - Lighting the Future, One Drop at a Time

Hena Suvarnan — Wed, 09 Jul 2025 09:02:31 +0000

When we first signed up for the TechXcel Challenge 2025, our minds were buzzing with ideas — but one concept truly stuck: HydroLumos. A lamp powered by saltwater. No electricity, no pollution — just science and simplicity. Sounds futuristic? That’s exactly what we’re aiming for.

So, what is HydroLumos? It’s a conceptual innovation: an eco-friendly, saltwater-powered lamp designed for areas with limited access to electricity. It uses the principles of electrochemical reactions — saltwater as an electrolyte, combined with magnesium and copper plates, to generate light. But it’s not just a science experiment. It’s a vision — to make clean, renewable lighting accessible and beautiful.

The problem we’re solving is energy scarcity and the lack of sustainable lighting in remote or disaster-prone areas. Millions still live without reliable electricity, and traditional fuel-based lighting is both dangerous and polluting. We wanted to rethink lighting — to make it sustainable, portable, and powered by something as simple as seawater or saline.

To tackle this, our plan was to research the chemistry behind saltwater energy, explore existing designs, and identify how we could improve on them — both functionally and aesthetically. Our version wouldn’t just be practical; it would look cool too. Think sleek, minimalist design with subtle glow effects, ideal for both emergency use and everyday ambiance.

Our action plan looked something like this:

Phase 1: Deep-dive into saltwater battery research

Phase 2: Sketch design concepts + user scenarios

Phase 3: Create a digital prototype & 3D model

Phase 4: Prepare pitch decks and gather feedback

Since it’s still in the idea stage, our success criteria were based on validation. Did people understand the concept? Did they get excited about it? Did it spark (pun intended) imagination and potential? If yes, we considered that a big win.

So how did it go? Honestly, way better than we expected. Judges loved the concept, peers were curious, and the feedback? Super encouraging. We had challenges explaining the chemistry in simple terms and figuring out feasible materials, but those hiccups only made the journey more interesting.

HydroLumos might not be a product yet, but it’s a spark — a bright idea born from curiosity and care. And in this karma war, it’s proof that sometimes, the biggest power comes from the simplest things — like salt, water, and a bunch of students who dared to dream.