DEV Community: Amit Shekhar

KV Cache in LLMs

Amit Shekhar — Fri, 27 Mar 2026 15:54:59 +0000

I am Amit Shekhar, Founder @ Outcome School, I have taught and mentored many developers, and their efforts landed them high-paying tech jobs, helped many tech companies in solving their unique problems, and created many open-source libraries being used by top companies. I am passionate about sharing knowledge through open-source, blogs, and videos.

I teach AI and Machine Learning, and Android at Outcome School.

Join Outcome School and get high paying tech job:

In this blog, we will learn about KV Cache - where K stands for Key and V stands for Value - and why it is used in Large Language Models (LLMs) to speed up text generation.

We will start with how LLMs generate text one token at a time, understand the role of Key, Value, and Query inside the model, see the problem of repeated computation through an example, and then walk through how KV Cache solves this problem by storing and reusing past results.

Let's get started.

How LLMs Generate Text

Before we understand KV Cache, we first need to understand how LLMs generate text.

An LLM - Large Language Model - is a model that has been trained on a massive amount of text data. It can understand and generate human language. When we give it a sentence, it predicts what comes next.

LLMs generate text one token at a time. A token is a small piece of text - it can be a word, part of a word, or even a single character. For simplicity, let's treat each word as one token.

Let's say we give the model this input:

"I love"

The model looks at "I" and "love", and predicts the next token: "teaching".

Now the full sequence becomes:

"I love teaching"

The model looks at "I", "love", and "teaching", and predicts the next token: "AI".

Now the full sequence becomes:

"I love teaching AI"

This process continues, one token at a time, until the model decides to stop.

The important thing to notice here is: every time the model predicts a new token, it needs to look at all the previous tokens to decide what comes next.

What Happens Inside the Model

Now, let's understand what happens inside the model when it generates each token.

The model has a component called the attention layer. The job of the attention layer is to help the model figure out which previous tokens are important for predicting the next token. Not all previous tokens are equally useful. Some matter more than others.

Inside the attention layer, every token is converted into three things. Let's understand each of them with a simple analogy.

Imagine a classroom where a new student joins and wants to find out who can help with a specific topic:

Query (Q): The new student's question - "Who here knows about this topic?" Every token being predicted gets a Query. It represents what the token is looking for.
Key (K): The name tag each existing student wears that says what they know - "I know about math" or "I know about science." Every previous token gets a Key. It describes what information that token holds.
Value (V): The actual notes each student has. Once the new student finds the right person using their name tag (Key), the notes (Value) are what they actually use. Every previous token gets a Value. It carries the actual information.

So, the current token uses its Query to compare against the Keys of all previous tokens. This comparison produces attention scores - numbers that tell the model how much focus to give to each previous token. A higher score means that token is more relevant. A lower score means it is less relevant. The model then uses these scores to collect the Values from the relevant tokens.

This is how the attention layer works.

Now, let's see the problem.

The Problem: Repeated Computation

Every time the model predicts the next token, it computes the Key, Value, and Query for all tokens in the sequence - not just the new one.

Let's see what happens step by step with our example:

Step 1: Input is "I love"

The model computes Key, Value, and Query for:

"I"
"love"

It uses these to predict the next token: "teaching".

Step 2: Input is "I love teaching"

The model computes Key, Value, and Query for:

"I" (already computed in Step 1, but computed again)
"love" (already computed in Step 1, but computed again)
"teaching" (new)

It uses these to predict the next token: "AI".

Step 3: Input is "I love teaching AI"

The model computes Key, Value, and Query for:

"I" (already computed in Step 1 and Step 2, but computed again)
"love" (already computed in Step 1 and Step 2, but computed again)
"teaching" (already computed in Step 2, but computed again)
"AI" (new)

Do you see the problem?

The Key and Value for "I" were computed in Step 1. But the model computes them again in Step 2, and again in Step 3. The same goes for "love" and "teaching".

The model is repeating the same work for tokens it has already seen. This is wasted computation.

As the sequence grows longer, this problem gets worse. If the model has already generated 100 tokens, then at the next step, it would recompute the Key and Value for all 100 previous tokens just to predict one new token. This makes text generation very slow.

The Solution: KV Cache

The idea behind KV Cache is simple: compute the Key and Value for each token once, store them, and reuse them in every future step.

Think of it like taking notes. Imagine you are in a meeting. Every time someone new speaks, instead of asking all the previous speakers to repeat what they said, you simply read from your notes and only listen to the new speaker. The notes are your cache.

Similarly, KV Cache is a memory where we save the Key and Value of every token that has already been processed. This way, the model does not have to compute them again.

Let's see how the same example works with KV Cache:

Step 1: Input is "I love"

The model computes Key, Value, and Query for:

"I"
"love"

It saves the Key and Value of "I" and "love" in the KV Cache.

It uses these to predict the next token: "teaching".

KV Cache now contains: Key and Value for "I", "love"

Step 2: Input is only "teaching" (only the new token)

The model retrieves the Key and Value of "I" and "love" from the KV Cache. No recomputation needed.

It computes Key, Value, and Query only for the new token: "teaching".

It saves the Key and Value of "teaching" in the KV Cache.

It uses all of these together to predict the next token: "AI".

KV Cache now contains: Key and Value for "I", "love", "teaching"

Step 3: Input is only "AI" (only the new token)

The model retrieves the Key and Value of "I", "love", and "teaching" from the KV Cache. No recomputation needed.

It computes Key, Value, and Query only for the new token: "AI".

It saves the Key and Value of "AI" in the KV Cache.

KV Cache now contains: Key and Value for "I", "love", "teaching", "AI"

So, instead of recomputing the Key and Value for every token at every step, the model computes them only for the new token and reuses the cached values for all previous tokens.

This is how KV Cache avoids repeated computation.

Why Only Key and Value Are Cached, Not Query

You would naturally ask: why do we cache only the Key and Value, and not the Query?

The Query is only needed for the current token - the one being generated right now. The current token uses its Query to compare against the Keys of all previous tokens to find which ones are relevant. Once the prediction is done, that Query is no longer needed.

But the Key and Value of every past token are needed at every future step, because every new token must look at all the previous tokens to make its prediction.

So, we only need to store the Keys and Values. This is why it is called KV Cache - it caches the Keys and Values.

How Much Faster Does It Get

Let's compare the two approaches side by side:

Without KV Cache:

Step 1: Compute K, V, Q for 2 tokens
Step 2: Compute K, V, Q for 3 tokens  (2 recomputed)
Step 3: Compute K, V, Q for 4 tokens  (3 recomputed)
Step 4: Compute K, V, Q for 5 tokens  (4 recomputed)
...
Step N: Compute K, V, Q for (N+1) tokens  (N recomputed)

The amount of computation keeps growing at every step.

With KV Cache:

Step 1: Compute K, V, Q for 2 tokens → Save K, V for 2 tokens in cache
Step 2: Compute K, V, Q for 1 token  → Reuse K, V for 2 tokens from cache
Step 3: Compute K, V, Q for 1 token  → Reuse K, V for 3 tokens from cache
Step 4: Compute K, V, Q for 1 token  → Reuse K, V for 4 tokens from cache
...
Step N: Compute K, V, Q for 1 token  → Reuse K, V for N tokens from cache

After the first step, the model computes only for one new token at each step instead of the entire sequence.

To put this into perspective: if the model is generating a sequence of 100 tokens, without KV Cache, the total number of Key and Value computations across all steps would be 2 + 3 + 4 + ... + 100 = 5,049 computations. With KV Cache, it would be 2 + 1 + 1 + ... + 1 = 101 computations. That is roughly 50 times fewer computations. The longer the sequence, the bigger the savings.

This is what makes KV Cache so effective at speeding up text generation.

The Trade-Off: Speed vs Memory

KV Cache makes generation faster, but it comes with a trade-off: it uses extra memory to store all the Key and Value information for every token that has been generated so far.

As the sequence gets longer, the cache grows larger. For very long sequences with thousands of tokens, the cache can consume a significant amount of memory.

So, KV Cache is a trade-off: we use more memory to save computation time. For most use cases, this trade-off is well worth it, as the speed improvement is significant.

Now, we have understood the KV Cache in LLMs.

In the next blog, we will learn about Paged Attention that solves the memory issue of KV Cache.

Prepare yourself for AI Engineering Interview: AI Engineering Interview Questions

That's it for now.

Thanks

Amit Shekhar
Founder @ Outcome School

You can connect with me on:

Follow Outcome School on:

Read all of our high-quality blogs here.

Evolution of HTTP

Amit Shekhar — Sun, 28 May 2023 06:51:03 +0000

I am Amit Shekhar, Co-Founder @ Outcome School, I have taught and mentored many developers, and their efforts landed them high-paying tech jobs, helped many tech companies in solving their unique problems, and created many open-source libraries being used by top companies. I am passionate about sharing knowledge through open-source, blogs, and videos.

Before we start, I would like to mention that, I have released a video playlist to help you crack the Android Interview: Check out Android Interview Questions and Answers.

In this blog, we will learn about the evolution of HTTP.

HTTP has seen the following version in its evolution.

HTTP 1.0
HTTP 1.1
HTTP 2.0
HTTP 3.0

This article was originally published at Outcome School.

Each version has some problems, and in order to get rid of those problems, it has to update itself. That's why HTTP kept on evolving like any other technology.

So, we will discuss each of the versions of HTTP, the problem with that version, and how it got solved in the updated version.

Let's start with HTTP 1.0

HTTP 1.0

This was the first version of HTTP. It has a problem.

Problem: Each request to the same server needed a new TCP connection.

We needed a solution for that, and HTTP 1.1 was introduced to solve this problem.

HTTP 1.1

It solves the HTTP 1.0 problem. But it has another problem.

Problem: HOL blocking issue. HOL(head-of-line) blocking issue - new request had to wait for the earlier request to complete.

HOL blocking issue at two layers:

Application
Transport(TCP)

Again, we needed a solution for that, and then HTTP 2.0 was released to solve this problem.

HTTP 2.0

It solves the HTTP 1.1 problem of the HOL issue at the application layer using request multiplexing. But the HOL blocking issue at TCP was the problem.

Problem: HOL blocking issue at TCP.

And once again, we need a solution for that, and with the release of HTTP 3.0, this problem got solved.

HTTP 3.0

It solves the HOL blocking issue at TCP. It uses QUIC(Quick UDP Internet Connections) which is based on UDP.

This is how HTTP has evolved from HTTP 1.0 to HTTP 1.1 to HTTP 2.0 to HTTP 3.0.

Master Kotlin Coroutines from here: Mastering Kotlin Coroutines

That's it for now.

Thanks

Amit Shekhar

Co-Founder @ Outcome School

You can connect with me on:

Read all of my high-quality blogs here.

React Native vs Flutter

Amit Shekhar — Mon, 22 May 2023 05:37:48 +0000

Before we start, I would like to mention that, I have released a video playlist to help you crack the Android Interview: Check out Android Interview Questions and Answers.

In this blog, we will learn about the difference between React Native and Flutter.

This article was originally published at Outcome School.

Both React Native and Flutter are the two most popular cross-platform development frameworks. They both allow developers to create mobile apps using a single code base for both Android and iOS.

When we are considering cross-platform development, we have both options. We need to choose one over the other. In order to choose one over the other, we must know the key differences between both frameworks.

Let's start to learn about both of them. Starting with React Native.

React Native

React Native is a cross-platform framework created by Facebook.
It is based on the JavaScript programming language. JavaScript is a widely-used language for web development.
It uses the native UI components for both Android and iOS. It provides the native look which means different UI on Android and iOS, Android Native UI on Android, and iOS Native UI on iOS.
Code Push: UI and business logic code (that we write in JavaScript for React Native Apps) can be updated simply through HTTP requests from the app directly without updating it on the Google Play Store / Apple App Store. This is a major advantage of React Native. You can push any new feature on the fly.
App Size: React Native apps are relatively smaller as compared to Flutter apps.
Performance: React Native uses a bridge to communicate JavaScript and native components, which is an overhead. It can have performance issues due to the bridge between JavaScript and native components. Hence, React Native is comparatively slower than Flutter.
It is supported by a large community as it has been for so long time.
It has a wide range of third-party libraries support.
Web developers can start quickly as they already know JavaScript.
Platform support: iOS, Android, Web.
It is widely adopted.

Now about the Flutter.

Flutter

Flutter is a cross-platform framework created by Google.
It is based on the Dart programming language, developed by Google specifically for building mobile and web apps.
It uses its own rendering engine to create its own UI Components. So, it replaces the native platform UI components. It provides the same look on all the platforms.
Code Push: Not supported. This is a major disadvantage of Flutter.
App Size: Flutter apps are relatively larger as compared to React Native apps.
Performance: Flutter is comparatively faster than React Native as it uses a rendering engine that directly renders to the platform, leading to fast and smooth animations.
It is supported by a smaller community as compared to React Native. But growing rapidly.
It has a small range of third-party libraries. But growing rapidly.
It has a steeper learning curve as developers need to learn the Dart language.
Platform support: iOS, Android, web, and other platforms like desktop(Windows, macOS, Linux) and embedded systems.
It is not widely adopted but gaining popularity.

From the above points, we have a good understanding of the difference between React Native and Flutter.

Let me tabulate the differences between React Native and Flutter for your better understanding so that you can decide which one to use based on your use case.

React Native vs Flutter

