Forem: Rasool Khan

Why “Easy / Medium / Hard” Is a Terrible Way to Think About DSA

Rasool Khan — Fri, 06 Feb 2026 19:25:05 +0000

One of the most misleading things about DSA is the difficulty label.

Easy.
Medium.
Hard.

It looks useful. It feels objective.
But over time, I’ve found it does more harm than good especially when you’re actually trying to get better.

Difficulty feels random for a reason

If you’ve ever felt this, you’re not alone:

Some “easy” problems feel impossible
Some “hard” problems click instantly
You solve a medium one day, struggle with another the next

At first, it’s easy to blame yourself.
Maybe you’re inconsistent. Maybe you’re not good at DSA.

But the issue isn’t you.
It’s the label.

Difficulty isn’t about complexity

Most people assume difficulty means:

harder math
trickier code
more clever ideas

That’s rarely true.

In practice, difficulty mostly reflects how many patterns are involved, and how cleanly they’re combined.

From my experience:

Easy problems usually test one pattern
Medium problems combine one or two
Hard problems usually use two, occasionally three

Almost never more than that.

Once you see this, the labels start to lose their power.

Why “easy” problems can feel hard

An “easy” problem feels hard when:

you haven’t mastered that specific pattern yet
the problem hides the pattern behind a story
the invariant isn’t obvious immediately

It’s not easy because it’s trivial.
It’s easy because, once you recognize the pattern, the solution is straightforward.

Without that recognition, even easy problems feel painful.

Why “hard” problems sometimes feel easy

On the flip side, a hard problem can feel surprisingly manageable when:

you’ve seen the underlying patterns before
the combination makes sense to you
you can reason about the invariants independently

At that point, you’re not solving a “hard” problem.
You’re just coordinating familiar ideas.

The label doesn’t reflect your experience anymore your preparation does.

Difficulty is subjective, patterns aren’t

This is the part I wish someone told me earlier.

Difficulty labels are:

subjective
relative
influenced by popularity and platform heuristics

Patterns are:

stable
reusable
transferable across problems and companies

When you focus on patterns, your progress becomes measurable.
When you focus on difficulty, it feels noisy and inconsistent.

How I approach problems now

I don’t ask:

“Is this problem hard?”

I ask:

How many patterns does this involve?
Do I already understand them individually?
Are they interacting, or just sequential?

That framing turns something vague into something concrete.

A “hard” problem becomes:

“Two patterns I already know, combined slightly awkwardly.”

That’s a much less scary problem to work on.

Why this matters while learning

If you let difficulty labels drive your learning:

you avoid “hard” problems too early
you overvalue “easy” problems for too long
you tie progress to external tags instead of internal clarity

If you let patterns drive your learning:

you know exactly what you’re weak at
you know what to practice next
progress feels intentional, not accidental

That difference compounds over time.

This is also how interviews work

Interviewers don’t think in terms of “this is a hard problem.”

They think in terms of:

Which concepts does this test?
Can the candidate recognize structure?
Can they reason about constraints clearly?

Difficulty labels are for platforms.
Patterns are what interviews actually evaluate.

Where I’m going with this

This way of thinking patterns first, labels last, is what I’m trying to make explicit in my own learning and in what I’m building.

Once you stop fearing “hard” and start dissecting structure, DSA becomes a lot calmer.

Still challenging.
But no longer intimidating.

What’s coming next

In the next post, I want to write about why mastering arrays alone gets you much further than most people expect, and why arrays quietly sit underneath a huge chunk of DSA.

If difficulty labels have been messing with your confidence, try ignoring them for a while.

Focus on the patterns instead.

It changes everything.

I’ve been indexing patterns and the signals that point to them in one place indexedcode, mostly as a reference for myself. Writing about it here helps me refine that thinking.

How I Identify the Right DSA Pattern (Before Writing Any Code)

Rasool Khan — Mon, 02 Feb 2026 17:08:01 +0000

