Forem: Ahmed Ehab

Building and Installing VS Code Extensions in Cursor

Ahmed Ehab — Tue, 17 Feb 2026 21:11:59 +0000

While working with Cursor, I discovered a serious limitation to what Cursor can do.

Cursor allows the installation of VS Code extensions, but not every extension in VS Code is available directly within Cursor's marketplace.
This is mainly because Cursor was separated from VS Code some time ago, which created compatibility issues with certain extensions.

Since it was not easily accessible or compatible through standard installation methods, I looked into building the extension from source and installing it manually.

I faced this problem while trying to install the pgFormatter extension. Which I will use as an example.

Why does this happen?

Cursor is built on the VS Code source code, and subsequently, its extension ecosystem. So, that means it supports the same extension packaging format.

However, the reality is some extensions:

Are not listed in Cursor's marketplace
Depend on APIs or versions that differ from Cursor

What is VSIX?

VS Code extensions usually are compiled and built as .vsix files. A VSIX file is a packaged bundle that includes:

Compiled extension code.
Metadata and dependency information.

Building an Extension from Source

The first step is obtaining the extension source code. In this example, the goal was to build the pgFormatter extension locally.

After downloading the extension source (mostly it will be on GitHub), the directory structure looked like this:

package.json
src/
tsconfig.json
vsc-extension-quickstart.md

Step 1: Install Dependencies

Go to the extension directory and install the required dependencies by running this command:

npm install

Step 2: Package the Extension

Once the installation finishes, package the extension into a VSIX file using the VS Code Extension CLI tool.
Run the following command to do this:

npx vsce package

If the process completes successfully, it produces a .vsix file similar to: pgformatter-1.33.0.vsix

Step 3: Installing in Cursor

After generating the VSIX file, the extension can be installed easily into Cursor as follows.

Command Palette Installation:

Open Cursor
Open the Command Palette:
- macOS: Cmd + Shift + P
- Windows/Linux: Ctrl + Shift + P
Run: Extensions: Install from VSIX...
Select the generated .vsix file
(Optional) If the extension isn't active yet, you can reload Cursor by doing the following action: Developer: Reload Window

Practical Considerations

While this method works fine, there are a few things to keep in mind:

Security Considerations

Installing extensions from source means you are responsible for verifying the code being installed. Reviewing the repository and dependencies is really recommended.
I can't stress this enough, extensions with bad intentions and malicious code can seriously harm or compromise your code base or your system or your users.

Maintenance

Manually installed extensions do not automatically update. Doing this process again will be necessary when new versions are released.

Conclusion

Cursor uses the same extension packaging model as VS Code, which means developers can manually compile and install extensions when they can't access the marketplace directly.

By generating a VSIX file from the extension, and then installing it manually, we can keep using important extensions like pgFormatter without getting stuck due to differences in the ecosystem.

Sync all of your LeetCode solutions to Github using glsync

Ahmed Ehab — Tue, 18 Feb 2025 00:20:24 +0000

Hey all,

I developed glsync, a CLI tool to sync all your LeetCode submissions to Github (and possibly any other Git client). Each solution will be committed based on its submission date on LeetCode.

You can create a custom repo on GitHub, and glsync will get all of your submissions from LeetCode and push it into this custom repo. It can also work with Gitlab and other Git repos.

I found a lack of similar tools that sync ALL of your submissions, not one at a time.

You can view and download it here: https://github.com/ahmed-e-abdulaziz/glsync

I created it because companies judge interviewees by how frequently they commit to Github. This can make time spent in LeetCode feel invisible to them, as it won't be visible on your GitHub profile.

I did this in about a week, so if you want more features, support other platforms, or encounter bugs, feel free to send me a message.

HTTP Idempotency

Ahmed Ehab — Sun, 02 Jan 2022 18:20:50 +0000

Idempotency?

Have you accidentally clicked the order button twice on any e-commerce and still ordered a single order? Well, you have idempotency to thank for that (And the developer who implemented it 👨‍💻)!
So what is Idempotency? Although it looks like a complex term, it is a simple concept.

Insanity is doing the same thing over and over and expecting different results. - 'Albert Einstein'

Client-Server Idempotency

For HTTP API design, you won't run the same operation twice when an idempotent API is called twice with the same data. So if the client/frontend calls a PUT API twice to update a user's data, the server/backend would recognize it is the same request and update the data only once.

