DEV Community: Kareem Al-Farsi

How to show weather on your personal website in 3 lines of JavaScript (no API key needed)

Kareem Al-Farsi — Thu, 28 May 2026 15:31:24 +0000

I got tired of explaining to people why their "simple weather widget" needed an API key, a signup form, and a credit card.

So I built a weather API that doesn't need any of that.

Here's how you can add live weather to your personal website, portfolio, or side project in about 60 seconds.

The old way (painful)

Most weather APIs make you:

Create an account
Verify your email
Generate an API key
Paste that key into your code
Worry about rate limits
Get an email when your "free tier" expires

For a weather widget on a personal site? That's overkill.

The Nimbus way (one fetch, done)

I made a public API that doesn't need keys. Just call it.

fetch('https://nimbus-api-gxuc.onrender.com/api/v1/weather?city=Berlin')
  .then(response => response.json())
  .then(data => {
    console.log(data);
  });

That's it. No headers. No tokens. No signup.

Real example: Put it on your site

Here's a working snippet you can drop into any HTML page right now:

<div id="weather-widget">
  <p>Loading weather...</p>
</div>

<script>
  fetch('https://nimbus-api-gxuc.onrender.com/api/v1/weather?city=Berlin')
    .then(res => res.json())
    .then(data => {
      const weatherHtml = data.temp_celsius + '°C • ' + data.description +
        '<br>Wind: ' + data.wind_speed_kmh + ' km/h • Humidity: ' + data.humidity_percent + '%';
      document.getElementById('weather-widget').innerHTML =
        '<strong>' + data.location + '</strong><br>' + weatherHtml;
    })
    .catch(function() {
      document.getElementById('weather-widget').innerHTML =
        '<p>Weather not available right now</p>';
    });
</script>

Change Berlin to any city. It works.

Why did I build this?

Because I got tired of closed source APIs that change their pricing every 6 months.

Nimbus is open source. The code is on GitHub. You can read it, fork it, or run your own version if you don't trust me. The API is free because hosting a weather endpoint costs me almost nothing, and I'd rather lose money than put up a paywall.

Try it right now

Open your terminal:

curl https://nimbus-api-gxuc.onrender.com/api/v1/weather?city=London

No API key. No signup. Just weather.

P.S. The geocoding API is coming soon. If you want to convert city names to coordinates without another API key, watch the repo.

Building Hyperonix: A Minimalist Research Archive for the Modern Scholar

Kareem Al-Farsi — Sat, 11 Apr 2026 12:04:25 +0000

Building Hyperonix: A Minimalist Research Archive for the Modern Scholar 📜

In an era of information overload, we don't just need more search results—we need synthesis.

Today, I’m excited to showcase Hyperonix, a high-fidelity research interface designed to turn the chaos of the web into a structured, editorial experience. Built with a focus on speed, precision, and an academic aesthetic, Hyperonix is more than a search engine; it's a digital journal for your inquiries.

🏛️ The Vision: Digital Minimalism meets AI Intelligence

The goal for Hyperonix was simple: create a search tool that feels like reading a prestige journal. While most AI tools focus on "chatting," Hyperonix focuses on archiving.

We moved away from the typical "neon-dark-mode" tech aesthetic and embraced an editorial, print-inspired design. Think high-contrast typography, muted archive tones, and a layout that breathes.

🛠️ The Tech Stack

To achieve real-time synthesis without the lag, we leveraged a modern, high-performance stack:

Frontend: React 19 + Vite for an ultra-fast developer experience and lean production builds.
Styling: Tailwind CSS v4 for a cutting-edge, future-proof CSS architecture.
Intelligence: Groq SDK (running Llama 3.3 70B) for near-instant response generation.
Search Engine: Tavily API for optimized research-grade web results.
Persistence: Firebase for seamless Google Authentication and session management.
Deployment: Render for streamlined CI/CD and hosting.

🔬 Core Features

1. Real-Time intelligence Synthesis

Hyperonix doesn't just give you links. It scans the top results, extracts the most relevant data nodes, and synthesizes them into a structured report with full citations.

2. Deep Research Protocol