When people ask how to get better at DSA, the advice is usually some version of:

“Practice more problems.”

That’s not wrong.
It’s just incomplete.

What actually made the biggest difference for me was learning how to identify the pattern early often before I thought about code at all.

Once I got reasonably good at that, the rest of the problem usually unfolded on its own.

I don’t start with the problem statement

This might sound odd, but I don’t mentally engage with the whole story upfront.

Instead, I look for a few very specific signals:

What kind of input am I given?
What’s the constraint on time and space?
What exactly is the output asking for?

Those three things eliminate most options very quickly.

Constraints do most of the work

If I see:

“Sorted array”
“Find a pair/subarray”
“O(n) expected”

I’m already thinking two pointers or sliding window.

If the problem:

asks for ranges
mentions cumulative values
wants counts or sums over subarrays

My brain immediately goes to prefix sums and hashing.

If the input size is large and the answer space is monotonic, I’m thinking binary search often not over the array, but over the answer itself.

None of this feels clever anymore.
It feels mechanical.

And that’s a good thing.

Keywords matter, but not the way people think

People often memorize keyword → pattern mappings.

That helps initially, but it breaks down.

What I pay more attention to is what must stay true as I move through the input.

That’s usually the invariant.

For example:

Am I shrinking a search space?
Am I maintaining a valid window?
Am I accumulating something monotonically?
Am I eliminating options as I go?

Once I can articulate that in a sentence, the pattern usually becomes obvious.

The moment of clarity usually comes early

There’s a specific feeling I’ve learned to trust.

If, within the first couple of minutes, I can say:
“This feels like X pattern because Y must remain true”

Then I know I’m on the right track even if I don’t yet know all the edge cases.

If I can’t say that, I slow down.

That’s usually a sign I’m trying to brute-force my way into insight instead of stepping back.

This is why coding comes last for me now

Earlier, I used to jump into code quickly.

That often led to:

messy logic
backtracking
unclear explanations

Now, if I can’t explain the invariant in plain English, I don’t open the editor.

Once the pattern is clear:

the loop structure is obvious
pointer movement decisions make sense
complexity is almost self-evident

The code becomes an implementation detail, not the core work.

This is what I’m trying to capture

This way of thinking constraints first, invariant second, code last is what I’m slowly trying to document more systematically.

Not as rules.
Not as templates.

Just as a way to make DSA feel less random and more… structured.

I’ve been indexing patterns and the signals that point to them in one place (indexedcode.com), mostly as a reference for myself. Writing about it here helps me refine that thinking.

What I’ll write about next

In the next post, I want to dig into why difficulty labels (easy/medium/hard) are often misleading, and why they sometimes do more harm than good when you’re learning.

If pattern recognition feels fuzzy right now, that’s normal.
It sharpens with repetition the right kind of repetition.

And once it clicks, you’ll notice you’re solving problems differently than before.

Slower at first.
Much faster in the long run.

Most DSA Problems Are Repetitions

Rasool Khan — Sat, 31 Jan 2026 16:56:08 +0000

At some point while preparing for interviews, something odd happens.

You solve a problem, move on, then a few days later you see another one that feels… familiar. Different story, different variables but the same underlying logic.

At first, it feels like a coincidence. But, it isn’t.

The quiet realization

Most DSA problems aren’t truly new.

They’re variations.

Different constraints. Slight tweaks. New wording.
But underneath, the same few ideas keep coming back.

Two pointers.
Sliding windows.
Prefix sums.
Binary search.
A bit of hashing.

Once you notice that, it’s hard to unsee it.

Why this feels uncomfortable at first

A lot of us are taught to treat every problem as something unique.

Read carefully.
Start from scratch.
Try a few approaches.
Hope something clicks.

So when problems start repeating, it can feel like you’re “cheating” by reusing ideas like you’re not really learning.

That framing is what makes DSA feel harder than it needs to be.

This is how engineering actually works

In real systems, we don’t reinvent solutions either.

