DEV Community: Murtuzaali Surti

Reflections on the AWS & Azure Outages

Murtuzaali Surti — Sat, 01 Nov 2025 07:19:35 +0000

AWS and Azure, two of the largest cloud providers having a market share of ~30% and ~23% respectively (as of 2025), experienced large scale outages recently. These outages affected multiple interdependent services. In this post, I will explore what are the implications of these outages, what can be done about them, and how fragile the web really is.

AWS Outage - October 19, 2025

The AWS Outage on October 19, 2025 began with Amazon's Dynamo DB service — a serverless, managed, NoSQL database service — in the us-east-1 AWS region. As per the official incident report, Dynamo DB's DNS management system published an "empty DNS record" for one of the endpoints, restricting any external/internal service to connect to it. In order to understand, you have to first understand what DNS is.

DNS stands for "Domain Name Server" and is like a phone book that maps human readable addresses to IP addresses (machine addresses). For example, openai.com maps to 172.64.154.211, an IP address of the server/machine the website is hosted on.

Run the following command to see it yourself:

ping openai.com

# output
PING openai.com (172.64.154.211): 56 data bytes
64 bytes from 172.64.154.211: icmp_seq=0 ttl=57 time=14.347 ms
64 bytes from 172.64.154.211: icmp_seq=1 ttl=57 time=15.783 ms
^C
--- openai.com ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 13.575/14.476/15.783/0.696 ms

Press CTRL+C to exit

So, if there's no address listed for a particular endpoint, other machines can't get to it because they don't know where it lives. Technically, that endpoint in now invisible. A similar thing happened with Meta (Facebook) in the past (October 4, 2021) where they had issues with the BGP protocol, in which Facebook stopped announcing their addresses (locations) which resulted in routers not able to find Facebook's servers.

Coming back to the AWS outage, the Dynamo DB DNS resolution issue was just the beginning. It started a domino effect where after the issue was fixed, the EC2 instances which were trying to connect to Dynamo DB the whole down time, experienced "congestive collapse", meaning they were repeatedly trying to connect but when the connection was established, they struggled to keep up with the number of connection requests. The EC2 instances then impacted the Network Load Balancers (NLB).

Azure Outage - October 29, 2025

In 2 weeks since the AWS outage, Azure, the second big cloud provider faced an outage on October 29, 2025, which Microsoft says was caused due to "inadvertent tenant configuration change". This change was made to the Azure Front Door service which is basically a CDN (Content Delivery Network). AFD (Azure Front Door) affected multiple services of Microsoft as it's a CDN, internal/external services depend on it for accessing stored blobs/files.

Microsoft has not yet published a full report of how it exactly happened, but from little do we know, there's an automated validation system which runs after such configuration change is made and it typically blocks such faulty configurations. But, in this case, it didn't. The automated validation system itself had issue with withholding the configuration change and that's how it by-passed the checkpoints.

Thoughts

These outages remind me how fragile the web really is. We think of these big tech corporations and wonder what's the worst thing that can happen to them? I mean, they have all of the resources, power, and money, so how can anything go wrong with them?

The fact is that no matter how big the tech organization is, they all depend on basic technologies which make the web, world wide web. No matter how much they claim they are reliable, the truth is, nothing is reliable enough. All of these complex systems are just abstractions built on top of really basic technologies, and when those basic technologies are affected, disruptions happen.

It all boils down to a mesh of interconnected systems which talk to each other, the only difference is, we don't see any of that. We are so glamorized by these complex software abstractions that we fail to see the very basic foundation they were built up on.

At the end, we are all sitting on top of fibre optics.

Zerodha, a brokerage firm, announced their FLOSS fund in 2024 to fund open source projects. Nithin Kamath, CEO of Zerodha, shared a post on why everyone should support and fund open source projects. He made a really good point that companies which earn billions of dollars relying on many small open source projects (without them their services would be rendered completely useless) are simply not willing to sponsor or fund them. Now, I know I am going a little off tangent with this, but the point is that if one of the underlying services fail, you start to see a domino effect where all of the above abstractions fail with it.

So, as much as maintaining the complex systems is important, it's equally important to maintain and fund the small, miniscule-looking technologies which are basically the backbone of software abstractions.

The Minimal React App Setup You Need

Murtuzaali Surti — Fri, 19 Sep 2025 16:18:25 +0000

Deciding which tools to use while building a React web application is subjective, but in this post, I will propose a minimum set of tools needed to build a simple React application. This post will help you to build and get the React application up and running in just a few minutes.

1. Vite (For Bundling)

Vite is now the go-to choice for most of the developers while building a React application from scratch. I wrote a detailed article about why is that the case — "Create React App (CRA) is Deprecated, Officially: What's Next?".

