DEV Community: James Kaguru Kihuha

Deno X WebGPU X Threejs

James Kaguru Kihuha — Tue, 02 Dec 2025 16:44:39 +0000

As the tradition goes in computer graphics we always start by drawing our first triangle on the screen. Personally I did my first following the WebGPU Fundamentals. And as you can imagine drawing the first triangle was easy, everything after that was a steep learning curve. But today we are on a different topic. Something I've been eyeing recently which is Deno WebGPU.

For those who aren't familiar with Deno its basically a different runtime for JS, a swap in replacement for NodeJs which comes with alot of benefits such as the one I'm talking about today which Deno WebGPU.

Deno WebGPU expands the reach of the JS Developer allowing them to run their graphics application natively on the users device rather than in a browser enviroment which has the benefit of less overhead and something which I'm really excited about is the reduced network cost of transfering large gltf models (These are basically the the 3d objects that get rendered). With this out of the way you can now focus on creating a good 3d epxerience using Deno which can compile your 3d application into an executable than can be run on various platforms i.e macOS, Windows and Linux using Deno compile.(At the moment deno doesn't support targeting Android)

And as you can imagine inorder to create 3d applications you require a decent renderer and thats where threejs comes in. Threejs allows you to define your scene in JS and render them on a screen. Ideally threejs works on the browser but with a few tweaks here and there you can have threejs running on your native application.

Anyway I've created a threejs starter repo to help track how the changes in threejs affect rendering on deno and you can download or even fork the repo to try it out.

https://github.com/james-kaguru/threejs_starter/tree/dev

Cheers. 🍻

Auth servers

James Kaguru Kihuha — Mon, 28 Jul 2025 12:10:46 +0000

Introduction to Observability

James Kaguru Kihuha — Thu, 12 Oct 2023 08:19:11 +0000

Introduction

Observability is defined as how well one understands the inner workings of a system by examining its output. It gives us the much needed insights into our applications that are in production. Observable applications are easy to troubleshoot as one is able to clearly identify bottlenecks in the applications or root cause of an issue. Observability is important especially with the increase in complexity of systems. Without observability, monitoring of large and complex applications would be a daunting task.

Pillars of observability

Observability is built on three pillars: metrics, logs, and traces. All these together are known as telemetry data. The applications being monitored are supposed to emit the data which can then be sent to an appropriate observability platform such as NewRelic

Metrics
Metrics are numerical measurements on a particular aspect of a system behaviour, such as CPU usage, memory usage, and request latency. Metrics are typically collected at regular intervals and aggregated over time.

Metrics are used to indicate the measure of the performance of a system. e.g request latency is a metric that measures how fast a system responds to a request. Measuring the request latency helps one gain insights about how slow or fast a system is.

Logs
Logs are time stamped records of a wide variety of system activity. Logs are typically used for debugging but lack contextual information as compared to traces. Logs can contain a wide varierty of information which with one key piece of imformation being the log level. Log level indicates the severity of the logs, with the lowest level indicating an event or activity that requires a prompt attention. The logging levels of as per the RFC5424 standards as shown below.
0 - Emergency: system is unusable
1 - Alert: action must be taken immediately
2 - Critical: critical conditions
3 - Error: error conditions
4 - Warning: warning conditions
5 - Notice: normal but significant condition
6 - Informational: informational messages
7 - Debug: debug-level messages

Traces
A trace is a collection of spans that represent a complete request or transaction. Traces track the flow of a request through a distributed system, such as a web application or a microservices architecture. A span is a unit of work or operation within a trace. Spans are used to represent the individual operations that make up a trace, such as a web request, a database query or a service call.

Traces are mainly used for debugging and troubleshooting purposes. They are the most detailed of the three pillars as they offer a really in depth view into an application.

Benefits of observability

Observability has many benefits for DevOps teams and SREs, including:
Improved debugging and troubleshooting: Observability can help teams to quickly and easily identify the root cause of problems in production. This can lead to faster resolutions and less downtime.
Improved performance and reliability: Observability can help teams to identify and fix performance bottlenecks and reliability issues. This can lead to a better user experience and reduced costs.
Reduced risk of outages and incidents: Observability can help teams to identify potential problems before they cause outages or incidents. This can help to reduce the risk of service disruptions and data loss.

The Future of Observability

Observability is a rapidly evolving field. New tools and technologies are emerging all the time. One of the most exciting trends in observability is the OpenTelemetry project which seeks to provide a uniform way of creating and managing telemetry data. The project is a gamechanger as is it easens the setup of metrics, logs and traces through automatic instrumentation.