We recognize structure.
We reuse known approaches.
We adapt patterns to constraints.

DSA is no different.

Interview problems aren’t testing how original you are.
They’re testing whether you can:

recognize structure
choose the right abstraction
reason about trade-offs
explain why your approach works

Repetition isn’t a weakness of the system.
It’s the signal.

How difficulty really increases

This part took me a while to accept.

Difficulty usually doesn’t come from brand-new ideas.
It comes from combining familiar ones.

In practice:

Easy problems → one pattern
Medium problems → one or two patterns
Hard problems → usually two, occasionally three That’s it.

The jump from easy to medium isn’t about intelligence.
It’s about whether you can hold multiple constraints and invariants in your head at the same time.

Why grinding eventually stops helping

This is where a lot of people get stuck.

If you just keep solving problem after problem without pausing to extract the pattern:

you overfit to specific questions
you forget solutions quickly
the next variation still feels “new”

But if you stop and ask:

What pattern is this really testing?
What invariant is being maintained?
Which constraints force this approach? Then repetition becomes an advantage instead of a frustration.

You start recognizing problems earlier sometimes within the first minute.

That’s when DSA starts feeling manageable.

What helped me the most

The biggest shift for me was changing the question I asked myself.

Instead of:
“Can I solve this problem?”

I started asking:
“Which pattern is this trying to test?”

Once I could answer that, everything else followed more naturally:

the approach
the edge cases
the complexity
even the explanation

The code itself often became the least interesting part.

Why I’m leaning into this publicly

This idea that DSA is mostly structured repetition is what I’m building around right now.

Not as shortcuts.
Not as tricks.

But as a way to make the learning process feel less random and less intimidating.

I’ve been slowly documenting patterns, invariants, and ways to recognize them in one place (indexedcode.com), mostly as a reference I wish I’d had earlier.
This newsletter is where I think out loud as I do that.

What’s next

In the next post, I’ll write about how I identify the right pattern early, usually before thinking about code at all.

It’s not magic.
It’s mostly about constraints, keywords, and knowing what to ignore.

If DSA has been feeling repetitive lately, that’s probably a good sign.

You’re starting to see the structure.

[Boost]

Rasool Khan — Sat, 31 Jan 2026 16:47:51 +0000

Building in Public: How I Think About DSA (and Why I’m Sharing It)

Rasool Khan ・ Jan 30

#dsa #interview #faang

Building in Public: How I Think About DSA (and Why I’m Sharing It)

Rasool Khan — Fri, 30 Jan 2026 19:43:25 +0000

I want to build in public, write about how I think, and share what I’ve learned while actually using DSA not just preparing for it.

How my view on DSA changed

At some point, DSA stops being about problems.

You start noticing that:

The same ideas keep repeating
Most “hard” problems aren’t new, they’re combinations
The real difficulty is recognising what applies, not writing code

That shift didn’t happen because I solved hundreds of problems.
It happened when I stepped back and asked why the same patterns kept showing up.

Once you see that, DSA feels less like a grind and more like a set of mental models.

What I believe now

This is my current, very opinionated take:

You don’t need endless problem-solving
You need standalone mastery of patterns
Easy problems usually use one pattern
Medium problems combine one or two
Hard problems rarely go beyond that

If you can explain the invariant, you’re most of the way there

When I say “understand”, I don’t mean memorizing templates.
I mean being able to explain why a certain approach works and why others don’t.

What I’ll write about here

This won’t be about:

LeetCode dumps
Speed-running problem lists
“Crack X in Y days” content

Instead, I’ll write about:

How I recognise DSA patterns from constraints
Why certain patterns work (and when they don’t)
How difficulty in interviews is often misunderstood
How these same ideas show up in real systems
What I’m building, and rethinking, along the way

Think of this as engineering notes, written out loud.

Building in public

Alongside this, I’m building indexedcode, a pattern-first way to learn DSA.

Not a course.
Not a leaderboard.
Not a grind.