Vite will take care of the build process and bundle React in a javascript bundle ready to be deployed. As a matter of fact, Vite provides React templates which you can use to quickly spin-up a Vite/React repository — "Scaffolding Your First Vite Project".

npm create vite@latest my-react-app -- --template react-ts

All of the templates Vite provides - create-vite.

2. React Router (For Routing)

React Router might not be the best solution for routing in React, but it is one of the stable solutions out there. If you want a more modern solution, then there's Tanstack Router from the Tanstack ecosystem which is a great contender for React Router.

Tanstack Router provides in-built type-safety (typescript support) with file based routing approach unlike React Router which has a more declarative component based approach.

3. Shadcn (For UI components)

Shadcn is the modern UI library which has almost every component you need. Not only that, those components are customizable and can be built up on. It works well with tailwindcss.

Some other notable UI libraries include MUI, Ant Design, Chakra UI, and Mantine.

4. Tanstack Query (For Query State Management)

Tanstack Query is by far the most important and useful tool in modern React applications. API query management is one of the most boilerplate-y tasks while building a React application. I always think about how to manage those API calls, their states, and how they impact the UI. All of that is solved by Tanstack Query (React Query) which is a complete and state-of-the-art solution for query state management.

From maintaining, caching, refetching queries to having dependable and conditional queries, almost every query fetching problem is solved by Tanstack Query.

5. Zustand (For Global State Management)

I really don't like React Context API for top-level state management as it re-renders everything in between (even if it doesn't consume/use the context).

And I don't blame React Context API for that. It is meant to trigger a re-render because we are wrapping the components under a Provider and it assumes that every child will be affected by it. So, the Context is attached to a parent and all of its children. But, true global state doesn't necessarily have to be attached to a React component. It has to be truly global.

In fact, React Redux also uses the React Context API internally to pass store data to deeply nested components, which doesn't make it truly global.

That's where Zustand comes into action. Zustand provides global states which aren't attached to the React Component lifecycle. Another nice perf optimization one can do while using Zustand is using atomic selectors instead of selecting the entire store state at once.

const ReactComponent = () => {
    // ❌ - returns a new object ever single time
    const { inventory, users } = useShopStore();

    // ✅ - atomic values which stay the same if unchanged
    const inventory = useShopStore(state => state.inventory);
    const users = useShopStore(state => state.users);

    // ...
}

Thoughts

The above list is not exhaustive and it is the bare-minimum set of tools required to build a simple React application. I am not saying that this is the ultimate React setup which should be used for every application. You might not even need global state management for instance, and in that case you are free to skip Zustand. But it's a great start if you quickly want to get things running.

Vibe Coding — The Fast Food of Coding

Murtuzaali Surti — Wed, 20 Aug 2025 15:25:19 +0000

The usage of AI, especially in the software industry, has increased a lot lately, but everything has a downside — and that, is, excess. Excess of anything is bad, and that includes the use of AI. With that in mind, in this post, I explore the downsides of vibe coding and how to balance it.

Recently, Zen van Riel - a senior software engineer at GitHub, shared a linkedin post about the dark side of vibe coding. He describes a developer constantly trying to fix "simple things" using an AI model but, unfortunately, the AI model fails to do so every time. It's not only a waste of time, but a waste of money (credits) as well. Zen wonderfully describes this through an analogy of fast food (hence, the title of this post).

In my opinion, that's a brilliant analogy because it talks about balance. Let me draw some parallels between fast food and vibe coding.

Vibe Coding & Fast Food

1. Instant Gratification

When you send a prompt and see output in a matter of seconds, you feel good. It gives you a dopamine hit, a sense of accomplishment, but it's only a matter of time when it all fades away.

When the AI model starts making mistakes and no matter which prompt you give, it still doesn't work, that's when you start feeling I could have done it myself.

It starts becoming messy if you look at the bigger picture.

2. Opinionated Ingredients

If you don't know what you are building, AI model can use whatever it thinks is good to build your application and sometimes it's not the best for your application and use case. And, it can be very hard to refactor later.

For you to be able to give enough context of what you are building and why, you need to be aware of the available tools and techniques needed to make that happen.

3. Lacks Nutritional Value

Once you get the taste of it, you stop asking the "why"/"how" question. Questioning what the AI model does almost feels like a second thought. And you know what it does? It drains your ability to learn and grasp new things.

That's the reason I never recommend beginners to rely solely on AI tools for coding/programming. Always questions things and ask the model why it did what it did.

4. Looks Good on the Outside