Why would I need it?

The reason a client would call the server twice might mostly not be because a user clicked a button two times. It is attributed more to network failures. For example, if an acknowledgment response for the update is NOT returned because of a network failure, the client might automatically send the same request again. From its point of view, the update request itself has yet to arrive at the server.

Safe vs. Idempotent

Another classification of HTTP methods to consider is safe methods.
Safe methods do not change any resource on the server, i.e., queries.

The difference is that idempotency concerns that we can call the same response many times and get the same answer.
While safe methods are concerned with keeping the same state of the resources on the servers with the first or the hundredth response as it treats resources in a read-only fashion.

Idempotent, Safe and non-idempotent HTTP Method

In the following table, we can see where each commonly-used HTTP methods fall in the previous categorization.

Method	Safe	Idempotent
`GET`	Yes	Yes
`HEAD`	Yes	Yes
`OPTIONS`	Yes	Yes
`TRACE`	Yes	Yes
`PUT`	No	Yes
`DELETE`	No	Yes
`POST`	No	No
`PATCH`	No	No

This shows that the real difference between Safe and Idempotent concepts is evident when we look at the behavior of the PUT and DELETE methods.

The DELETE method is not safe as it changes the resource/server state by deletion. However, it is idempotent because if we call DELETE on /user/1, for example, to delete a user with an ID of 1, the server shouldn't go and delete the user with an ID of 2 if it doesn't find it. It will reply with 200/204 as well since although it didn't find it, it's still not a fault to call it twice, as we have seen earlier.

The PUT method follows the same idea, it replaces a whole object with another entire object or adds a new one, so it will reply with the same response each time, but each time it's doing an update query on the server.

How will this matter to me/my team?

From a backend/server-side perspective, you have to respect the HTTP method and use them correctly according to its semantic meaning. Thus, a GET method, for example, must not change a state as it is safe and must not change the response type it returns as it is idempotent.

From a frontend/client-side perspective, you can call any idempotent endpoint many times with no fear of misbehavior, given your backend team is following the HTTP specs and semantics correctly.

Richardson Maturity Model

Ahmed Ehab — Sun, 18 Apr 2021 13:54:11 +0000

Are you RESTful?

So, right now, everyone and their mother is creating REST APIs. However, are all REST APIs created as equals?
As I said in my rest fundamentals article, Roy Fielding, the creator of REST, is getting frustrated by the number of people calling any HTTP-based interface a REST API.
Even so, a black-or-white scale for whether an API is RESTful can be misleading. Thus, Leonard Richardson designed a way to define how much an API conforms to the RESTful standards, creating the Richardson Maturity Model or RMM.

RMM

RMM aims to describe a specific grade for how much an API conforms to the RESTful standards. Maturity here means conformity to RESTful standards. It has four levels of maturity levels from level 0 to level 3.

The great thing is that it doesn't shun away any API that is not fully RESTful. It has some specific measurements that will allow engineers to quickly assess how scalable their endpoints are according to the RESTful standards and what can be improved to reach a higher level.

Level 0 (Swamp of POX)

In this level, a single URI can serve multiple resources and actions, and HTTP verb usage is incorrect (mostly only POST).

For example, you can have a URI that looks like this /usersManagement, which will serve to query, update, delete and create users using only the POST HTTP verb. To differentiate between the various obscure actions that the endpoint can do at this level, the body of the request will have to have the specific requirements of the request.

This level is not considered RESTful by RMM and mainly exists in the SOAP Web Services world. That's why it's called the Swamp of POX, as POX means Plain Old XML, and the level of coupling and obscurity of the endpoints in this level led to it being called a Swamp.

I have experienced integrating with SOAP services, and let me tell you that this level is awful and leads to a lot of confusion and mistakes.

Level 1 (Resources)

At level 1, we will use different URIs for different resources but still only use one HTTP verb (generally POST as well), leading to better decoupling in the API.

So using the previous example, instead of having one /usersManagement endpoint, we will have /usersCreate, /usersUpdate, /usersDelete, and /usersQuery while using only POST HTTP verb for all of them. We won't be using the body to define the action, though.

Although, level 1 is much better than the previous level. It still isn't considered RESTful enough by RMM. At the start of my career, I worked on a project with an API that would primarily reside at this level, and it was extremely cumbersome to keep creating and integrating with APIs like this. Furthermore, the whole suffix I used in this example needs to be standardized. It was basically whatever the developer would think was correct, which would differ wildly per developer.