More like a reference I wish I had earlier, one that focuses on patterns, invariants, and decision-making.

I’ll share what I build, what I change, and what I get wrong.
If it helps someone else think more clearly, that’s a win.

Who this is for

This is probably for you if:

DSA feels harder than it should be
You’re preparing for interviews but tired of brute force
You care more about understanding than memorizing
You like slowing down and reasoning things through

If not, that’s okay too.

What’s next

I’ll start with things like:

Why most DSA problems are repetitions
How I identify the right pattern early
Why difficulty labels are misleading
How mastering array patterns alone gets you surprisingly far

I don’t have a fixed schedule. I’ll write when there’s something worth sharing.

If any of this resonates, feel free to stick around.

I’ll build in public and hopefully, learn alongside a few of you.

Backend engineer. Thinking a lot about DSA, systems, and how engineers actually reason.
Building indexedcode in public.

Elastic Beanstalk - Update Media Upload Size

Rasool Khan — Thu, 11 Nov 2021 10:58:20 +0000

Introduction

Elastic Beanstalk is an AWS service for deploying and scaling web applications. We can upload our project code and elastic beanstalk will automatically handle the deployment, load balancing, auto-scaling, CloudWatch, etc.

Media Upload in S3

In a local environment, when we upload a media file to an AWS S3 bucket, the file is first uploaded to our local server and then from our application the file is uploaded to S3 bucket.

The Problem

But in production mostly we use Nginx web server. So, the Elastic Beanstalk basically creates an EC2 instance and uses Nginx in front of the node server as a proxy server.

So, the problem arises here because Nginx server is a proxy server it doesn't allow unlimited upload size. Nginx has a default upload size as 1 MB for all file uploads. That's why when we upload a file which is over 1 MB size to S3 using an application deployed on Elastic Beanstalk it throws an error:

413 – Request Entity Too Large

To solve this issue we have to add a custom Nginx configuration file.

Solution

Elastic Beanstalk provides a number of platforms(docker, Go, Node, Java, etc.) which can be used to build our application. The Nginx is installed on the platform so to add a custom Nginx configuration file we need to add nginx.conf file inside of the platform folder.

The below example shows how the our app is structured in the Elastic Beanstalk. You can read more about it here.

~/my-app/
|-- web.jar
|-- Procfile
|-- readme.md
|-- .ebextensions/
|   |-- options.config        # Option settings
|   `-- cloudwatch.config     # Other .ebextensions sections, for example files and container commands
`-- .platform/
    |-- nginx/                # Proxy configuration
    |   |-- nginx.conf
    |   `-- conf.d/
    |       `-- custom.conf

This is the folder structure we need to follow in order to add custom Nginx config file. Create a .platform folder in your project's root directory. Then create a file called proxy.conf.

The proxy.conf file will be placed at ".platform/nginx/conf.d/proxy.conf". The contents of this file will be:

client_max_body_size 100M;

After adding this file, deploy your app to Elastic Beanstalk. Now, we will be able to upload any file up to size 100MB.

Note: When deploy our app, Nginx server will automatically reload. If you are still not able to upload above 1MB then, the issue could be that Nginx server was not reloaded properly. To solve this, we can add another file. In the root of .platform folder create a file called as myconf.config. This command will basically reload our Nginx server before starting. The contents of this will be as follows:

container_commands:
  01_reload_nginx:
    command: "service nginx reload"

Note: If you are using docker then add the .platform folder in the root directory along with Dockerrun.aws.json. Then bundle them as zip and deploy.

Summary

We saw how Nginx server only allows 1MB of file upload when deployed in Elastic Beanstalk. And we saw how to solve this by creating a custom Nginx configuration file.

Please like and share if you found it useful. And follow me on twitter.

Thank you for reading!

Building CRUD API with NestJs - Swagger API Documentation.

Rasool Khan — Wed, 13 Oct 2021 15:53:49 +0000

Introduction