Feature	React Native	Flutter
Language	JavaScript.	Dart.
UI components	Native UI components.	Own UI Components.
Code Push	Code Push supported.	Code Push NOT supported.
App Size	Smaller App Size.	Larger App Size.
Performance	Comparatively slower.	Comparatively faster.
Platform Support	Platform support: iOS, Android, Web.	Platform support: iOS, Android, web, and other platforms like desktop(Windows, macOS, Linux) and embedded systems.
Community Support	Supported by a large community.	Supported by a smaller community.

Now the big question: Which framework is right for you?

There is no clear winner here, both React Native and Flutter have their pros and cons, and the right choice will depend on your experience, the goals, and the requirements of your project. You should consider the following factors:

Language
UI Components
Code Push
App Size
Performance
Platform Support
Community Support

For example, React Native is a good choice if you need a code push feature so that you can update UI and business logic code on the fly without updating the apps on Google Play Store / Apple App Store.

Another example: If you are a web developer, and you already know JavaScript, writing mobile apps in React Native is a no-brainer.

With this, I will let you decide which cross-platform development framework is right for you.

This was all about React Native vs Flutter.

Master Kotlin Coroutines from here: Mastering Kotlin Coroutines

That's it for now.

Thanks

Amit Shekhar

Co-Founder @ Outcome School

You can connect with me on:

Read all of my high-quality blogs here.

Launch vs Async in Kotlin Coroutines

Amit Shekhar — Thu, 16 Feb 2023 10:42:17 +0000

Before we start, I would like to mention that, I have released a video playlist to help you crack the Android Interview: Check out Android Interview Questions and Answers.

In this blog, we will learn about the Launch vs Async in Kotlin Coroutines. We will see how the Launch and Async differ from each other and when to use which one.

This article was originally published at Outcome School.

Let's get started.

Both launch and async are the functions in Kotlin to start the Coroutines.

launch{}
async{}

The difference is that the launch{} returns a Job and does not carry any resulting value whereas the async{} returns an instance of Deferred<T>, which has an await() function that returns the result of the coroutine like we have future in Java in which we do future.get() to get the result.

In other words:

launch: fire and forget.
async: perform a task and return a result.

Let's take an example to learn launch vs async.

We can use the launch as below:

val job = GlobalScope.launch(Dispatchers.Default) {
    // do something and do not return result
}

It returns a job object which we can use to get a job's status or to cancel it.

In the above example of launch, we have to do something and NOT return the result back.

But when we need the result back, we need to use the async.

val deferredJob = GlobalScope.async(Dispatchers.Default) {
    // do something and return result, for example 10 as a result
    return@async 10
}
val result = deferredJob.await() // result = 10

Here, we get the result using the await().

In async also, we can use the Deferred job object to get a job's status or to cancel it.

Note: I have used GlobalScope for quick examples, we should avoid using it at all costs. In an Android project, we should use custom scopes based on our usecase such as lifecycleScope, viewModelScope and etc.

Another difference between launch and async is in terms of exception handling.

If any exception comes inside the launch block, it crashes the application if we have not handled it.

However, if any exception comes inside the async block, it is stored inside the resulting Deferred and is not delivered anywhere else, it will get silently dropped unless we handle it.

Let's understand this difference with code examples.

Suppose we have a function that does something and throws an exception:

private fun doSomethingAndThrowException() {
    throw Exception("Some Exception")
}

Now using it with the launch:

GlobalScope.launch {
    doSomethingAndThrowException()
}

It will CRASH the application as expected.

We can handle it as below:

GlobalScope.launch {
    try {
        doSomethingAndThrowException()
    } catch (e: Exception) {
        // handle exception
    }
}

Now, the exception will come inside the catch block and we can handle it.

And now, using it with the async:

GlobalScope.async {
    doSomethingAndThrowException()
}

The application will NOT crash. The exception will get dropped silently.

Again, we can handle it as below:

GlobalScope.async {
    try {
        doSomethingAndThrowException()
    } catch (e: Exception) {
        // handle exception
    }
}

Now, the exception will come inside the catch block and we can handle it.

Let me tabulate the difference between launch and async.

Launch	Async
Fire and forget.	Perform a task and return a result.
`launch{}` returns a `Job` and does not carry any resulting value.	`async{}` returns an instance of `Deferred<T>`, which has an `await()` function that returns the result of the coroutine.
If any exception comes inside the launch block, it crashes the application if we have not handled it.	If any exception comes inside the async block, it is stored inside the resulting Deferred and is not delivered anywhere else, it will get silently dropped unless we handle it.

So, we have understood the difference between the launch function and the async function.

Master Kotlin Coroutines from here: Mastering Kotlin Coroutines

Outcome School Android Program: Outcome School Android Program

That's it for now.

Thanks

Amit Shekhar

Founder @ Outcome School

You can connect with me on:

Read all of my high-quality blogs here.

callbackFlow - Callback to Flow API in Kotlin

Amit Shekhar — Tue, 31 Jan 2023 05:31:27 +0000

Before we start, I would like to mention that, I have released a video playlist to help you crack the Android Interview: Check out Android Interview Questions and Answers.

In this blog, we will learn how to convert any Callback to Flow API in Kotlin using callbackFlow.

This article was originally published at Outcome School.

This blog is a part of the series I have written on Flow API in Kotlin:

Mastering Flow API in Kotlin
Creating Flow Using Flow Builder in Kotlin
Terminal Operators in Kotlin Flow
Cold Flow vs Hot Flow
StateFlow and SharedFlow
Long-running tasks in parallel with Kotlin Flow
Retry Operator in Kotlin Flow
Retrofit with Kotlin Flow
Room Database with Kotlin Flow
Kotlin Flow Zip Operator for Parallel Multiple Network Calls
Instant Search Using Kotlin Flow Operators
Exception Handling in Kotlin Flow
callbackFlow - Callback to Flow API in Kotlin - YOU ARE HERE
Unit Testing ViewModel with Kotlin Flow and StateFlow

We use many libraries in our Android Project that provides the callback way to use instead of the Flow API way. As nowadays, we all have started using Kotlin Coroutines Flow API in our projects, so it becomes our responsibility to implement things in a way that supports Flow API.

So, we need to learn how to convert any Callback to Flow API in Kotlin using callbackFlow. And, this is the topic of this blog.

Here, I will take an example of a LocationManager just for the sake of understanding.

Assume that we can use LocationManager and listen to the changes in location as below:

// create a location listener
val locationListener = object : LocationListener {

    override fun onLocationUpdate(location: Location) {
        // do something with the updated location
    }

}

// register for location updates
LocationManager.registerForLocation(locationListener)

// unregister in onDestroy()
LocationManager.unregisterForLocation(locationListener)

Here, we have a LocationListener through which we get the onLocationUpdate callback.

Now, we want to use this LocationManager in the Flow API way.

Let's do this by creating a function which returns Flow<Location> as below:

fun getLocationFlow(): Flow<Location> {
    return callbackFlow {

        val locationListener = object : LocationListener {

            override fun onLocationUpdate(location: Location) {
                trySend(location)
            }

        }

        LocationManager.registerForLocation(locationListener)

        awaitClose {
            LocationManager.unregisterForLocation(locationListener)
        }

    }
}

Now, it's time to understand what we have done to convert the Callback to Flow API.

We have followed the following steps to convert the Callback to Flow API in Kotlin:

Create a function to return the Flow<Location>.
Use callbackFlow as the return block.
Use trySend() for the location updates.
Use awaitClose block to unregister.

Now, we can use the above function as below:

launch {
    getLocationFlow()
    .collect { location ->
        // do something with the updated location
    }
}

This is how we can convert any callback to Flow API in Kotlin using callbackFlow.

So, today we learned how to convert any callback to Flow API and use them.

Master Kotlin Coroutines from here: Mastering Kotlin Coroutines

Outcome School Android Program: Outcome School Android Program

That's it for now.

Thanks

Amit Shekhar

Co-Founder @ Outcome School

You can connect with me on:

Read all of my high-quality blogs here.

Dalvik, ART, JIT, and AOT in Android

Amit Shekhar — Fri, 27 Jan 2023 15:28:18 +0000

Before we start, I would like to mention that, I have released a video playlist to help you crack the Android Interview: Check out Android Interview Questions and Answers.

In this blog, we will learn about the terms Dalvik, ART, JIT, and AOT in Android.

We, Android Developers keep hearing these terms when we talk about optimization, and performance but have little or no idea about them.

Dalvik
ART
JIT
AOT

Do not worry, today we will learn about each of them in detail.

This article was originally published at Outcome School.

These terms are related to Android Runtime, so first we must understand what is Android Runtime.

What is Android Runtime?

We write code in Kotlin/Java, and when we build the APK, it gets converted to bytecode.

In our APK, we will have the .dex files that contain bytecode.

Our Android devices can't run the bytecode directly, so it needs to be translated to the machine code. This translation is done by Android Runtime.

Kotlin/Java > bytecode(.dex files in APK) > machine code

So, now that we know what is Android Runtime, it's time to learn about the different types of Android Runtime and their evolution.

Dalvik
ART

Let's first learn about the Dalvik.

Dalvik

Dalvik, our first Android Runtime is based on the JIT compilation.

JIT compilation means Just In Time compilation.

As the .dex contain the bytecode, it needs to be translated to the machine code to be run.

In Dalvik Android Runtime, as it is JIT based, it gets translated when we run the app. As we keep on using the app, only that part of the bytecode gets converted to the machine code. Also, the most frequently used code gets cached so that we don't have to translate them again.

This process is repeated every single time when we open the app using the CPU cycles and hence impacting the battery life.

Disadvantage: Low performance and decreases battery performance.

The performance of the application was not up to the mark as the translation was happening during the application run and it happens every time when we run the app.

So, we needed a solution to make the apps more performant.

In Android L, we were introduced to the new Android Runtime: ART.

Till now, we have learned about the Dalvik and JIT, now it's time to learn about the ART and AOT.

ART

ART, our next Android Runtime is based on the AOT compilation.

AOT compilation means Ahead of Time compilation.

Again, as the .dex contain the bytecode, it needs to be translated to the machine code to be run.

In ART Android Runtime, as it is AOT based, it gets translated before we run the app. It gets translated at the time of app installation only. Basically, when we install the app, it translates the bytecode into the machine code and stores it on the disk.

So, by ART, the problem related to the low performance of Dalvik got solved. Now we have a high-performance application because there is no need for translation during the app run.

Advantage: High Performance

But, we should also talk about the disadvantages.

One disadvantage is more installation time as it translates the bytecode to the machine code at the time of app installation only.

Another disadvantage of ART is that it needs more space as it translates the bytecode into machine code and stores it on the disk. The pre-compiled binary occupies more space than the DEX bytecode. So, it takes more space as compared to the Dalvik runtime.

The last disadvantage is that the boot time is more as compared to the Dalvik as the cache is built during the boot. You might see an "Optimizing apps" dialog box while booting your Android devices.

Disadvantages:

More install time
More space on the disk
More boot time

Time to talk about the solution to these above-mentioned problems.

Before that let's see the difference between Dalvik and ART in a tabular form.

Difference between Dalvik and ART

Dalvik	ART
JIT based	AOT based
Low performance	High performance
More startup time	Less startup time
Less install time	More install time
Less space on the disk	More space on the disk
Less boot time	More boot time
Decreases battery performance	Increases battery performance
Does not have a better Garbage collection as compared to ART	Better Garbage collection than Dalvik

Now, let's get back to the discussion regarding the solution.

And we all know that users use 20% of the Apps present on their devices 80% of the time. And also, 20% part of an application is used 80% of the time. So, it is unnecessary to keep the translation of the complete bytecode of all the apps. It's a complete waste of space and time.

We could have a better solution.

In Android N, Just In Time compilation was introduced back with the profile-guided compilation.

Profile-guided compilation

In profile-guided compilation, the translation is done using the Just In Time compilation which means when we are using the app. Then, as it learns which part of the apps or which apps are being very frequently used, it caches the translated code for that part only and stores it on disk.

This profile-guided compilation is hybrid ART with both JIT and AOT.

In the initial few runs, the apps run slowly, but with the subsequent run, it becomes faster as it has learned more about the usage and has cached the translated code based on the usage.

Advantages:

Less install time
Less space on the disk
Less boot time
Improved performance but only after the first few application usages.

Disadvantages:

Low performance in the initial few runs of the application.

Now, that we have solved most of the issues, now we are left with only one issue which is "Low performance in the initial few runs of the application".

We just need to solve this, and we will win.

The solution: ART Cloud Profiles that was introduced in Android P.

ART Cloud Profiles

As we know that most of the apps are used in a similar pattern by most users, Google collects this usage pattern data about all the apps present on the Play Store. They aggregate the data and call it as "Code Profile".

This Code Profile has information about which part of the app is frequently run by most users.

If we install an app, the Code Profile also gets downloaded along with the APK.

ART uses it to translate the code that is frequently run by most users. It does it during the installation that is before the app run.

And we start getting improved performance from the initial run of the application.

All problems got solved.

Master Kotlin Coroutines from here: Mastering Kotlin Coroutines

Outcome School Android Program: Outcome School Android Program

That's it for now.

Thanks

Amit Shekhar

Co-Founder @ Outcome School

You can connect with me on:

Read all of my high-quality blogs here.

Difference between == and === in Kotlin

Amit Shekhar — Wed, 25 Jan 2023 06:57:51 +0000

Hi, I am Amit Shekhar, Co-Founder @ Outcome School • IIT 2010-14 • I have taught and mentored many developers, and their efforts landed them high-paying tech jobs, helped many tech companies in solving their unique problems, and created many open-source libraries being used by top companies. I am passionate about sharing knowledge through open-source, blogs, and videos.