AI tools might get you the exact thing you want, but if you look closely at the code, (if you have decent knowledge about programming) you start seeing inconsistencies and tech debt.

5. Forms Bad Habit in the Long Term

If you only vibe code, you never get to focus on the grilling part of programming, which is to sit patiently and think about the problem at hand. You never really learn how to dissect a problem and solve it incrementally.

Some of the best solutions to software engineering problems I had occurred to me when I was asleep, walking or just wandering around with an open mind. Sometimes, all it takes is to take a step back and relax.

Correct Usage of AI tools for Coding

Don't solely rely on AI of you are a beginner. Read in-depth articles, watch YouTube videos explaining how stuff really works and practice, build something. Building something on your own is key and it will get you out of tutorial hell.
Familiarize yourself with what you are building and why. It's easy to get lost in whatever the AI model generates, so it's necessary to have decent knowledge about technologies you want to use to build your project.
Use AI model in an incremental way. Prompt the AI model to do small changes instead of giving it a complex task. Break down the problem yourself, or even better, prompt the AI model to generate a plan first, study the plan, and then tell it to implement. It will help you learn and break down the problem.
Ask the AI model why it did what it did. AI models are great at explaining things, so use it to your own advantage.

I wrote about my experience of vibe coding an entire full stack application in this post — "The Problem With AI Generated Code And How To Deal With It". Let me know if you found it useful.

Deep Research in Tech Recruiting

Murtuzaali Surti — Sun, 23 Feb 2025 09:23:05 +0000

In my opinion, companies might start integrating deep research functionalities of platforms such as Grok, Perplexity, OpenAI, etc. and use them to do a quick research about the person that they are willing to hire. Now I am not sure up to what extent they might use it but I see at least some use of it in the near future.

I have shared my thoughts here: https://syntackle.com/blog/leveraging-deep-research-by-building-an-online-presence/

What do you think?

Deprecation of CRA and What's Next

Murtuzaali Surti — Sun, 16 Feb 2025 14:41:53 +0000

Here are my thoughts on the official deprecation of Create React App and what should you migrate to next.

https://syntackle.com/blog/create-react-app-deprecated/#thoughts

Celebrating 50 articles on Syntackle

Murtuzaali Surti — Sun, 12 Jan 2025 12:41:58 +0000

Completed 50 articles on my blog syntackle.com. Wanna join me? (syntackle.com/write)

Server Sent Events 101

Murtuzaali Surti — Sat, 11 Jan 2025 12:55:55 +0000

Server Sent Events (SSE), as the name suggests, are a way to communicate with the client by keeping a persistent connection in which the server sends text messages to the client whenever they are available. They are similar to websockets but, unlike websockets, the connection is unidirectional, i.e. only the server has the capability to send messages and the client just listens.

Another key difference between SSE and websockets is that websockets use their own ws:// websocket protocol while SSEs use the HTTP protocol. Also, SSEs can only transmit data in text/event-stream format.

Sending Events From Server

In a basic nodejs (express) server, you can define an endpoint to allow subscriptions from clients, and store them in a unique Set.

const clients = new Set(); // [!code highlight]

const addSubscription = (client) => {
    clients.add(client);
    console.log(`Client ${client} connected`);
}

const removeSubscription = (client) => {
    clients.delete(client);
    console.log(`Client ${client} disconnected`);
}

app.get("/subscribe", (req, res) => {
    const client = new URLSearchParams(req.query).get("id") || crypto.randomUUID();

    addSubscription(client); // [!code highlight]

    // ...

    req.on('close', () => {
        removeSubscription(client); // [!code highlight]
    })
})

Once a subscription is added and stored in the Set, you must set these response headers with a status code of 200 to let the client know that this is a text/event-stream, keep-alive connection.

app.get("/subscribe", (req, res) => {
    const client = new URLSearchParams(req.query).get("id") || crypto.randomUUID();

    addSubscription(client);

    res.writeHead(200, { // [!code highlight:5]
        "Content-Type": "text/event-stream",
        "Connection": "keep-alive",
        "Cache-Control": "no-cache"
    });

    req.on('close', () => {
        removeSubscription(client);
    })
})

Now that the connection is set, you can send messages to the client in the EventStream format. That's it, you can now listen to these event streams using the EventSource API which I will talk about more later in this post.

app.get("/subscribe", (req, res) => {
    const client = new URLSearchParams(req.query).get("id") || crypto.randomUUID();

    addSubscription(client);

    res.writeHead(200, {
        "Content-Type": "text/event-stream",
        "Connection": "keep-alive",
        "Cache-Control": "no-cache"
    });

    res.write(`data: ${message}\n\n`); // [!code highlight]

    req.on('close', () => {
        removeSubscription(client);
    })
})