In this part, we will integrate Swagger UI which helps us to visualize our API resources and with visual documentation, it is easier for consuming and implementing APIs.

Why Swagger?
The swagger UI does the hard work of generating and maintaining our API docs, making sure our documentation stays up-to-date as our application evolves.

Before integrating Swagger UI, let's create some more APIs. In the last part we created a POST API to create new user. Let's create GET APIs to get all users and to get a single user.

//Add these APIs in user.controller.ts
@Get('all')
  async getAll(): Promise<User[]> {
    return this.userService.getAll();
  }

  @Get(':userId')
  async getUser(@Param('userId') userId: number): Promise<User> {
    return await this.userService.getUser(userId);
  }

//user.service.ts
async getAll(): Promise<User[]> {
    return await this.userRepository.findAll();
  }

  async getUser(userId: number): Promise<User> {
    return await this.userRepository.findOne({ id: userId });
  }

Note: Here, we are just returning the data from database directly. But, this is not secure at all we shouldn't be exposing the data directly, we have to create response objects and return them to the client. Also, we have not added any validation what happens if the user we are requesting does not exist we are still returning 200 response which is not ideal. Please explore how to handle validation in APIs and how to use response objects to return data to client. Don't worry if you can't understand these, we will look into these in next part.

Installation

We can install the swagger dependencies using npm

npm install --save @nestjs/swagger swagger-ui-express

Once the installation is complete we need to initialize Swagger in 'main.ts' file

Now, in our browser if we go to: http://localhost:3000/api/. We can see the list of APIs we have created and we can see all the details of the APIs what parameters it requires and what responses it returns.

Swagger Schema

But if we see in schema below it contains 'CreateUserDto' object which we created but it's empty as Swagger is not able to recognize it.

We are using Nest CLI, so we need to add the following plugin configuration in 'nest-cli.json' file.

Also, in all the APIs the response objects are empty, as we need to mention them explicitly in controllers. So, let's do it now.

Note: We have added only response objects for status 200. Please explore what other return statuses are possible and add respective Api Response decorators for them.

Now we can see the response objects and the schema objects.

Note: If schema objects are still empty, please delete 'dist' directory and run the server again. This folder contains the file conversions of TypeScript to JavaScript. NestJs is entirely written in TypeScript but it has to be converted to JavaScript which is run by the server. Since we have updated the 'nest-cli.json' file we may have to generate the dist folder again.

Summary

In this tutorial, we explored how we can integrate Swagger UI in our Nest application to document our APIs. We also saw how to add response objects and schema objects in swagger UI.

GitHub Repository - https://github.com/rskhan167/movie-review

That's it for this part. Please like and share if you found it useful.
Follow me on Twitter: https://twitter.com/Dotnetdotnet

Thanks for reading.

Building CRUD API with NestJs - Write First API.

Rasool Khan — Fri, 08 Oct 2021 18:53:11 +0000

Part II

In Part I, we created nestjs project and created a database and then integrated Mikro-Orm. In this part we are going to create entities and start writing APIs.

We are first going to start with User module. We are going to structure our project like user folder will contain controller, service, repository, entities of it's own and after this module is completed we are going to export this module to our main module i.e. "app.module.ts file".
First, let's create a "user" named folder in src directory.

Create an Entity

Now, let's create a folder "entities" which will contain all the entities related to user.

Here we used @Entity to define an entity. The entity contains many properties and these properties can be defined with either @Property(), @ManyToOne(), @OneToMany(), etc. These are known as decorators, to know more about these checkout out Decorator Reference.
There are also some optional properties like defining an entity property as nullable using @Property({ nullable: true }) and also setting a default value for a property. Check out Defining Entities to know more about how to define an entity and its properties.
We have also used 'class-validator' package which is used to validate an entity property itself. @IsEmail() decorator will check if the email is valid or not. We can add a lot these validation at entity creation level itself so that no improper data reaches the database.

Now let's create user repository. Create this file in the user directory itself.