For example, someone would query users with /usersQuery. Still, for address querying, the endpoint would be /addressRetrieval, and someone else would retrieve departments using /getDepartments, leading to a highly fragmented API.

Level 2 (HTTP Verbs)

Here we are at a level that is considered RESTful by a lot of RMM advocates. However, Roy Fielding believes it needs to be RESTful more. In my opinion, this level is RESTful and can provide the requirements of a RESTful API.

Anyway, now we will put HTTP verbs to actual use. Let's use the previous example. Now the users will have the following endpoint /users. Then to retrieve users, we will create a request with a GET HTTP verb to the users' endpoint. We will use the DELETE HTTP verb to delete a user in the request to indicate the action. To update, you can use PUT or PATCH. We can use GET, POST, PUT, DELETE, and more for other endpoints like that address or department.

The majority of Web APIs never pass this level. Mainly, that's okay; this level can provide almost all RESTful requirements. It only needs a self-descriptive API. The API dev delivers the client documentation beforehand. Thus, it will also require documentation to define the necessary endpoints for various actions on the retrieved entity.

Level 3 (HATEOAS)

Finally, we arrive at the last level here. The HATEOAS principles reside here.
When we get the users from the /users endpoint with the GET HTTP verb, the response for getting a user will look like the following:

[
  {
    "id": 1,
    "name": "Ahmed Ehab Abdulaziz",
    "email": "ahmed.ehab5010@gmail.com",
    "links": {
      "self": {
        "href": "https://ahmedehab.com/user/1"
      },
      "update": {
        "href": "https://ahmedehab.com/user/1"
      },
      "delete": {
        "href": "https://ahmedehab.com/user/1"
      },
      "report": {
        "href": "https://ahmedehab.com/user/1/report/default"
      },
      "tax-report": {
        "href": "https://ahmedehab.com/user/1/report/tax"
      }
    }
  }
]

As you can see, we don't need the update, delete, report, or tax-report actions to be hard coded in our code.
When we get the users array, we will get the API to do the various actions with the endpoint per user through the response as in the example.

I want to go over HATEOAS sparingly, as it deserves its article. You can find more about it in my article here. Lastly, everyone considers this level RESTful, including Roy Fielding, who regards it as a prerequisite to having a RESTful API.

Which level should I develop for?

Levels 0 and 1 are still in use today, and many web applications are developed with levels 0 or 1. However, level 2 for greenfield web API today is considered acceptable. Whether calling it a RESTful API or not, it leads to a cleaner API and does not put overhead on the developers or the API architect.

As for level 3, you need to consider the users' bandwidth. Also, the primary purpose of HATEOAS is to deal with changes in the API efficiently. Changes have never been an issue for internal applications, and the new APIs are adapted to the old ones. The other way around is much harder for this type of project. Besides, many developers don't understand or even know what HATEOAS is. Some training might be required to onboard them.
However, for SaaS-based projects or other projects with an external API exposed to many different systems, HATEOAS and Level 3 can be of immense practicality. You can easily swap out old APIs with new APIs without having to change a line of code in the integrating services.

P.S. You should read the Roy Fielding article that mentions that REST APIs must be hypertext. The discussions there are fascinating. You can visit it from here.

WTF is HATEOAS?

Ahmed Ehab — Tue, 23 Feb 2021 14:37:42 +0000

Hypermedia As The Engine Of Application State or HATEOAS is a significant part of REST architecture to provide a Uniform Interface, which is one of the main fundamentals of REST. You can read more about REST fundamentals in my previous post. Here I will explain it and why it was created.

In a Perfect World

Let's say we have a system that needs to expose an API to manage the user entity. That API will do CRUD operations in addition to supporting generating a report of the user billing for the last month; thus, the following endpoints were created in the backend:

Get all users: GET https://ahmedehab.com/users/
Get a single user with an ID of 1: GET https://ahmedehab.com/users/1/
Create a new user: POST https://ahmedehab.com/users/ (Or PUT for idempotency, more on that in a later post)
Update a user: PUT https://ahmedehab.com/users/1/
DELETE a user: DELETE https://ahmedehab.com/users/1/
Retrieve a billing report for a user: GET https://ahmedehab.com/users/1/report