For complex queries, the Deep Research mode allows for multi-step scanning, ensuring you get the full context of a topic, from quantum computing breakthroughs to commercial space logistics.

3. The Scholar Interface

The UI is built to be "invisible." The focus is entirely on the text, with smooth transitions and a responsive sidebar that keeps your research archive organized and accessible.

🚀 Deployment in Seconds

One of the project's highlights is its deployment workflow. Using Render Blueprints (render.yaml), you can go from local code to a global production URL in minutes. It handles the build environment, static publishing, and environment variable management out of the box.

🌍 Open for Synthesis

Hyperonix is built for the curious. Whether you're a developer looking for a reference implementation of Groq and Tavily, or a researcher looking for a cleaner way to scan the web, the project is ready for you.

Check it out live: hyperonixsearch.onrender.com

What's next?

I'm looking into adding PDF export for research reports and multi-user collaborative journals.

What would you use a minimalist research archive for? Let me know in the comments!

Building Photon: A Hybrid Ray Tracer That Builds for Windows, Linux, and macOS

Kareem Al-Farsi — Tue, 07 Apr 2026 19:02:25 +0000

Repository: Photon on GitHub

Photon is a C-based adaptive hybrid ray tracer built to explore real-time rendering techniques without locking the project to one platform. The goal was simple: make a renderer that can grow into something serious, while still being practical to build, test, and ship across Windows, Linux, and macOS.

What Photon is

Photon is a modular ray tracing engine written in C17. It combines several rendering ideas into one pipeline:

BVH-based ray traversal
hybrid raster + ray tracing structure
denoising passes
probe-based indirect lighting
adaptive ray budgeting
build-time shader compilation support

The project is designed to run in a stub mode when full GPU dependencies are missing, which makes it easier to develop and test even on machines without a full Vulkan setup.

Why I built it this way

I wanted a renderer that was more than a demo or a single-file experiment. Photon is organized like an actual engine:

include/ holds the core types and API
src/ contains the implementation
shaders/ contains the compute and graphics shaders
.github/workflows/ handles CI and releases

That structure makes it easier to extend later, whether that means better materials, real Vulkan integration, texture loading, or more advanced global illumination.

What makes it different

A few things stand out in Photon:

1. Adaptive rendering

Instead of firing a fixed amount of rays every frame, Photon uses a budget system that can adjust quality depending on performance needs.

2. Hybrid pipeline

The renderer is built to combine rasterization and ray tracing ideas instead of relying on one approach only. That gives more flexibility for future features.

3. Denoising

Rendering noisy paths is normal in ray tracing, so Photon includes denoise stages like temporal and spatial filtering to make the output more stable.

4. Cross-platform release workflow

One of the biggest goals was not just "build on my machine," but "build everywhere." The workflow now produces packaged releases for:

Windows: .exe
Ubuntu/Debian: .deb
Fedora: .rpm
Arch Linux: .tar.gz

All of them are collected into one GitHub release.

The hard part

The renderer itself was not the only challenge. A lot of the work went into making the project reliable on CI and different systems.

Some of the issues I hit:

Apple Silicon macOS runners do not support x86 SIMD headers like immintrin.h
RPM packaging needed the binary path fixed so the installer could find the built executable
GitHub Actions artifact actions had deprecated versions that broke builds
Release creation needed proper permissions in workflow settings

Those were not just build issues - they shaped how the project had to be structured.

What I learned

A few useful lessons came out of this:

Portability matters early, not later
CI breaks fast when platform assumptions are too narrow
Packaging is part of the product
A renderer is more than graphics code - it's build scripts, release automation, and platform support too

What is next

Photon still has room to grow. The next steps are likely:

real Vulkan backend integration
better material and texture support
improved scene loading
more accurate indirect lighting
cleaner packaging for Linux distributions
more sample scenes and validation tests

Closing

Photon started as a ray tracer project, but it became a full cross-platform rendering pipeline with CI, release packaging, and platform-specific build support. That made it much more than "just code" - it became a small engine that can actually be built, shipped, and iterated on.

If you're into rendering, engine architecture, or cross-platform build systems, Photon is a good example of how quickly those worlds overlap.

Explore the repo: https://github.com/GordonFreeman21/photon/tree/main