//user.repository.ts
import { EntityRepository, Repository } from '@mikro-orm/core';
import { User } from './entities/user.entity';

@Repository(User)
export class UserRepository extends EntityRepository<User> {}

Now we need to run migration and apply the migration to create this user table in our database.
Run this command npx mikro-orm migration:create to create a new migration file. If any new entity is created or a change has been made to the existing entities, a new migration file will be generated. Then, npx mikro-orm migration:up command will apply the changes to the database.

Check out these other Mikroorm related commands:

npx mikro-orm migration:create   # Create new migration with current schema diff
npx mikro-orm migration:up       # Migrate up to the latest version
npx mikro-orm migration:down     # Migrate one step down
npx mikro-orm migration:list     # List all executed migrations
npx mikro-orm migration:pending  # List all pending migrations

This is the migration file that is being generated. After applying these changes to the database a new table will be created.

First API

Now that our table is created we can start writing APIs. We will create a controller and a service file. Controller file will handle all our APIs related to user and all the business logic will be written in service file.

Controller

We will create a CreateUser API. This API will accept user details and then store it in our user table. First, we need to create a DTO(Data Transfer Object), in simple words DTOs are used to map objects to domain models.
In user directory create "dtos" folder and inside it create "create-user.dto.ts" file.

Here, we have defined all the properties needed to create a new user. As mentioned in previous post to validate a property we are using 'class-validator' library.

Now we can create user controller file.

We are injecting UserService here, where we will call database to perform CRUD operation. In controller, we just handle the incoming request and then send the response back to the client.

Service

UserService is where we make the database call using ORM to store or retrieve the data. Services in Nestjs are known as Providers. Providers (services, repositories, helpers, etc.) can be injected as dependencies.

As repositories are also providers these can be injected as dependency too and we inject UserRepository so that UserService can retrieve or store data in the database.
We have a single method inside user service, which first checks if the a user with given email Id is already stored in database or not. Then, we create a User object using the constructor created in user entity. At last, we save the new user object in the database.

Before, we test our API as mentioned earlier, we need to import this user module in our main "app.module.ts" file. Just add the "UserModule" file in imports.

Test the API.

Run the "npm run start" or "npm run start:dev" command in the terminal to start the application.
For testing we are using Postman, you can download if you don't have it already or you can use postman online in your browser too.

We send a POST request to the /api/user endpoint:

After successful response we have our first entry in the database.

Summary

In this tutorial, we created our first API and learned how to uses Mikro-Orm to store and retrieve data from database. And tested our API with postman.

Github Repository - https://github.com/rskhan167/movie-review

That's all for this part see you in the next one. Thanks for reading.
Please Like it and Share with your friends if you found it useful.

Building CRUD API with NestJs - Introduction.

Rasool Khan — Thu, 07 Oct 2021 20:30:33 +0000

NestJs is a Node.js framework for building efficient and scalable server-side applications and the best thing is that it fully supports Typescript.
And we will be using Mikro-orm for data mapping and PostgreSQL, a relational database.

We are going to create a movie-review app wherein users can rate and write review about the movies/shows they have watched.

This will a series, so please follow each blog and at the end of the series hopefully we will have a working back-end application and in doing so we will get better understanding of NestJs.

Part I

So, in the first part of this series, we are going to setup our NestJs project, create a PostgreSQL database and connect our application with the database using Mikro-Orm.

Let's start...

Installation

Install Nest CLI globally in your machine and then using the Nest CLI create a new project.

$ npm i -g @nestjs/cli
$ nest new project-name

This will create a new project which already has boilerplate files installed in it. To know what these files are please refer NestJs Documentation they have explained it perfectly.

Your project structure should look something like this

Database Configuration

We will be using PostgreSQL for database. So, install PostgreSQL and pgAdmin(Database management tool). After installing both, open pgAdmin and create new database.

Now, we need to install an ORM to work with the database we created. Let's install Mikro-Orm.