Now, in a perfect world, these endpoints are and will always be the go-to endpoints to manage a user. We will never need to make a new change here, or will we?

Imperfect World

Realistically, the backend endpoints will change over time for any large project. So for our example, a new architect was hired. He doesn't believe resources (i.e., users in the example) should be in the plural form in the URIs, so instead of /users/1/, we would have /user/1/ add to that the BA/PO is now requesting a new feature to generate a tax report. So we will have the following endpoints.

Get all users: GET https://ahmedehab.com/user/
Get a single user with an ID of 1: GET https://ahmedehab.com/user/1/
Update the user: PUT https://ahmedehab.com/user/1/
Delete the user: DELETE https://ahmedehab.com/user/1/
Get the default billing report for a user: GET https://ahmedehab.com/user/1/report/default
Get the tax report for a user: GET https://ahmedehab.com/user/1/report/tax

Now for the frontend part, this will be devastating if we roll this update without a coordinated deployment with the frontend to address this.
This means we are not reaping the benefit of REST endpoints which is the evolution of the server and the client independently of each other.

HATEOAS for the rescue

Now, HATEOAS was introduced to specifically mitigate this issue, the issue of ever-evolving backend APIs.

With HATEOAS, we can keep the front end running as is while quickly changing all these different APIs.
HATEOAS defines actions and their endpoints in the response of any entity. Thus we don't hardcode every API in the front end.

It is applied by adding a list of actions with their links to the entity so we can get the required link from the response to perform our action.
Initially, the response for GET /users/ to get a list of users would look like this (assuming we have a single user in the backend) with HATEOAS:

[
  {
    "id": 1,
    "name": "Ahmed Ehab Abdul-Aziz",
    "email": "ahmed.ehab5010@gmail.com",
    "links": {
      "self": {
        "href": "https://ahmedehab.com/users/1"
      },
      "update": {
        "href": "https://ahmedehab.com/users/1"
      },
      "delete": {
        "href": "https://ahmedehab.com/users/1"
      },
      "report": {
        "href": "https://ahmedehab.com/users/1/report"
      }
    }
  }
]

Now we can change the endpoints from /users/ to /user/ and add a new report like this:

[
  {
    "id": 1,
    "name": "Ahmed Ehab",
    "email": "ahmed.ehab5010@gmail.com",
    "links": {
      "self": {
        "href": "https://ahmedehab.com/user/1"
      },
      "update": {
        "href": "https://ahmedehab.com/user/1"
      },
      "delete": {
        "href": "https://ahmedehab.com/user/1"
      },
      "report": {
        "href": "https://ahmedehab.com/user/1/report/default"
      },
      "tax-report": {
        "href": "https://ahmedehab.com/user/1/report/tax"
      }
    }
  }
]

Another step we can do is to add the HTTP method used for each link to reduce coupling further. This is different from the REST standards, though.

{
  "self": {
    "href": "https://ahmedehab.com/users/1",
    "method": "GET"
  }
}

That can lead to, for example, changing the PUT for the update action to PATCH without breaking any changes. Nonetheless, that last step is not HATEOAS compliant.

The recommended way to do this is to keep the older structure where there is only "href" in action and send an OPTIONS request before sending the request to get the required HTTP method. Each way has its fans. Roy T. Fielding, the creator of REST was one of the creators of the OPTIONS request.

Some Architects even prefer to keep the HTTP method coupled as they see that the role of HATEOAS is to follow a standard to decouple the URIs since HATEOAS is part of having a Uniform Interface for REST. So we have to get back to the API documentation to recognize the HTTP verb.

Remember that HATEOAS is not a replacement for something like OpenAPI for API documentation.

Also, the verb should present the action it is doing. If I am retrieving a user, I will always use a GET whether I change the URI or not. You can find a lot of colliding opinions on the internet, like this link on StackOverflow

REST Fundamentals

Ahmed Ehab — Fri, 19 Feb 2021 16:47:36 +0000

REST has been a cornerstone of backend programming for quite a while now. However, many developers have a vague idea of what REST is or confuse it with HTTP. In this post, I will shed some light on what exactly constitutes REST and how it compares to HTTP.

Why use REST?

REST enforces a good separation of concerns between clients and servers. The more our REST endpoints are mature, the more we can evolve our client (frontend) or server (backend) with no issues with scalability or coupling.