Before we start, I would like to mention that, I have released a video playlist to help you crack the Android Interview: Check out Android Interview Questions and Answers.

In this blog, we will learn about the difference between == and === in Kotlin.

This article was originally published at Outcome School.

In Kotlin, we have two types of equality:

Structural equality (==): It checks for equals().
Referential equality (===): It checks whether the two references point to the same object.

Let's learn about these two equalities in Kotlin with examples.

Suppose we have a class as below:

class Car(val color: String) {

}

Note: This is NOT a data class. So, it will not implement the equals() method by default.

First, let's first compare Structural equality.

val car1 = Car("RED")
val car2 = Car("BLUE")
println(car1 == car2)

The output:

false

It outputs false and it is obvious.

Let's take another example.

val car1 = Car("RED")
val car2 = Car("RED")
println(car1 == car2)

The output:

false

It also outputs false even though the color of both cars is the same because we have not implemented the equals() method.

Let’s take another example.

val car1 = Car("RED")
val car2 = car1
println(car1 == car2)

The output:

true

It outputs true as the references to both objects are the same now, no need of checking for the equals() method implementation.

Now, compare Referential equality.

val car1 = Car("RED")
val car2 = Car("RED")
println(car1 === car2)

The output:

false

It outputs false as the references to both objects are different.

Another example:

val car1 = Car("RED")
val car2 = car1
println(car1 === car2)

The output:

true

It outputs true as the references to both objects are the same now.

Till now, we have NOT implemented the equals() method, there are two ways to implement equals() method:

Making the class a data class.
Adding our own equals() method implementation.

Both will behave the same. So, let's go with the data class.

As our class Car was not a data class. Now, let's make our class a data class.

data class Car(val color: String) {

}

When we make it a data class, it implements equals() method internally.

Now, let's first compare Structural equality.

val car1 = Car("RED")
val car2 = Car("BLUE")
println(car1 == car2)

The output:

false

It outputs false that is obvious.

Let's take another example.

val car1 = Car("RED")
val car2 = Car("RED")
println(car1 == car2)

The output:

true

It outputs true as the color of both cars is the same and we have made the class a data class that implements the equals() method.

Let’s take another example.

val car1 = Car("RED")
val car2 = car1
println(car1 == car2)

The output:

true

It outputs true as the references to both objects are the same now, no need of checking for the equals() method implementation although it is a data class. The output will be the same even if it was not a data class as we have seen earlier.

Now, compare Referential equality. It has no impact due to the data class.

val car1 = Car("RED")
val car2 = Car("RED")
println(car1 === car2)

The output:

false

It outputs false as the references to both objects are different.

Another example:

val car1 = Car("RED")
val car2 = car1
println(car1 === car2)

The output:

true

It outputs true as the references to both objects are the same now.

Now, we know the difference between == and === in Kotlin.

Watch the video format: Difference between == and === in Kotlin

Master Kotlin Coroutines from here: Mastering Kotlin Coroutines

Outcome School Android Program: Outcome School Android Program

That's it for now.

Thanks

Amit Shekhar

Co-Founder @ Outcome School

You can connect with me on:

Read all of my high-quality blogs here.

crossinline in Kotlin

Amit Shekhar — Fri, 20 Jan 2023 06:25:14 +0000

Before we start, I would like to mention that, I have released a video playlist to help you crack the Android Interview: Check out Android Interview Questions and Answers.

In this blog, we will learn about the crossinline modifier in Kotlin.

This article was originally published at Outcome School.

What is a crossinline in Kotlin?

crossinline in Kotlin is used to avoid non-local returns.

Do not worry about the term "non-local returns", we will learn it with an example.

As we are learning about the crossinline, we must be knowing about the inline keyword in Kotlin. You can learn here.

Let's take an example to understand the non-local returns.

fun guide() {
    print("guide start")
    teach {
        print("teach")
        return
    }
    print("guide end")
}

inline fun teach(abc: () -> Unit) {
    abc()
}

Here, we have added a return statement in the lambda function that we are passing.

Let's go to the decompiled code. The decompiled code is as below:

public void guide() {
    System.out.print("guide start");
    System.out.print("teach");
}

When we notice the decompiled code, we find that there is no System.out.print("guide end"). As we have added the return inside the lambda, it allowed the non-local returns and left the code below that.

Now, we have an idea of non-local returns.

How can we avoid this situation?

crossinline in Kotlin is the solution to avoid non-local returns.

When we add the crossinline, then it will not allow us the put the return inside that lambda.

Let's use the crossinline.

Our updated code with crossinline:

fun guide() {
    print("guide start")
    teach {
        print("teach")
        // return is not allowed here
    }
    print("guide end")
}

inline fun teach(crossinline abc: () -> Unit) {
    abc()
}

Again, let's go to the decompiled code. The decompiled code is as below:

public void guide() {
    System.out.print("guide start");
    System.out.print("teach");
    System.out.print("guide end");
}

Now, we can see that everything is as expected. We also have the System.out.print("guide end").

This is how the crossinline can help us to avoid the "non-local returns".

Now, we have understood the crossinline in Kotlin.

Learn about noinline: noinline in Kotlin

Master Kotlin Coroutines from here: Mastering Kotlin Coroutines

That's it for now.

Thanks

Amit Shekhar

Co-Founder @ Outcome School

You can connect with me on:

Read all of my high-quality blogs here.

noinline in Kotlin

Amit Shekhar — Tue, 17 Jan 2023 05:40:57 +0000

Before we start, I would like to mention that, I have released a video playlist to help you crack the Android Interview: Check out Android Interview Questions and Answers.

In this blog, we will learn about the noinline modifier in Kotlin.

This article was originally published at Outcome School.

What is a noinline in Kotlin?

Assume that we do not want all of the lambdas passed to an inline function to be inlined, in that case, we can mark those function parameters with the noinline modifier.

As we are learning about the noinline, we must be knowing about the inline keyword in Kotlin. You can learn here.

Let's understand this noinline modifier with an example.

fun guide() {
    print("guide start")
    teach({
        print("teach abc")
    }, {
        print("teach xyz")
    })
    print("guide end")
}

inline fun teach(abc: () -> Unit, xyz: () -> Unit) {
    abc()
    xyz()
}

Let's go to the decompiled code. The decompiled code is as below:

public void guide() {
    System.out.print("guide start");
    System.out.print("teach abc");
    System.out.print("teach xyz");
    System.out.print("guide end");
}

Here, both the lambdas(abc, xyz) passed to an inline function got inlined.

What if we want only the first lambda(abc) to get inlined but not the second lambda(xyz)?

In that case, we will have to use the noinline modifier with that lambda(xyz).

Our updated code:

fun guide() {
    print("guide start")
    teach({
        print("teach abc")
    }, {
        print("teach xyz")
    })
    print("guide end")
}

inline fun teach(abc: () -> Unit, noinline xyz: () -> Unit) {
    abc()
    xyz()
}

Again, let's go to the decompiled code. The decompiled code is as below:

public void guide() {
    System.out.print("guide start");
    System.out.print("teach abc");
    teach(new Function() {
        @Override
        public void invoke() {
            System.out.print("teach xyz");
        }
    });
    System.out.print("guide end");
}

public void teach(Function xyz) {
    xyz.invoke();
}

Here, we can see that the lambda(xyz) has not got inlined as expected. Only the lambda(abc) got inlined. This is how noinline in Kotlin helped us in achieving what we wanted.

This way, we used the noinline to avoid the inlining.

Now, we have understood the noinline in Kotlin.

Learn about crossinline: crossinline in Kotlin

Master Kotlin Coroutines from here: Mastering Kotlin Coroutines

That's it for now.

Thanks

Amit Shekhar

Co-Founder @ Outcome School

You can connect with me on:

Read all of my high-quality blogs here.

Configuration with Viper in Go

Amit Shekhar — Mon, 16 Jan 2023 13:46:14 +0000

In this blog, we will learn how to load the configurations from the envfile in Golang using Viper in Go (Golang) projects.

This article was originally published at Outcome School.

About the viper package: Viper is used to find, load, and unmarshal a configuration file in JSON, TOML, YAML, HCL, INI, envfile, or Java properties formats.

So, let's start learning to use this viper package to load configuration from the envfile in Go.

I will be using the below-mentioned project for the implementation part. The project follows a clean architecture in Go Language. You can find the complete code for loading the configuration using the Viper package mentioned in the blog in the project itself.

Link to the project: Go Backend Clean Architecture.

As a first step, we should install the package:

go get github.com/spf13/viper

We have a .env file in our project as below:

APP_ENV=development
SERVER_ADDRESS=:8080
PORT=8080
CONTEXT_TIMEOUT=2
DB_HOST=localhost
DB_PORT=27017
DB_USER=
DB_PASS=
DB_NAME=go-backend-clean-architecture-db
ACCESS_TOKEN_EXPIRY_HOUR = 2
REFRESH_TOKEN_EXPIRY_HOUR = 168
ACCESS_TOKEN_SECRET=access_token_secret
REFRESH_TOKEN_SECRET=refresh_token_secret

And, we want to load the configuration from this .env file.

Now, we have to create a struct Env in the env.go file as below:

type Env struct {
    AppEnv                 string `mapstructure:"APP_ENV"`
    ServerAddress          string `mapstructure:"SERVER_ADDRESS"`
    ContextTimeout         int    `mapstructure:"CONTEXT_TIMEOUT"`
    DBHost                 string `mapstructure:"DB_HOST"`
    DBPort                 string `mapstructure:"DB_PORT"`
    DBUser                 string `mapstructure:"DB_USER"`
    DBPass                 string `mapstructure:"DB_PASS"`
    DBName                 string `mapstructure:"DB_NAME"`
    AccessTokenExpiryHour  int    `mapstructure:"ACCESS_TOKEN_EXPIRY_HOUR"`
    RefreshTokenExpiryHour int    `mapstructure:"REFRESH_TOKEN_EXPIRY_HOUR"`
    AccessTokenSecret      string `mapstructure:"ACCESS_TOKEN_SECRET"`
    RefreshTokenSecret     string `mapstructure:"REFRESH_TOKEN_SECRET"`
}

Then, create a function in the same env.go file to load the .env file and unmarshal it into the above created Env struct.

func NewEnv() *Env {
    env := Env{}
    viper.SetConfigFile(".env")

    err := viper.ReadInConfig()
    if err != nil {
        log.Fatal("Can't find the file .env : ", err)
    }

    err = viper.Unmarshal(&env)
    if err != nil {
        log.Fatal("Environment can't be loaded: ", err)
    }

    if env.AppEnv == "development" {
        log.Println("The App is running in development env")
    }

    return &env
}

Here, we can notice that we have provided the file .env to the viper using the SetConfigFile method, then read and finally unmarshal it into the Env struct.

The complete env.go file will be as below:

package bootstrap

import (
    "log"

    "github.com/spf13/viper"
)

type Env struct {
    AppEnv                 string `mapstructure:"APP_ENV"`
    ServerAddress          string `mapstructure:"SERVER_ADDRESS"`
    ContextTimeout         int    `mapstructure:"CONTEXT_TIMEOUT"`
    DBHost                 string `mapstructure:"DB_HOST"`
    DBPort                 string `mapstructure:"DB_PORT"`
    DBUser                 string `mapstructure:"DB_USER"`
    DBPass                 string `mapstructure:"DB_PASS"`
    DBName                 string `mapstructure:"DB_NAME"`
    AccessTokenExpiryHour  int    `mapstructure:"ACCESS_TOKEN_EXPIRY_HOUR"`
    RefreshTokenExpiryHour int    `mapstructure:"REFRESH_TOKEN_EXPIRY_HOUR"`
    AccessTokenSecret      string `mapstructure:"ACCESS_TOKEN_SECRET"`
    RefreshTokenSecret     string `mapstructure:"REFRESH_TOKEN_SECRET"`
}

func NewEnv() *Env {
    env := Env{}
    viper.SetConfigFile(".env")

    err := viper.ReadInConfig()
    if err != nil {
        log.Fatal("Can't find the file .env : ", err)
    }

    err = viper.Unmarshal(&env)
    if err != nil {
        log.Fatal("Environment can't be loaded: ", err)
    }

    if env.AppEnv == "development" {
        log.Println("The App is running in development env")
    }

    return &env
}

After that, we can just have the Env as below:

env := NewEnv()

Finally, we can just access the configuration as below:

dbName := env.DBName

secret := env.AccessTokenSecret

So, this way we are able to access the configuration values.

I will highly recommend going through the project and checking the usage of viper to load the configuration.

Link to the project: Go Backend Clean Architecture.

This is how we can load the configurations from the envfile in Golang using Viper in Go (Golang) projects.

Prepare yourself for Machine Learning Interview: Machine Learning Interview Questions

That's it for now.

Thanks

Amit Shekhar

Co-Founder @ Outcome School

You can connect with me on:

Read all of our blogs here.

Test with Testify and Mockery in Go

Amit Shekhar — Mon, 16 Jan 2023 04:23:12 +0000

In this blog, we will learn about writing the unit test with Testify and Mockery in Go (Golang) project.

This article was originally published at Outcome School.

These two packages are very useful during the testing of any Go files.

testify: A toolkit with common assertions and mocks that plays nicely with the standard library.
mockery: A mock code autogenerator for Golang used in testing.

As we know that the testify package is used for the purpose of the assertions.