You can also ping the client at regular intervals by using setInterval.

setInterval(() => res.write(`data: ping\n\n`), 5000);

This is all good but what if you want to send messages when something happens, either in the server or in the database. For that, you need to use event emitters in nodejs to fire a specific event and capture that event in our request handler to send a message to the client.

Event Emitters

Event emitters are a type of the pub/sub architecture wherein you have subscribers subscribing to specific "named" events and emitters (publishers) which publish/emit the event based on some operation.

Here's a simple example of an event emitter in nodejs:

import { EventEmitter } from 'events';

class UpdateEvents extends EventEmitter {
    constructor () {
        super();
    }

    new (data) {
        this.emit('new', data);
    }
}

const updates = new UpdateEvents();

export default {
    updates,
    newUpdate: (data) => updates.new(data)
}

The new method in the UpdateEvents class is an event emitter method which emits the named event new. This is what fires the event. Then, we create an instance of the UpdateEvents class and export it for it to be used for listening to the new event. You can listen to the event anywhere in your application code using:

updates.on('new', (data) => {
    // do something with the data
})

This is really useful for your SSE endpoint. For example, if you want to send events from an operation/event in some other part of the application and not necessarily inside the request handler, then you can fire an event from different places in your code and listen to it in the SSE endpoint.

// in some other part of the application
newUpdate({ message: "Hello World" }) // [!code highlight]

// ----------------------------------

// in the SSE endpoint
app.get("/subscribe", (req, res) => {
    const client = new URLSearchParams(req.query).get("id") || crypto.randomUUID();

    addSubscription(client);

    res.writeHead(200, {
        "Content-Type": "text/event-stream",
        "Connection": "keep-alive",
        "Cache-Control": "no-cache"
    })

    updates.on('new', (data) => { // [!code highlight:3]
        res.write(`data: ${message}\n\n`);
    })

    req.on('close', () => {
        removeSubscription(client);
    })
})

Subscribing to SSE Events From Clients

SSE Events are captured using the EventSource web API. You just have to pass the URL of the SSE endpoint to the EventSource API. You can't pass your own custom headers in the EventSource, so you have to rely on query parameters to pass additional context about the client.

const url = new URL(SSE_ENDPOINT, YOUR_API_BASE_URL)
const event = new EventSource(`${url.href}?id=${crypto.randomUUID()}`)

CAUTION: The EventSource API doesn't allow you to pass custom headers natively. You have to rely on polyfills or query parameters to pass additional context about the client. Learn more about the limitations of the EventSource API here.

Then, listen to the messages which are sent by the server by using the onmessage event.

const url = new URL(SSE_ENDPOINT, YOUR_API_BASE_URL)
const event = new EventSource(`${url.href}?id=${crypto.randomUUID()}`)

event.onmessage = (e) => { // [!code highlight:3]
    console.log(e.data);
}

event.onopen = (e) => {
    console.log('connection opened');
}

event.onerror = (e) => {
    console.log(e);
}

What happens when the connection to the server is lost? In that case, the browser tries to reconnect automatically within a certain interval of time known as the retry interval. The default retry interval is ~3 seconds in the browser. However, you can specify your own retry interval by sending the value (in milliseconds) in a retry field with the server sent message.

// server
res.write(`data: ${message}\n`);
res.write(`retry: ${retryInterval}\n\n`); // in milliseconds

Know how to properly send messages using the EventStream format in this article by web.dev.

If you don't want to rely on the automatic reconnect provided by the browser or if it's not working for you, you can implement you custom retry mechanism yourself. Let me show you how.

let retryInterval = 6000;

function listenToEvents(retryAfter) {
    let isListening = false;

    const interval = setInterval(() => {
        if (!isListening) {
            isListening = true;

            const url = new URL(SSE_ENDPOINT, YOUR_API_BASE_URL);
            const event = new EventSource(`${url.href}?id=${crypto.randomUUID()}`);

            event.onmessage = (e) => {
                const payload = JSON.parse(e.data);
                // do something with the payload
                payload.retry && (retryInterval = payload.retry); // [!code highlight]
            }

            event.onerror = (e) => {
                clearInterval(interval);
                event.close();
                listenToEvents(retryInterval);
            }
        }
    }, retryAfter);
}

listenToEvents(1000); // initially, establish the connection in 1 second

First of all, you have to setup an interval which will keep checking if the connection is still alive or not. And the interval can be set to a custom value, or to the retry value you get from the server. This interval will be wrapped in a function named listenToEvents which will accept a retryInterval parameter and initialize a local variable named isListening.