$ npm i -s @mikro-orm/cli @mikro-orm/core @mikro-orm/postgresql
$ npm i -s @mikro-orm/nestjs @mikro-orm/reflection @mikro-orm/sql-highlighter

After installing Mikro-Orm, we need to add configuration file in which we will connect to our database. Create mikro-orm.config.ts file in src folder.

We can directly configure this in app.module.ts file. But it is better to separate the dbConfig file so that we can write the database and migration details in a clean way. Please Refer Mikro-Orm documentation for other methods of configuring ORM.

After writing the config file we need to add this file to app.module.ts. Just call forRoot() method without any arguments as we have already mentioned everything in our config file.

Now, the EntityManager will be available to inject across entire project (without importing any module elsewhere).

Also make sure mikro-orm is added in package.json file.

"mikro-orm": {
    "useTsNode": true,
    "configPaths": [
      "./src/mikro-orm.config.ts",
      "./dist/src/mikro-orm.config.js"
    ]
  }

Also make sure the configPaths are given correct. You can verify this by checking your dist folder. Otherwise, you might get some error stating "cannot find mikro-orm.config.js".

Before moving forward, let's look at our main.ts file as well. Here, we have to mention the port number our app will be running on. And we have also added a global prefix 'api' to our app. This prefix will be used in all the APIs. Example: http://localhost:3000/api/user, http://localhost:3000/api/movie/.

We are ready to create entities and start writing APIs. I think this is enough for Part I. Let's meet in the Part II of this series.

Github Repository - https://github.com/rskhan167/movie-review

Please like and share if you found it helpful.
Thanks for reading.

API documentation - Swagger UI in .NET Core

Rasool Khan — Sun, 07 Mar 2021 17:26:58 +0000

Swagger UI

What is Swagger UI?
Swagger UI is an API documentation tool that helps us to visualize our API resources and with visual documentation, it is easier for consuming and implementing APIs.

Why Swagger?
As our backend app grows managing APIs become difficult. So it is highly advisable to create API documentation. But generating and maintaining our own API documentation is a painful task this is where Swagger UI comes into the play. The swagger UI does the hard work of generating and maintaining our API docs, making sure our documentation stays up-to-date as our API evolves.

Let's create a .Net Core app. For this tutorial, we are going to have a simple app with two basic APIs.

Install Swashbuckle.AspNetCore

This is a NuGet package for Swagger in dotnet. We can install it from the Nuget package manager.

Register Swagger UI in Startup.cs

As we know that we have to register all our services in Startup.cs file.

We will register Swagger in Startup.cs file's ConfigureServices method as shown below.

using Microsoft.OpenApi.Models;

Note: This using namespace has to be added to use OpenApiInfo class.

Now, we will add swagger in the Configure method as well.

That's it. Now we are ready to use Swagger UI for our APIs.

Now, we don't have to configure anything else. As we keep adding more APIs it will start to appear in this Documentation automatically.

That's the end.

Thanks for reading.
Please share and ❤️ if this was helpful.

Publish NuGet packages with GitHub

Rasool Khan — Thu, 25 Feb 2021 11:56:28 +0000

In this blog, we will see how to publish NuGet packages to a GitHub repository. We can publish NuGet packages either publicly or privately. For publishing NuGet packages in nuget.org (publically available to all developers) Refer this.

We can publish NuGet to a repo in GitHub using Personal Access Token(PAT) so that the package can be available to our team/organization only(basically anyone who has access to our PAT).

Let's start,

1. Create a new project

Create a new .Net project using Dotnet CLI or from Visual Studio 2019.

For this blog, I am using an empty demo project. Note: Obviously, we can also use any existing projects and publish them as well.

When the project is ready to publish, open .csproj file of the project and add package description inside the PropertyGroup tag.