mockery package provides the ability to easily generate mocks for Golang interfaces using the testify package. It removes the boilerplate coding required to use mocks.

So, let's start learning to use both packages to write tests in Go.

I will be using the below-mentioned project for the implementation part. The project follows a clean architecture in Go Language. You can find the complete code for unit testing using the Testify and Mockery mentioned in the blog in the project itself.

Link to the project: Go Backend Clean Architecture.

In the project, we have Controller, Usecase, and Repository. In this blog, we will learn to write the test by taking the Usecase as an example.

Consider the TaskUsecase present inside the given project.

package usecase

import (
    "context"
    "time"

    "github.com/amitshekhariitbhu/go-backend-clean-architecture/domain"
)

type taskUsecase struct {
    taskRepository domain.TaskRepository
    contextTimeout time.Duration
}

func NewTaskUsecase(taskRepository domain.TaskRepository, timeout time.Duration) domain.TaskUsecase {
    return &taskUsecase{
        taskRepository: taskRepository,
        contextTimeout: timeout,
    }
}

func (tu *taskUsecase) Create(c context.Context, task *domain.Task) error {
    ctx, cancel := context.WithTimeout(c, tu.contextTimeout)
    defer cancel()
    return tu.taskRepository.Create(ctx, task)
}

func (tu *taskUsecase) FetchByUserID(c context.Context, userID string) ([]domain.Task, error) {
    ctx, cancel := context.WithTimeout(c, tu.contextTimeout)
    defer cancel()
    return tu.taskRepository.FetchByUserID(ctx, userID)
}

So, our aim is to test the Usecase that is dependent on Repository. We will have to mock the Repository.

As the mockery generates the mocks for Golang interfaces, suppose we have the following interface for the TaskRepository.

type TaskRepository interface {
    Create(c context.Context, task *Task) error
    FetchByUserID(c context.Context, userID string) ([]Task, error)
}

As a next step, we need to run the following command to generate the mock for this repository.

mockery --dir=domain --output=domain/mocks --outpkg=mocks --all

Note: You will have to modify the command based on your project structure and directory.

It should generate the TaskRepository mock that we will be using for the testing.

Now, that mock for the Repository is also ready, we can write the test for the Usecase.

We will write the test for the FetchByUserID method present in the Usecase.

Here, we are testing two cases:

Success: The repository returns data successfully without any errors.
Error: The repository returns an error.

The following is the code showing how to write those tests using the testify and mockery:

package usecase_test

import (
    "context"
    "errors"
    "testing"
    "time"

    "github.com/amitshekhariitbhu/go-backend-clean-architecture/domain"
    "github.com/amitshekhariitbhu/go-backend-clean-architecture/domain/mocks"
    "github.com/amitshekhariitbhu/go-backend-clean-architecture/usecase"
    "github.com/stretchr/testify/assert"
    "github.com/stretchr/testify/mock"
    "go.mongodb.org/mongo-driver/bson/primitive"
)

func TestFetchByUserID(t *testing.T) {
    mockTaskRepository := new(mocks.TaskRepository)
    userObjectID := primitive.NewObjectID()
    userID := userObjectID.Hex()

    t.Run("success", func(t *testing.T) {

        mockTask := domain.Task{
            ID:     primitive.NewObjectID(),
            Title:  "Test Title",
            UserID: userObjectID,
        }

        mockListTask := make([]domain.Task, 0)
        mockListTask = append(mockListTask, mockTask)

        mockTaskRepository.On("FetchByUserID", mock.Anything, userID).Return(mockListTask, nil).Once()

        u := usecase.NewTaskUsecase(mockTaskRepository, time.Second*2)

        list, err := u.FetchByUserID(context.Background(), userID)

        assert.NoError(t, err)
        assert.NotNil(t, list)
        assert.Len(t, list, len(mockListTask))

        mockTaskRepository.AssertExpectations(t)
    })

    t.Run("error", func(t *testing.T) {
        mockTaskRepository.On("FetchByUserID", mock.Anything, userID).Return(nil, errors.New("Unexpected")).Once()

        u := usecase.NewTaskUsecase(mockTaskRepository, time.Second*2)

        list, err := u.FetchByUserID(context.Background(), userID)

        assert.Error(t, err)
        assert.Nil(t, list)

        mockTaskRepository.AssertExpectations(t)
    })

}

Case 1: Success

In this case, we have mocked the method of Repository to return success with the data.

Then, we are passing the mocked Repository into the Usecase.

After that, we are calling the method of the Usecase.

And then finally, asserting to check whether everything is as expected or not.

Case 2: Error

In this case, we have mocked the method of Repository to return an error.

Then, we are passing the mocked Repository into the Usecase.

After that, we are calling the method of the Usecase.

And then finally, asserting to check whether everything is as expected or not.

Now, our test is ready to be run. We can run the test and check.

We can run all the tests with the following command:

go test ./...

This is how we can write the unit test by using the Testify and Mockery package in Go (Golang) project.

I will highly recommend going through the project and checking the tests written for the Controller, Usecase, and Repository.

Link to the project: Go Backend Clean Architecture.

That's it for now.

Thanks

Amit Shekhar

Co-Founder @ Outcome School

You can connect with me on:

Read all of my high-quality blogs here.

Go JWT Authentication Middleware

Amit Shekhar — Wed, 11 Jan 2023 05:56:30 +0000

In this blog, we will learn the implementation of JWT Authentication Middleware in Go (Golang).

First of all, I must mention that the use of JWT(JSON Web Token) in the OAuth 2.0 protocol is a battle-tested way of authenticating users.

While most of the token-based authentication implementation needs a database query to verify the validity of the granted token, JWT doesn't need the database query to verify. Moreover, with JWT, we can encode some data like User ID as a payload and can be decoded to get the data when needed.

We all have been using it for a long time in projects with different languages like Java, JavaScript, Python, etc. Today, we are going to do the same in the Go language.

This article was originally published at Outcome School.

Let's Go :)

I will be using the below-mentioned project for the implementation part. The project follows a clean architecture in Go Language. You can find the complete code for the implementation of JWT Authentication Middleware mentioned in the blog in the project itself.

Link to the project: Go Backend Clean Architecture.

We will be using the following package to use JWT in Go:

go get -u github.com/golang-jwt/jwt/v4

Then, import it in your code:

import "github.com/golang-jwt/jwt/v4"

First of all, we have to create a file jwt_custom.go in the domain package as below:

package domain

import (
    "github.com/golang-jwt/jwt/v4"
)

type JwtCustomClaims struct {
    Name string `json:"name"`
    ID   string `json:"id"`
    jwt.StandardClaims
}

type JwtCustomRefreshClaims struct {
    ID string `json:"id"`
    jwt.StandardClaims
}

and suppose, we have a struct User as below:

package domain

type User struct {
    ID       string
    Name     string
}