What is REST?

REST: Stands for REpresentational State Transfer. Firstly defined in the year 2000. It is an architectural style that standardizes communication between web services and systems. To say we have REST web services, we must follow the REST standards (i.e., become RESTful).

REST became wildly popular as a replacement for SOAP protocols requiring a lengthier set of requirements. However, note that REST doesn't dictate the data transfer protocol. It focuses instead on the architecture of endpoints and how to name them. Thus, it's a software architecture/pattern, not a protocol. Nonetheless, HTTP is recommended as the go-to protocol to apply REST, but you can use it with other protocols like MQTT.

How to apply REST

This is the part of REST that, unfortunately, needs to be fully understood or followed, which leads to calling HTTP APIs REST APIs. However, REST is required to be followed correctly. Just check Roy T. Fielding article from 2008, where he rants about how he is getting frustrated by the number of people calling any HTTP-based interface a REST API.

I will go over each of the basic fundamentals in the following point that leads to an actual REST endpoint, not just a regular HTTP one.

Client and Server Separation

In REST, the client and server are separated, leading to less coupling between the client and server. Thus we gain flexibility and a stateless server.

Statelessness

REST advocates statelessness, meaning that the server doesn't keep the client's state. So the server doesn't keep track of the user's session. This leads to great scalability, as any new server instance is not required to keep track of old sessions.

Caching

If a request is following REST, the request must detail if it's cacheable or not. Applying caching to client and server requests leads to a significantly reduced number of requests. Or even the elimination of requests altogether over a while.

Layers

If a client is connecting to a server and a new layer is introduced (e.g., proxy/load balancer), this must not affect how the client or the server behaves. So we can add proxies, load balancers, firewalls, and more without affecting the system's behavior.

Uniform Interface

Having a uniform interface is a must in the REST architectural style. This enables each part (client/server) to change sides over time separately from each other. Four rules must be followed to have a uniform interface between clients and servers.

Resource identification in requests

Resources (endpoints) should be identified in the request. Such as using URIs. For example, the user resource should be stated in the HTTP URI that the users are what is required here, like this https://example.com/users/.

The resource for the server side is separate from the representations returned to the client. Many resources and entities represent this user endpoint in the backend. This is coupled away from the client/front end.
Resource manipulation through representations

When a client receives a resource (with headers and other metadata), it has enough information to modify or delete. So if the frontend retrieves users from https://example.com/users/, it can follow a simple structure to manipulate any user in the list without asking the backend how to request a type of this change.

In HTTP-based REST endpoints, this is achieved by HTTP verbs such as GET to retrieve, POST to create a new resource, PUT to create/update a complete resource, PATCH to modify a part of a resource, DELETE to delete a resource, and so on. This is accompanied by other data that can help in this, for example, returning each user ID.
Self-descriptive messages

The response message should describe itself with no requirement to go back to the backend to retrieve the message's meaning. For example, an attribute must be attached to explain the file type if a file is returned in a binary format. If the response is in JSON, an attribute must exist to explain it's in JSON.

In HTTP-based REST APIs, https://example.com/annual-report/, the response must have a media type header that explains that the returning blob is a pdf like this Content-Type: application/pdf.

Also, in HTTP, the response should have a status code that describes the state of this response, whether it's an error or a successful one, like response 200 (OK) or 400 (BAD REQUEST).
Hypermedia as the engine of application state (HATEOAS)

HATEOAS requires that when requesting a URI for a REST endpoint, the response should include links provided by the backend to discover all available resources in the response dynamically.

This leads to a decoupled client from the backend endpoints leading to more freedom in changing the backend structure and endpoints.

    {
      "id": 1,
      "name": "Ahmed Ehab",
      "email": "ahmed.ehab5010@gmail.com",
      "_links": {
          "self": {
              "href": "https://ahmedehab.com/users/1"
          },
          "report": {
              "href": "https://ahmedehab.com/users/1/report"
          }
      }
    }

HATEOES is a big topic; I might write a post discussing it precisely. To keep this post short, I won't be going into HATEOES.

Richardson Maturity Model

RMM is a maturity model described by Leonard Richardson in 2008. It tells how much an application adheres to REST specifications and puts it in one of four levels.This model is well suited to show us how much our endpoints conform to the REST architectural style, so it can state that our API is not a fully mature REST API, but partially a REST endpoint.