```

        <PropertyGroup>
        <TargetFramework>netcoreapp3.1</TargetFramework>
        <PackageId>NugetDemo</PackageId>
        <Version>1.0.0</Version>
        <Authors>RK</Authors>
        <Company>rkblog</Company>
        <PackageDescription>Demo Description</PackageDescription>
        <RepositoryUrl>https://github.com/rskhan167/NugetDemo</RepositoryUrl>
        </PropertyGroup>

```

Create a new repo in GitHub and don't forget to add it's URL inside RepositoryUrl tag.
Our project is now ready.

2. Pack the project

Now we need to package our project so that we have the .nupkg file that can be published.
And this is very simple. We can do this in two ways.

Right-click on our project in Visual Studio 2019 and select "Pack" option.

Or we can use Dotnet CLI to pack our project.

dotnet pack --configuration Release

A .nupkg file will be created in the bin directory of the project.

3. Publish the package

To publish package in GitHub we need to do two things first generate Personal Access Token and second authenticate to GitHub Packages. Refer to official github docs for generating a PAT.

Now to authenticate to GitHub Packages we need to create nuget.config file in our project directory and add the package sources and package source credentials as shown below.

After generating PAT and adding nuget.config file run this command.

dotnet nuget push "bin/Release/NugetDemo.1.0.0.nupkg" --api-key YOUR_GITHUB_PAT --source "github"

Voila! Our package is published.

We can the view package in our GitHub profile.

But wait it's not finished yet. How will we use this package as dependencies in our next .Net project? Again we have two ways to achieve this, either we can install this package from the command line OR install it from NuGet package manager in Visual Studio 2019.

4. Installing package

Adding from Command line
From Nuget Package manager.

To access our packages we need to mention our package source in Nuget manager. Refer to this official Microsoft doc to add package source.

NOTE: The package name and package source should be exactly the same as we have in our nuget.config file. Refer to the nuget.config file that we created earlier before adding package source in Nuget package manager.

That's it.

Now we can create and publish our projects as NuGet packages and use them within our organization/team in our next .Net projects.

Please ❤️ this article and share this with others too.

Forem: Rasool Khan

Why “Easy / Medium / Hard” Is a Terrible Way to Think About DSA

Difficulty feels random for a reason

Difficulty isn’t about complexity

Why “easy” problems can feel hard

Why “hard” problems sometimes feel easy

Difficulty is subjective, patterns aren’t

How I approach problems now

Why this matters while learning

This is also how interviews work

Where I’m going with this

What’s coming next

How I Identify the Right DSA Pattern (Before Writing Any Code)

I don’t start with the problem statement

Constraints do most of the work

Keywords matter, but not the way people think

The moment of clarity usually comes early

This is why coding comes last for me now

This is what I’m trying to capture

What I’ll write about next

Most DSA Problems Are Repetitions

The quiet realization

Why this feels uncomfortable at first

This is how engineering actually works

How difficulty really increases

Why grinding eventually stops helping

What helped me the most

Why I’m leaning into this publicly

What’s next

[Boost]

Building in Public: How I Think About DSA (and Why I’m Sharing It)

Rasool Khan ・ Jan 30

Building in Public: How I Think About DSA (and Why I’m Sharing It)

How my view on DSA changed

What I believe now

What I’ll write about here

Building in public

Who this is for

What’s next

Elastic Beanstalk - Update Media Upload Size

Introduction

Media Upload in S3

The Problem

Solution

Summary

Building CRUD API with NestJs - Swagger API Documentation.

Introduction

Installation

Swagger Schema

Summary

Building CRUD API with NestJs - Write First API.

Part II

Create an Entity

First API

Controller

Service

Test the API.

Summary

Building CRUD API with NestJs - Introduction.

Part I

Installation

Database Configuration

API documentation - Swagger UI in .NET Core

Swagger UI

Install Swashbuckle.AspNetCore

Register Swagger UI in Startup.cs

That's the end.

Publish NuGet packages with GitHub

1. Create a new project

2. Pack the project

3. Publish the package

4. Installing package

That's it.

Thanks for reading ❤️