This interval will keep creating new eventsource objects if the isListening variable is false. It's set to false by default but, it's set to true when establishing the connection, so only one eventsource object will be created at the first round of the interval.

If the connection is lost, the onerror event will be fired closing the event, clearing the current interval and invoking the function listenToEvents recursively.

Conclusion

In this guide, you got to know about server sent events, event emitters and the EventSource API. Server Sent Events are almost similar to websockets with some key differences. If you want to learn more about websockets, check out the WebSockets 101 guide.

3 Steps To Think Like A Software Developer

Murtuzaali Surti — Mon, 06 Jan 2025 17:22:22 +0000

If someone were to ask me, what does a software engineer do on a basic level and what makes a good software engineer? I would say, problem solving. Yes, it’s the most basic and the most important skill to have as a software developer/engineer, yet most people don’t think about it before getting into software.

But, it’s not that hard. In this post, I will list down three steps to better approach the problem given at hand, find the solution, and then improve upon it. It will also help you achieve a developer mindset.

1. Break it down

The first step to understand what’s going on is to understand it on a granular level. Given a complex problem, try to dissect it into smaller parts which are meaningful on their own, yet when put together, give you the final bigger picture.

Think of it like the component architecture where everything is broken down into pieces which function on their own but also serves a higher purpose.

2. Find a solution that just works

You don’t have to nail the perfect solution every time on the very first try. No. To be honest, if that happens to you, then you are not learning anything new and there’s no growth. Instead, find a solution that gets the work done even if it’s naive and inefficient.

By doing so, you at least get a working prototype which you can test and iterate upon.

Prepare for coding interviews on GreatFrontEnd - a platform on which the interview resources are prepared by engineers from world's largest tech companies and core maintainers of open source projects.

3. Refactor and Iterate

For me, this is the most interesting and challenging part where you have already figured out the solution, but now you are looking for edge cases, performance improvements, potential bugs and implementation details in your solution.

This is your chance to improve the solution according to your business needs along with maintaining best coding practices. Also, it gives you more depth to add to the documentation - you can add different approaches you took to arrive at the final solution, their advantages as well as shortcomings and much more.

Refactoring: Improving the Design of Existing Code by Martin Fowler is a must read if you are struggling with refactoring existing/legacy code.

Conclusion

This is what I learned in my experience as a software engineer up until now and I like to keep experimenting with this flow. If you have some more thoughts to share, let me know and I will add it here.

Better - An AI powered Code Reviewer GitHub Action

Murtuzaali Surti — Sat, 28 Sep 2024 09:44:19 +0000

Code reviews have always been crucial in maintaining a standard and emphasizing on the best practices of code in a project. This is not a post about how developers should review the code, it's more about delegating a part of it to AI.

As Michael Lynch mentions in his post - "How to Do Code Reviews Like a Human" - we should let computers take care of the boring parts of the code review. While Michael emphasizes on a formatting tool, I would like to take it a step further and let artificial intelligence figure it out. I mean, why not take the advantage of the AI boom in the industry?

Now I am not saying that AI should be used in place of formatting tools and linters. Instead, it is to be used on top of that, to catch trivial stuff which might be missed by a human.

That's why I decided to create a github action which code reviews a pull request diff and generates suggestions using AI. Let me walk you through it.

🚨 Note

This GitHub action is now available at the GitHub marketplace.

It's a javascript action - learn more about creating javascript github actions.

Getting the diff

To interact with the github API, I have used octokit, which is kind of an SDK or a client library for interacting with the github API in an idiomatic way.

In order for you to get the diff of the pull request raised, you need to pass the Accept header with the value application/vnd.github.diff along with the required parameters.

async function getPullRequestDetails(octokit, { mode }) {
    let AcceptFormat = "application/vnd.github.raw+json";

    if (mode === "diff") AcceptFormat = "application/vnd.github.diff";
    if (mode === "json") AcceptFormat = "application/vnd.github.raw+json";

    return await octokit.rest.pulls.get({
        owner: github.context.repo.owner,
        repo: github.context.repo.repo,
        pull_number: github.context.payload.pull_request.number,
        headers: {
            accept: AcceptFormat,
        },
    });
}

If you are not familiar with github actions at all, here's a github actions 101 series by Victoria Lo and it's a good start.

Once I get the diff, I parse it and remove unwanted changes, and then return it in a schema shown below:

/** using zod */
schema = z.object({
    path: z.string(),
    position: z.number(),
    line: z.number(),
    change: z.object({
        type: z.string(),
        add: z.boolean(),
        ln: z.number(),
        content: z.string(),
        relativePosition: z.number(),
    }),
    previously: z.string().optional(),
    suggestions: z.string().optional(),
})