We also have to put the secret key and expiry time for both the access token and refresh token in our configuration files such as .env or config.json.

ACCESS_TOKEN_EXPIRY_HOUR = 2
REFRESH_TOKEN_EXPIRY_HOUR = 168
ACCESS_TOKEN_SECRET=access_token_secret
REFRESH_TOKEN_SECRET=refresh_token_secret

I have used the .env file for this and then loads it into the struct Env.

type Env struct {
    AccessTokenExpiryHour  int
    RefreshTokenExpiryHour int
    AccessTokenSecret      string
    RefreshTokenSecret     string
}

Then, we have to create a file tokenutil.go. I have created this inside the tokenutil package under the internal package.

In this file, we have the following functions:

CreateAccessToken(user *domain.User, secret string, expiry int)
CreateRefreshToken(user *domain.User, secret string, expiry int)
IsAuthorized(requestToken string, secret string)
ExtractIDFromToken(requestToken string, secret string)

Let's understand what these functions do one by one.

CreateAccessToken(user *domain.User, secret string, expiry int)

This function takes three parameters: user, access secret, and expiry.

And it creates a token by encoding the payload that consists of the user Name and ID with the given expiry time signed with the given access secret.

CreateRefreshToken(user *domain.User, secret string, expiry int)

This function also takes three parameters: user, refresh secret, and expiry.

And it creates a token by encoding the payload that consists of the user ID with the given expiry time signed with the given refresh secret.

IsAuthorized(requestToken string, secret string)

This function does the task of checking if the given token is authorized or not. That's it.

ExtractIDFromToken(requestToken string, secret string)

This function decodes and extracts the ID that was encoded while creating the token.

The complete code is present inside this tokenutil.go file.

package tokenutil

import (
    "fmt"
    "time"

    "github.com/amitshekhariitbhu/go-backend-clean-architecture/domain"
    jwt "github.com/golang-jwt/jwt/v4"
)

func CreateAccessToken(user *domain.User, secret string, expiry int) (accessToken string, err error) {
    exp := time.Now().Add(time.Hour * time.Duration(expiry)).Unix()
    claims := &domain.JwtCustomClaims{
        Name: user.Name,
        ID:   user.ID,
        StandardClaims: jwt.StandardClaims{
            ExpiresAt: exp,
        },
    }
    token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
    t, err := token.SignedString([]byte(secret))
    if err != nil {
        return "", err
    }
    return t, err
}

func CreateRefreshToken(user *domain.User, secret string, expiry int) (refreshToken string, err error) {
    claimsRefresh := &domain.JwtCustomRefreshClaims{
        ID: user.ID,
        StandardClaims: jwt.StandardClaims{
            ExpiresAt: time.Now().Add(time.Hour * time.Duration(expiry)).Unix(),
        },
    }
    token := jwt.NewWithClaims(jwt.SigningMethodHS256, claimsRefresh)
    rt, err := token.SignedString([]byte(secret))
    if err != nil {
        return "", err
    }
    return rt, err
}

func IsAuthorized(requestToken string, secret string) (bool, error) {
    _, err := jwt.Parse(requestToken, func(token *jwt.Token) (interface{}, error) {
        if _, ok := token.Method.(*jwt.SigningMethodHMAC); !ok {
            return nil, fmt.Errorf("Unexpected signing method: %v", token.Header["alg"])
        }
        return []byte(secret), nil
    })
    if err != nil {
        return false, err
    }
    return true, nil
}

func ExtractIDFromToken(requestToken string, secret string) (string, error) {
    token, err := jwt.Parse(requestToken, func(token *jwt.Token) (interface{}, error) {
        if _, ok := token.Method.(*jwt.SigningMethodHMAC); !ok {
            return nil, fmt.Errorf("Unexpected signing method: %v", token.Header["alg"])
        }
        return []byte(secret), nil
    })

    if err != nil {
        return "", err
    }

    claims, ok := token.Claims.(jwt.MapClaims)

    if !ok && !token.Valid {
        return "", fmt.Errorf("Invalid Token")
    }

    return claims["id"].(string), nil
}

Next, we will create the middleware package. In this, we will create jwt_auth_middleware.go file.

Here, we need to understand that, based on the HTTP web framework that we are using, we will put the handler function corresponding to that framework. In our case, we are using the Gin HTTP web framework. So we will use the gin.HandlerFunc.

But the logic will be the same inside that function whatever framework we choose except the modification related to that framework.

The code in that file will be as below:

package middleware

import (
    "net/http"
    "strings"

    "github.com/amitshekhariitbhu/go-backend-clean-architecture/domain"
    "github.com/amitshekhariitbhu/go-backend-clean-architecture/internal/tokenutil"
    "github.com/gin-gonic/gin"
)

func JwtAuthMiddleware(secret string) gin.HandlerFunc {
    return func(c *gin.Context) {
        authHeader := c.Request.Header.Get("Authorization")
        t := strings.Split(authHeader, " ")
        if len(t) == 2 {
            authToken := t[1]
            authorized, err := tokenutil.IsAuthorized(authToken, secret)
            if authorized {
                userID, err := tokenutil.ExtractIDFromToken(authToken, secret)
                if err != nil {
                    c.JSON(http.StatusUnauthorized, domain.ErrorResponse{Message: err.Error()})
                    c.Abort()
                    return
                }
                c.Set("x-user-id", userID)
                c.Next()
                return
            }
            c.JSON(http.StatusUnauthorized, domain.ErrorResponse{Message: err.Error()})
            c.Abort()
            return
        }
        c.JSON(http.StatusUnauthorized, domain.ErrorResponse{Message: "Not authorized"})
        c.Abort()
    }
}

It takes the access secret key as an input parameter.

First, it extracts the token from the header of the request.

Then, it checks if the token is authorized or not, and it returns an error if not authorized.

If it is authorized, it extracts the UserID from the token that we have put in while creating the access token. And then put it into the context of the HTTP web framework used so that we can extract it easily when needed later in the request flow.

We can get the UserID from the HTTP Web Framework Context as below:

userID := c.GetString("x-user-id")

Then, we can use this middleware as below:

router.Use(middleware.JwtAuthMiddleware(env.AccessTokenSecret))

When we want to generate the access token, we can call:

accessToken, err := tokenutil.CreateAccessToken(user, secret, expiry)

For generating the refresh token, we can call:

refreshToken, err := tokenutil.CreateRefreshToken(user, secret, expiry)

This is how we can use JWT Authentication Middleware in Go (Golang).

I will highly recommend going through the project and checking the end-to-end flow of the implementation of JWT Authentication Middleware.

Link to the project: Go Backend Clean Architecture.

Prepare yourself for Machine Learning Interview: Machine Learning Interview Questions

That's it for now.

Thanks

Amit Shekhar

Co-Founder @ Outcome School

You can connect with me on:

Read all of our blogs here.