Ignoring Files

Ignoring files is quite straightforward. The user input list requires a semicolon separated string of glob patterns. It's then parsed, concatenated with the default list of ignored files and de-duped.

**/*.md; **/*.env; **/*.lock;

const filesToIgnoreList = [
    ...new Set(
        filesToIgnore
            .split(";")
            .map(file => file.trim())
            .filter(file => file !== "")
            .concat(FILES_IGNORED_BY_DEFAULT)
    ),
];

The ignored files list is then used to remove the diff changes which refer to those ignored files. That gives you a raw payload containing only the changes you want.

Generating suggestions

Once I get the raw payload after parsing the diff, I pass it to the platform API. Here's an implementation of the OpenAI API.

async function useOpenAI({ rawComments, openAI, rules, modelName, pullRequestContext }) {
    const result = await openAI.beta.chat.completions.parse({
        model: getModelName(modelName, "openai"),
        messages: [
            {
                role: "system",
                content: COMMON_SYSTEM_PROMPT,
            },
            {
                role: "user",
                content: getUserPrompt(rules, rawComments, pullRequestContext),
            },
        ],
        response_format: zodResponseFormat(diffPayloadSchema, "json_diff_response"),
    });

    const { message } = result.choices[0];

    if (message.refusal) {
        throw new Error(`the model refused to generate suggestions - ${message.refusal}`);
    }

    return message.parsed;
}

You might notice the use of response format in the API implementation. This is a feature provided by many LLM platforms, which allows you to tell the model to generate the response in a specific schema/format. It is especially helpful in this case as I don't want the model to hallucinate and generate suggestions for incorrect files or positions in the pull request, or add new properties to the response payload.

The system prompt is there to give the model more context on how it should do the code review and what are some things to keep in mind. You can view the system prompt here github.com/murtuzaalisurti/better.

The user prompt contains the actual diff, the rules and the context of the pull request. It is what kicks off the code review.

This github action supports both OpenAI and Anthropic models. Here's how it implements the Anthropic API:

async function useAnthropic({ rawComments, anthropic, rules, modelName, pullRequestContext }) {
    const { definitions } = zodToJsonSchema(diffPayloadSchema, "diffPayloadSchema");
    const result = await anthropic.messages.create({
        max_tokens: 8192,
        model: getModelName(modelName, "anthropic"),
        system: COMMON_SYSTEM_PROMPT,
        tools: [
            {
                name: "structuredOutput",
                description: "Structured Output",
                input_schema: definitions["diffPayloadSchema"],
            },
        ],
        tool_choice: {
            type: "tool",
            name: "structuredOutput",
        },
        messages: [
            {
                role: "user",
                content: getUserPrompt(rules, rawComments, pullRequestContext),
            },
        ],
    });

    let parsed = null;
    for (const block of result.content) {
        if (block.type === "tool_use") {
            parsed = block.input;
            break;
        }
    }

    return parsed;
}

Adding Comments

Finally, after retrieving the suggestions, I sanitize them and pass them to the github API to add comments as a part of the review.

I chose the below way to add comments because by creating a new review, you can add all comments in one go instead of adding a single comment at a time. Adding comments one by one may also trigger rate limiting because adding comments triggers notifications and you don't want to spam users with notifications.

function filterPositionsNotPresentInRawPayload(rawComments, comments) {
    return comments.filter(comment =>
        rawComments.some(rawComment => rawComment.path === comment.path && rawComment.line === comment.line)
    );
}

async function addReviewComments(suggestions, octokit, rawComments, modelName) {
    const { info } = log({ withTimestamp: true }); // eslint-disable-line no-use-before-define
    const comments = filterPositionsNotPresentInRawPayload(rawComments, extractComments().comments(suggestions));

    try {
        await octokit.rest.pulls.createReview({
            owner: github.context.repo.owner,
            repo: github.context.repo.repo,
            pull_number: github.context.payload.pull_request.number,
            body: `Code Review by ${modelName}`,
            event: "COMMENT",
            comments,
        });
    } catch (error) {
        info(`Failed to add review comments: ${JSON.stringify(comments, null, 2)}`);
        throw error;
    }
}

Conclusion

I wanted to keep the github action open-ended and open to integrations and that's why you can use any model of your choice (see the list of supported models), or you can fine tune and build your own custom model on top of the supported base models and use it with this github action.

If you encounter any token issues or rate limiting, you might want to upgrade your model limits by referring to the respective platform's documentation.

So, what are you waiting for? If you have repository on github, try the action now - it's on the github action marketplace.

murtuzaalisurti / better

A code reviewer github action powered by AI, ready to be used in your workflow.

better

A code reviewer github action powered by AI, ready to be used in your workflow.

Why use it?

Standardize your code review process
Get feedback faster
Recognize patterns which result in bad code
Detection of common issues
Identify security vulnerabilities
Second opinion
For humans to focus on more complex tasks

Usage

1. Create a workflow

Create a workflow file inside .github/workflows folder (create if it doesn't exist) of your repository with the following content:

name: Code Review
on
    pull_request:
        types: [opened, reopened, synchronize, ready_for_review]
        branches:
            - main # change this to your target branch
    workflow_dispatch: # Allows you to run the workflow manually from the Actions tab

permissions: # necessary permissions
    pull-requests: write
    contents: read

jobs:
    your-job-name:
        runs-on: ubuntu-latest
        name: your-job-name
        steps:
            - name: step-name
              id: step-id
              uses: murtuzaalisurti/better@v3 # this is

…

View on GitHub

Create a Node Server using Hono

Murtuzaali Surti — Thu, 04 Jul 2024 16:44:02 +0000

Hono, as per the docs, was originally built for Cloudflare Workers. It's an application framework designed to work the best for cloudflare pages and workers as well as javascript runtimes Deno and Bun. Although not built specifically for Node, an adapter can be used to run it in Node.

In this tutorial, you will get to know how you can create a simple HTTP server in Node using Hono in less than 10 lines of code.

Prerequisites

Create a bare bones node environment using npm init -y.

Setting Up Hono

Install hono from npm along with its nodejs adapter.

npm i hono @hono/node-server

Creating A Server

Create a file named index.mjs and then, import Hono and its nodejs adapter.

import { Hono } from "hono"
import { serve } from "@hono/node-server"

Initialize a new Hono app.

const app = new Hono()

Handle a simple GET route.

app.get("/", (context) => context.json({ "hello": "world" }))

Serve the app using the nodejs adapter.

serve({ port: 3000, fetch: app.fetch }, (i) => console.log(`listening on port ${i.port}...`))

Here's a snippet of all the code combined:

import { Hono } from "hono"
import { serve } from "@hono/node-server"

const app = new Hono()

app.get("/", (context) => context.json({ "hello": "world" }))

serve({ port: 3000, fetch: app.fetch }, (i) => console.log(`listening on port ${i.port}...`))

Conclusion

One highlight of Hono is its Regexp router. It allows you to define routes which match a regex pattern. Apart from that, it also offers multiple built-in authentication modules for implementing various authentication methods such as basic, bearer, and jwt.

syntackle.live is now syntackle.com

Murtuzaali Surti — Wed, 31 Jan 2024 15:31:13 +0000

Recently, I moved my blog syntackle to a new domain from syntackle.live. I feel that .com as a domain is a better choice. What are your thoughts on this? Is it a good decision?

Web Components & Custom Elements

Murtuzaali Surti — Mon, 01 Jan 2024 07:04:31 +0000

Those familiar with React or any other javascript framework, are already aware of the component based architecture. You break the UI into re-usable pieces of code and stitch them together when required.

Custom elements in HTML are a way to extend native HTML elements. Javascript frameworks simulate the behavior of components in a web page whereas custom elements provide a native HTML-ly way to do so. A web component uses custom elements along with other techniques such as the shadow DOM.

Types Of Custom Elements

Autonomous custom elements
Customized built-in elements

Autonomous custom elements extend the generic HTMLElement class. On the other hand, a customized custom element extends a specific HTML elements' class and builds on top of existing functionality. For example, if you want a custom anchor element, you can extend the HTMLAnchorElement.

Defining Custom Elements

To define a custom element, we need to create a javascript class extending the native HTMLElement class. Try creating the below custom element in a codepen:

class Demo extends HTMLElement {
  constructor() {
    super()
  }

  connectedCallback() {
    this.textContent = "hello"
  }
}

customElements.define("demo", Demo)

And then invoking it in HTML:

<demo></demo>

It won't let you create it. Why? See the error.

Uncaught SyntaxError: Failed to execute 'define' on 'CustomElementRegistry': "demo" is not a valid custom element name

This is not a bug, this is intentionally done to separate custom elements from native HTML elements. Custom elements must contain a hyphen in their name to make custom elements recognizable and distinct from HTML elements.

So now, if you change it to something like demo-webc and change the class name to DemoWebC, it works.

class DemoWebC extends HTMLElement {
  constructor() {
    super()
    this.customProperty = "custom"
  }

  connectedCallback() {
    this.textContent = "hello"
  }
}

// two arguments: tag name, class name
customElements.define("demo-webc", DemoWebC)

It always recommended to call the super() method first in the constructor as it initializes default properties of the HTMLElement class by invoking its constructor.

The connectedCallback() method is for detecting when the element is loaded into the page. There's also a method named disconnectedCallback() which detects if the element is removed from the page. A third method name adoptedCallback() says that the element has moved to a new page.

You can define custom properties inside the constructor and use them as custom attributes in your element.

constructor() {
    super()
    this.customProperty = {
        name: "data-custom",
        value: "custom value"
    }

    connectedCallback() {
        this.textContent = "hello"
        this.setAttribute(this.customAttribute.name, this.customAttribute.value)
    }
}

But what if you need to modify the functionality on attribute's value change? That's where attributeChangedCallback() method comes into action. In order to see it in action, you need to first define a static observedAttributes class property and set it to an array of all the attributes you want to keep track of.

The attributeChangedCallback() fires if those attributes mentioned in the static observedAttributes property change. Note that if the attribute is already present when the custom element loads, this method is fired at that time too.

static observedAttributes = ["data-custom"]

constructor() {
    super()
}

attributeChangedCallback(name, old, newValue) {
    console.log(name, old, newValue)
}

Once you are done with building a custom element, you must register it by using the define() method. It's callable on the customElements global object (window.customElements) which is a registry of custom elements.

customElements.define("custom-element-name", ClassName, options)

This was all for defining a customized autonomous custom element. What about extending only an anchor HTML element?

For that, instead of extending the HTMLElement class, extend the HTMLAnchorElement class. And specify which type of HTML element it extends with the extends option.

class DemoAnchor extends HTMLAnchorElement {
  constructor() {
    super()
  }

  connectedCallback() {
    this.textContent = "syntackle.live"
    this.href = "https://syntackle.live"
  }
}

customElements.define("demo-anchor", DemoAnchor, { extends: "a" })

You can't use this element like <demo-anchor> because it's not an autonomous element, instead you can use it like this:

<a is="demo-anchor"></a>

Web Components

Web components are more than just custom elements. They sometimes also involve a shadow DOM. A "shadow" DOM, as the name suggests, is a sub-DOM tree for HTML elements. It is mainly used for encapsulation and restricting styles up to the web component only.

Shadow DOM

To create a shadow DOM, attach it to a host, in our case the custom element itself is a host to the shadow DOM. However, the shadow DOM can only be attached to a custom element or these built-in elements mentioned in the HTML spec.

You can access elements outside the shadow DOM from inside the shadow DOM.

class DemoWebC extends HTMLElement {
  constructor() {
    super()
  }

  connectedCallback() {
    const shadow = this.attachShadow({mode: "open"})

    const style = document.createElement("style")
    style.textContent = `p { color: blue; }`
    shadow.appendChild(style)

    const text = document.createElement("p")
    text.textContent = "hello"
    shadow.appendChild(text)
  }
}

customElements.define("demo-webc", DemoWebC)

Shadow DOM has two modes: open and closed. Open means external elements in the page can modify the contents of the shadow DOM by using shadowRoot property. In the closed mode, the shadow DOM is not accessible from outside using the shadowRoot property as it is null in this case.

Try doing this on a closed shadow DOM custom element:

console.log(document.querySelector("demo-webc").shadowRoot)

It returns null.

Templates and slots are extremely useful when building complex custom elements or web components. Diving deep into them is out of the scope of this article, but here are some good resources for them:

Using templates and slots - Web APIs | MDN

Shadow DOM slots, composition

Working with Slots and Web Components

Styling Shadow DOM

The shadow DOM can be styled either by:

Constructing a CSSStyleSheet object, inserting CSS in it using replaceSync() and attaching it to the shadow DOM using the adoptedStyleSheets property.

const shadowDOM = this.attachShadow({mode: "open"})
const styleSheet = new CSSStyleSheet()
styleSheet.replaceSync(`p { color: blue; }`)
shadowDOM.adoptedStyleSheets = [styleSheet]

Declaring styles using a <template>.

<template id="custom">
    <head>
        <style>p { color: blue; }</style>
    </head>
    <p>Web Component</p>
</template>

const shadowDOM = this.attachShadow({ mode: "open" })
const template = document.querySelector("#custom")
shadowDOM.appendChild(template.content.cloneNode(true))

Simply creating a style tag and inserting CSS as text in it.

const style = document.createElement("style")
style.textContent = `p { color: blue; }`
shadow.appendChild(style)

Creating Your Own Web Component

The first web component shown below is a custom button element which opens a dialog element. And the second web component involves a shadow DOM to pretty print JSON string in HTML.

Similarly, you can create your own custom elements and use them anywhere you want.