DEV Community: Romeo Agbor Peter

Developers should be asking more questions: - "Why does this exist?” - "Who is this for?” - “What problem does this actually solve?” - "Can I see the briefing on this"? We're creators, not a code monkeys.

Romeo Agbor Peter — Wed, 10 Dec 2025 11:50:41 +0000

Romeo Agbor Peter

Dec 5 '25

10X Developers Don’t Just Ship Code; They Ship the Business.

#webdev #careerdevelopment #programming #productivity

Comments

2 min read

10X Developers Don’t Just Ship Code; They Ship the Business.

Romeo Agbor Peter — Fri, 05 Dec 2025 11:00:00 +0000

If you’ve been in the trenches of sofware development long enough, then you’ve seen it happen: a team ships beautiful screens, elegant components, and beautiful layouts… yet the project still drags, stalls, or collapses under its own confusion.

Why? Because shipping code is not the job. Understanding the business is.

For example, a project meant to take a month, stretches into 3. Not neccessarily because the team was incompetent. Not because the tech was impossible. But because the team building the product didn’t truly understand the thing they were building.

The designers didn’t understand the business flow.
The developers didn’t ask enough questions.
And the handoff was basically “Here’s the UI. Figure it out.”

You can probably guess how that ends.

You end up having screens without context. APIs built from Figma instead of documentation. Developers coding features that look right but don’t work right for real users. And the slow, painful realization that everything needs to be rethought.

The turning point happens when the team realizes it and decides not to “fix the code,” but to fix the thinking. They challenge assumptions. They questioned flows. The frontend and backend is rewired with the actual business in mind. And suddenly everything clicked.

That’s what 10x developers do.

10x developers don't just ask “What are we building?” They ask:

“Why does this exist?”
“Who is this for?”
“What problem does this actually solve?”
“What breaks if we ship this the way it is?”

Because 10x developers understands something most devs miss:

Great software isn’t the sum of its features; it’s the expression of a business model.

And if you don’t understand the business, you can’t possibly build the product.

Personally. here are some lesson carved into stone:

1. A UI handoff is not a project handoff.
Designs do not replace business requirements. Ever!

2. If you don’t understand the business, your code will reflect it. Beautiful bugs are still bugs.

3. Documentation is a necesity.
Developers should not be reverse-engineering intent from mockups.

4. Novel problems require research.
If the domain is new or challenging, curiosity isn’t optional, it’s necessary.

At the end of the day, businesses don’t pay for beautiful UIs or API endpoints.

They pay for clarity.
They pay for understanding.
They pay for UX
They pay for outcomes.

And that’s why I believe the best developers —the 10x ones— don’t just ship code. They ship the business.

Phone Book Binary Search With Python.

Romeo Agbor Peter — Wed, 26 Apr 2023 12:30:26 +0000

Hello guys, I'm back with another one: Phone Book Binary Search With Python. Before we get started, I want to tell you what brought about this idea. A programmer friend (more of an acquaintance) shared a link on Whatsapp to Harvard's university CS50 theatrical style approach in teaching its Computer Science introduction courses online (you can check more about that here and the first use of the theatricality was an explanation of how a binary search algorithm works by using a phone book. I then thought about writing what a Binary Search algorithm is and how to implement the Phone Book search code in Python ... because why not?.

What is a Binary Search?

Binary search is a common computational search approach used in computer science to quickly search through a list for a specific value/key within a list/array of values. The concept behind it is to repeatedly divide the list in half portions that could contain the value until it's found or until the list is empty.

Programmatic Approach to Using a Binary Search.

Start by examining the midpoint of the array
If the midpoint matches the target value, return the matched index.
If the midpoint is greater than the search value, examine the left half of the array.
If the midpoint is less than the target value, examine the right half of the array.
Repeat the process of dividing the search intervals until the target value is found or the remaining interval is empty.

The concept behind Binary Search is that each comparison allows discarding half of the remaining search space, leading to a shorter time complexity.

Code implementation.

Below is a Python example code of using a Binary Search to look through a phone book:

def binary_search(arr, target):
    low = 0
    high = len(arr) - 1

    while low <= high:
        mid = (low + high) // 2

        if arr[mid][0] == target:
            return arr[mid][1]

        elif arr[mid][0] < target:
            low = mid + 1

        else:
            high = mid - 1

    return None

# Example usage
phone_book = [('Musa', '+235-706-7890'), ('Uche', '+234-807-8901'), ('John', '+234-708-9012'), ('Funke', '+234-902-7883')]

name = 'Funke'
phone_number = binary_search(phone_book, name)

if phone_number:
    print(f"{name}'s phone number is {phone_number}.")
else:
    print(f"Sorry, {name}'s contact doesn't exist in the phone book.")

In the implementation above, the argument arr is a list of tuples representing the phone book, where the first element of each tuple is a name and the second element is a phone number. target is the name we're searching for, and we're returning the corresponding phone number if we find a match.

The binary_search function starts by initializing the low and high pointers to the beginning and end of the list, respectively. It then enters a loop that repeatedly computes the midpoint of the search interval and compares the name at the midpoint with the target name. If the midpoint name matches the target, the function returns the corresponding phone number. Otherwise, if the midpoint name is less than the target, the function sets low to the midpoint plus one to discard the lower half of the list. If the midpoint name is greater than the target, the function sets high to the midpoint minus one to discard the upper half of the list. If the loop completes without finding a match, the function returns None.

In the example usage, we define a tuple that represents a phone book, and then search for the phone number associated with the name 'Funke'. If we find a match, we print out the phone number. If we don't find a match, we print out a message saying there's no contact associated with the name.

Conclusion

In conclusion, the binary search algorithm is a powerful and efficient way to search for a specific value in a sorted list or array. With each comparison, it eliminates half of the remaining search space, leading to a time complexity of O(log n) in the worst case, where n is the size of the list or array.

In the Python implementation we just saw, we applied the binary search algorithm to search for a name in a phone book. By utilizing the binary search algorithm, we were able to search the phone book much faster and more efficiently than we would have with a linear search.

Follow me on Twitter for software tweets and other interesting things about life 👋🏿

Python Normal Classes vs. Data Classes: Which Should You Use?

Romeo Agbor Peter — Fri, 31 Mar 2023 11:49:17 +0000

Hey 👋🏿, it's been a while I put out a technical piece on anything. I was jaded from things happening around me but now I'm back and I've got loads of topic and concept in tech I want to share. For starters, while researching on Python's class data, I decided to write a technical piece about it. Hope you fine it useful.

Python is an object-oriented programming language that provides different ways to define and use classes. Two popular options are data classes and normal classes. In this article, we'll explore the differences between these two types of classes and help you decide which one to use in your Python code.

What are Normal Classes?

In Python, a class is a blueprint for creating objects. A normal class is a user-defined class that doesn't have any special attributes or methods. It has a constructor method __init__ that initializes the class instance with default or user-provided values. A normal class can also have additional methods defined within its scope.

Here is an example of a normal class in Python:

class Dog:
    def __init__(self, name, breed, age):
        self.name = name
        self.breed = breed
        self.age = age

What are Data Classes?

A data class is a special type of class that is designed to store data. In Python, data classes are created using the @dataclass decorator. They are meant to be used for simple, immutable data structures that have no behavior.

Here is an example of a data class in Python:

from dataclasses import dataclass

@dataclass
class Person:
    name: str
    age: int

In the code above, The Person data class using the @dataclass decorator. We also defined two fields name and age which are annotated with their respective types.

differences between Normal and Data classes

1- Conciseness: Data classes are more concise than normal classes as they require less code to define. The fields are automatically generated, and a __repr__ method is provided for us.

Here is an example that compares the conciseness of a normal class and a data class:

class Point:
    def __init__(self, x, y):
        self.x = x
        self.y = y

    def __repr__(self):
        return f"Point(x={self.x}, y={self.y})"

@dataclass
class Point2:
    x: int
    y: int

In the above example, the Point class has a constructor method and a __repr__ method, while the Point2 data class only has the two fields x and y. The __repr__ method is automatically generated for Point2.

2- Boilerplate code: One of the biggest differences between normal classes and data classes is the amount of boilerplate code needed to define them.

When defining a normal class, we need to define the __init__ method, as well as getters and setters for each attribute, if we want to be able to access and modify them from outside the class. This can quickly become cumbersome when dealing with classes with many attributes.

Here's an example of a normal class that defines two attributes, name and age:

class Person:
    def __init__(self, name, age):
        self.name = name
        self.age = age

    def get_name(self):
        return self.name

    def set_name(self, name):
        self.name = name

    def get_age(self):
        return self.age

    def set_age(self, age):
        self.age = age

On the other hand, when defining a data class, we only need to define the attributes as class variables, and the boilerplate code is generated for us automatically. This makes data classes much more concise and easier to read.

Here's an example of a data class that defines the same two attributes, name and age:

from dataclasses import dataclass

@dataclass
class Person:
    name: str
    age: int

3- Immutability: Another key difference between normal classes and data classes is immutability. By default, data classes are immutable, meaning that their attributes cannot be modified after they are created.

This is achieved by adding the frozen=True argument to the dataclass decorator:

from dataclasses import dataclass

@dataclass(frozen=True)
class Person:
    name: str
    age: int

In contrast, normal classes are mutable by default, meaning that their attributes can be modified at any time. While mutability can be useful in certain cases, it can also make it difficult to reason about the state of an object, particularly in multi-threaded environments.

4- Type Hinting: Type hinting is another area where data classes and normal classes differ. With data classes, we can specify the types of our attributes in the class definition. This is done using Python's built-in type annotations. Here's an example:

from typing import List

@dataclass
class Person:
    name: str
    age: int
    hobbies: List[str]

As you can see, we specified the types of the name, age, and hobbies attributes. This allows Python's type checker to catch any type errors during development, which can help prevent bugs and improve the reliability of our code.

In contrast, with normal classes, we have to manually specify the types of our attributes in the constructor or in the class definition. Here's an example:

from typing import List

class Person:
    def __init__(self, name: str, age: int, hobbies: List[str]):
        self.name = name
        self.age = age
        self.hobbies = hobbies

4 Equality: By default, data classes define equality based on the values of their attributes, meaning that two instances of a data class are considered equal if all their attributes have the same values.

from dataclasses import dataclass

@dataclass
class Person:
    name: str
    age: int

p1 = Person("Alice", 30)
p2 = Person("Alice", 30)
print(p1 == p2)  # True

In contrast, normal classes define equality based on object identity, meaning that two instances of a normal class are considered equal only if they are the same object in memory.

class Person:
    def __init__(self, name, age):
        self.name = name
        self.age = age

p1 = Person("Alice", 30)
p2 = Person("Alice", 30)
print(p1 == p2)  # False

5 Overriding default methods: Data classes provide default implementations for several methods such as __init__(), __repr__(), __eq__(), __ne__(), __hash__() etc. These default implementations are generated based on the attributes defined in the class. This allows us to avoid writing boilerplate code and focus on the logic of our program.

On the other hand, with normal classes, we have to define these methods ourselves if we want to use them. Here's an example of a normal class that implements these methods:

class Person:
    def __init__(self, name: str, age: int):
        self.name = name
        self.age = age

    def __repr__(self):
        return f"Person(name='{self.name}', age={self.age})"

    def __eq__(self, other):
        if isinstance(other, Person):
            return self.name == other.name and self.age == other.age
        return False

    def __ne__(self, other):
        return not self.__eq__(other)

    def __hash__(self):
        return hash((self.name, self.age))

Conclusion

Data classes and normal classes are both used in Python to represent objects. Data classes are a more concise and readable way of defining classes that are primarily used to store data, whereas normal classes are more flexible and customizable.

Data classes are preferred when we have simple data structures and we want to avoid writing boilerplate code. They also provide several default methods such as __init__(), __repr__(), __eq__(), __ne__(), __hash__() that we don't have to write ourselves.

Normal classes, on the other hand, are more flexible and customizable. They allow us to define our own methods and attributes and provide us with complete control over our classes.

In summary, data classes are great for simple data structures and normal classes are more appropriate when we need more flexibility and control over our classes.

PS: Did you find this useful? If so then follow me for more article updates and tweets ✨

Practical Implementation of the blockchain.

Romeo Agbor Peter — Fri, 25 Nov 2022 09:16:20 +0000

Hi there 👋🏿

If you’ve been following, you should have a good understanding of what the blockchain is and does to an extent. It’s no doubt a powerful and disruptive technology. Speaking of disruptive, This article is a highlight of how blockchain can change the landscape of business, legal work and technology for good.

Blockchain in the Fintech.

The financial technology (Fintech) sector stands to benefit immensely from what blockchain technology has to offer. Due to the rise and high cost of transactions and exchange of securities within regions and the complexities in the global market, there is a need for higher technological applications that are fast and reduces cost. The traditional approach for asset management isn’t just slow but manual, tasking and error-prone when matching and reconciling accounts by involved parties (Broker, custodian and the clearing & settlement teams).

Blockchain has the potential to remove intermediaries that verify (by an exchange), clear and settle securities transactions (Equities, repurchase agreements, and leverage loans), it will save large sums of fees and capital charges globally by speeding up the securities settlement window. This will be led by an automated streamlined trade cycle giving all involved parties equal access to trade data that’s not just efficiently managed but transparent and has minimal reconciliation settlement with a fast processing time.

Blockchain in Real estate.

The known and expensive burden of the real estate sector can be greatly reduced by the parties involved. Transacting real estate deals is not only burdensome (brokers, government agents, insurance, escrow companies) because of the many middlemen needed to complete a transaction but the process can be expensive. These middlemen hold information the ordinary person does not have access to or lacks the skill to operate in the real estate market. With a public blockchain, these processes will be democratised and automated; making it easy to transact and purchase real estate properties. The financial burden will be reduced substantially and anyone would be able to put up a property on the network for prospective buyers to verify ownership, review and purchase.

Blockchain in a decentralised economy.

The blockchain can enable decision-making among members of an organisation. The idea is a bottom-up structure of an organisation with no central authority or corporate power. Every member calls the shot through a vote (at least 67% majority.). This is a shift from the usual way of creating organisations or entities where the power to make decisions rests on its members or users rather than a selected few acting as the board or a chief executive presiding over. A digital organisation over the blockchain is known as Decentralised Autonomous Organisation (DAO).

it’s nothing new that companies take decisions without giving much thought to how it affects their customer base or users of their products as long as profit is being made and investors get their returns. The answer, if its customer base or users so chose, is a decentralised digital entity where the power of control over decisions and profit is in the hands of its members.

Blockchain in the legal system.

In the legal world, Lawyers and law firms can adopt blockchain technology in the execution of legal contracts. This will require lawyers to either become developers or specify the intent of a contract clearly enough for a blockchain developer to understand.

Creating a legal smart contract will involve:

Lawyer with legal knowledge of contract drafting, structure and enforcement.
Technologist with code designing and engineering skills to implement a contract’s legal construct into a smart self-executing transaction using the blockchain.

Smart contract functions differently from the static traditional contract. Understanding how blockchain and Distributed Ledger Technology (DLT) work is crucial to managing the processes involved. Big firms representing enterprises and small firms handling the dealings of small businesses can take advantage of the opportunity blockchain provides.

Blockchain as decentralised file hosting.

If you’ve followed up until this point, you may recall in this introduction that the blockchain is likened to a central-file sharing system like Dropbox with the exception of central server architecture.
The idea of a distributed file storage system in the blockchain is not far-fetched and is very much being done. Protocols like the Interplanetary File System (IPFS) do just that. It uses content-addressing to uniquely identify and connect all computing devices on the blockchain with the same file system. This will ultimately allow for the storage of files in a decentralised manner. Computing devices on the network with enough unused disk space can rent it out thus slashing the cost of file storage as we have it.

Conclusion

The use cases for blockchain I’d say is “limitless.” The technology is still growing and the more it meets the everyday demand of people; be that in global transactions, legal work, file storage, etc; the more it’ll evolve not just in its system maturity but widespread adoption in major sectors and fields.

With that, I’m happy to say we’ve covered to a good extent the introduction of the blockchain. The next article releases will be an in-depth focus on the application of blockchain in technology, business, law and governance.

To get early update and release subscribe to the newsletter and and follow me on Twitter.

Cheers!

Motivation for Blockchain and its application as an information technology system.

Romeo Agbor Peter — Thu, 24 Nov 2022 21:14:10 +0000

Money the Motivator.

What led to the idea of creating a distributed, immutable and orderly linked database in the first place? The answer is Money.
The current monetary system of the world for retaining and managing records of transactions is through central authorities – we rely on banks and the government to retain and manage monetary records. With the blockchain, people can achieve managing financial records themselves because it guarantees uniformity for everyone. Every transaction that occurs on a particular monetary system can be monitored and recorded on a ledger by participants on the network. Because everyone is in sync with the network and has a record of every transaction, the worry or chances for fraud and incorrect entry in managing transactions is eliminated. This brings about the question: How is money created and distributed on the blockchain? That’s a different discussion entirely and we’ll get to it as we progress in the series but the simple answer is using cryptocurrencies as legal tender.

Moving away from the ledger side of things, the second motivation (or it’s realised application after the initial motivation) for the blockchain technology is in the the execution of legal contract in the form of computer code. Let’s take the scenario of a legal contract involving two parties: Two parties come together and sign contract under certain conditions that bind both of them. They both rely on each other’s good faith or trust and the justice system so that the agreement is not broken.

The risk involved in the above scenario is the “trust” or believe that the parties involved will carry out their side of the agreement swiftly without any conflict whatsoever. By using the blockchain, that risk can be eliminated. On it, the involved parties need not worry about trusting each as trust is handed to the blockchain. The agreement can be written as computer code and initialised with enough funds as agreed upon by the involved parties. The code is then executed and certain actions are triggered when due as stated on the contract. Once written, the code can’t be modified or deleted by neither party. Participants of the blockchain network all get and keep a record of this transaction between the involved parties. Contracts written as code are popularly known as smart contract

A Distributed Information Technology Part 1.

To reiterate for a better understanding of this section, the blockchain is a distributed, immutable and secured ledger of transactions as blocks of data that are cryptographically linked (forming a chain) together using a hashing function (programmatic function for converting an arbitrary size of data to form unique values).

The blockchain isn’t managed by an entity nor is it stored in a central place. it’s a mesh of multiple computers (also known as nodes or peers) connected to form a distributed system. The nodes compete to validate data entries for a reward. Once validated, the data becomes immutable. That is to say, data can only be created and viewed, not updated or deleted by a user. All nodes connected get an up-to-date record of data that reflects recent changes in the ledger. Members of the network can view the ledger at a designated website. The trustworthiness of the blockchain makes it a secure Information Technology system for enabling effective cost-saving transactions.

Conclusion

Next, we’ll look at part 2 of blockchain as Distributed Information Technology!

If you’re new, you can catch up on the previous parts in the series that led here.

Be kind and share it with others if you found it useful

Cheers!

Introduction to Blockchain: Part 2

Romeo Agbor Peter — Thu, 24 Nov 2022 20:34:30 +0000

Blockchain as Peer-to-peer System.

A peer-to-peer is a distributed software architecture that allows connection, interaction and execution of tasks with other computer systems running the same software. In the case of uTorrent, you connect with others to download and upload files to and from them. They too can do the same to you and others running the same software. the systems connected act as servers and clients to each other. So, rather than uploading a file to a central file-sharing server (like Google Drive or Dropbox). You just simply upload it directly to a friend’s computer. It takes at least two computers to make it happen, hence the name peer-to-peer (p2p).

The blockchain is a peer-to-peer network with a major difference: the peers in the network must all have a copy of the exact data. Any change made to the data in any of the peers in the network must reflect on other peers. There is a protocol to how changes are made and if a peer modifies its data without following the rules, the change is ignored because it’s invalid. If it happens that your copy of data in the blockchain is erased or becomes invalid, you can request a fresh valid copy from your peers on the network.

In current public blockchains (yes, they are types of blockchains. We’ll get there), data is only ever written and never deleted. Rather than changing data, a new one is attached to the batch or block that forms a chain link (database). Hence the name Blockchain. Besides having access to the same database, each peer in the blockchain has an exclusive right to data that only they can access. In the traditional web, access is granted given a username and a password. In the case of the blockchain, there is no central authority to manage access credentials hence it uses cryptography to grant access. Users on the blockchain are able to generate an ID (referred to as an address) that acts as a locker that is tied to their data and a private key that is used to access the locker. The private key is meant to prove that indeed the user is the creator and owner of the locker. Only the generator of the address alone would have the private key. Furthermore, the private key can not be determined just by obtaining the address.

While users’ data sit publicly on the blockchain, only they can modify it by proving ownership via the private key. Also, a new address can be generated in isolation without it ever clashing with other addresses no matter how numerous they are.
Besides storing static data on the blockchain, it can also store computer codes (executables) that execute at the trigger of an event or at a set time. every peer gets a copy of the program. The Etherium blockchain uses the Solidity programming language to build programs that represent an agreement between two parties (or more). Such programs are called Smart Contracts. The code is marked with its owner’s address. The owner decides the executions that are open to the public and those that only they can execute. Once the code is written it can’t be changed or reversed. Everyone has a copy and can see what it’s doing but can’t interact or alter the code.

Conclusion

So there you have it… next time you hear the news or see on social media talking about a “p2p exchange,” just know that it’s referring to the blockchain as peer-to-peer (p2p) for cryptocurrency.

As noted before, p2p networks existed before blockchain technology. It’s just an ideal adoption for the implementation of the blockchain – which functions differently from traditional p2p networks.

Next, We’ll look into the Motivation for Blockchain as an Information Technology system.

cheers!

Introduction to blockchain Part 1.

Romeo Agbor Peter — Fri, 28 Oct 2022 11:00:00 +0000

A blockchain is a distributed and immutable database of orderly linked blocks containing encrypted data. Each block has a fixed length of memory and a new one must be created when the previous one’s memory limit is reached. For a block to be added to the chain it must first be validated and verified by the network and then added to the end of the existing blocks. Contrary to the CRUD (Create, Read Update and Delete) function of traditional web applications, there are only two operations on the blockchain: Create block and View Block. That is, to be able to add data to a block and view that data.

The basic process of record entry on a blockchain can be broken down as follows:

Add new immutable data into blocks.
Cryptographically verify and validate data in the block.
Attach the new block at the end of existing blocks.

Once inserted, the block on the chain can’t be modified singularly nor retroactively (effecting change in data from a date in the past). This is because, by design, the blockchain is designed to be tamper-proof.

Through the use of peer-to-peer (p2p) networking and a time-stamping system, the blockchain system can run autonomously.

In a business transaction context, the blockchain is an open, distributed and immutable ledger that can record verifiable business transactions.

A transaction flow occurring on the blockchain would look like this:

Jane and John wish to conduct a business transaction.
Cryptographic keys are created for the interaction between both Jane and John.
Interaction is broadcasted and verified by a distributed network.
Block is added to the chain once verified.
Transaction between Jane and John is complete.

The ledger can be programmed to trigger transactions automatically without the help of an intermediary or 3rd party.

Because Blockchains are secure by designs and an example of a distributed computing system with high Byzantine (A Game Theory problem the blockchain protocol models after) fault-tolerance (uninterrupted despite the failure of one or more components), they can achieve decentralised consensus (collective agreement). This makes the blockchain suitable for recording not just financial transactions but other record management activities spanning different industries. Furthermore, the blockchain can be used to achieve large-scale cooperation in a distributed and decentralised manner that’ll change the perception of having central control in organisations.

Conclusion

Here is a cap of what you should take home:

The blockchain is an open and distributed database of cryptographically encrypted and interlinked data known as called blocks.
The blockchain is immutable; once data is recorded, it can’t be deleted.
Blockchain is an ideal approach for recording and triggering transactions and events efficiently without the need for an intermediary.
Large-scale cooperation can be achieved in a decentralised manner on the blockchain.

There's more! You can read the part 2 of the introduction here.

Don't forget to share, subscribe and follow me on Twitter for more.

Blockchain Friday

Romeo Agbor Peter — Fri, 28 Oct 2022 02:16:16 +0000

Hi 👋🏿 – These are excerpt taken from the Blockchain Friday newsletter; a pragmatic guide for those interested in a ground knowledge of the technology and its applications.

Who is this newsletter for?

The target audience for this newsletter is anyone who’s an enthusiast or has piqued an interest in blockchain technology. No prior knowledge is required to learn. This is intended to take anyone from ‘beginner’ to ‘knowledgable’.

Stay tuned

For future release, subscribe to the newsletter to receive each issues straight from your email inbox 📥

TypeScript Generics 101

Romeo Agbor Peter — Fri, 01 Jul 2022 18:22:13 +0000

New to TypeScript and get your head to understand what Generics do? This short article if for you.

Generics?

Generics is simply a way to build code components that work with different data types without losing information about that data type. Such components are reusable; they can take in an input of any data type and produce the required output. This allows the component to be flexible.

Without Generics

Here is a TypeScript functions that echos out whatever it's given. without applying the generic method, you'd have to specify the type of the argument or use the any type.

// Specific type
function echo(arg: number): number {
    return arg
}

// Using the 'any' type
function echo(arg: any): any {
    return arg
}

Using specific types will only hold information about that type. Using the 'any' type seems generic but it loses information about the type of data passed in. If you pass a string with a type of 'any,' Typescript will translate the returned type as 'any'; not a string.

The Generic Way

The generic way would be to capture the argument despite the type and denote what is being returned. The 'Type' variable does that. it's a special variable for data type rather than values.

// Using the 'Type' variable
function echo<Type>(arg: Type): Type {
    return arg;
}

The 'Type' variable captures a range of types and holds the information for later use thus making the 'echo' function generic.

Calling Generic Functions

A generic function can be called in two ways. The first is to pass the 'Type' variable argument and the function. This way you explicitly set 'Type' to be a string.

let output = echo<string>("Romeo");

The second way is by calling the function and only passing the argument. Typescript will infer the types automatically for you.

let output = echo("Romeo");

Always use the first way when working on complex code because TypeScript may fail to infer the proper type.

The End

Now you know the 101 of TypeScript Generics. Cheers!

TypeScript for Beginners

Romeo Agbor Peter — Sat, 21 May 2022 13:08:46 +0000

A quick view of the everyday types.

TypeScript has been one interesting thing amongst others that have happened to the JavaScript language in recent years. The superset script has indeed made programming in JavaScript not only safer but much more interesting and approachable (especially to developers coming from languages that use compilers).

It goes without saying that the most errors in JavaScript is the type errors. JavaScript inherently does not provide a type checking system for its code. so one big implication is that developers tend to provide a different value when a certain kind of value was expected.

This article will cover JavaScript's common data types and the equivalent ways to describe and typecheck them using TypeScript. It will not be touching the advanced parts (not necessarily) of TypeScript. What this article will show is the building block of TypeScript code.

Let's go...

This article is a simplified version of the everyday types from the TypeScript docs and assumes you know the fundamentals of javascript.

Installing TypeScript.

TypeScript can be installed in 3 ways: through the NPM registry, as a Visual Studio extension, and through the .NET package registry (NuGet).

You can choose any routes you want for the installation. I have NodeJS installed so that's what I'll be using.

Visit here to download TypeScript.

If you want to jump straight into code while following, you can use this TypeScript playground.

Everyday Types

The essence of TypeScript is to provide make for what the language lacked the most –– a static typechecker. A typechecker runs before the actual code runs to ensure all data types are correct (typechecked) and are used as they should in a program.

Annotating Primitives

JavaScript has three basic primitives data types: string,number and boolean. These form the basic level types in the language.

String represent text like "Hi Romeo".
Number represents a number like 5. Every digit in JavaScript is represented as a number. There aren't special representations like int and float
Boolean represents two values, true and false.

Below is the representation of primitive in JavaScript and the equivalent in TypeScript.

// JavaScript
const name = "Romeo";
const age = 23;
const isChristian = true;

// TypeScript
const name: string = "Romeo";
const age: number = 23;
cont isChrisian: boolean = true;

NOTE:

TypeScript is capable of inferring types automatically in your code. For example, the type of a variable is inferred based on the type of its initializer:

let myName = "Alice";
No type annotation needed -- 'myName' inferred as type
'string'

Arrays

This represent types of an array, say a string of names like ["Romeo", "Waan', "Peter"]. you can use the string[] syntax to do so. It works for other types as well, like numbers (number[]).

// JavaScript
const names = ["Romeo", "Waan", "Maxwell", "Peter"];
const numbers = [23, 5.5, 42, 32];

// Typescript
const names: string[] = ["Romeo", "Waan", "Maxwell", "Peter"];
const numbers: number[] = [23, 5.5, 42, 32];

Any

The any type is special to TypeScript and will cause a value not to be validated by TypeScript for its type. In other words, it won't be typechecked.

When a value has the any type, it and its property can be accessed and manipulated as you normally would in JavaScript without it being typechecked. That means it can be assigned to (or from), called as function and its property, which in turn has a type of any, can be accessed.

// Typescript
let someVariable: any = {name: "Romeo"};
someVariable.bar = 100;
someVariable = (n=10) => n;
someVariable();

NOTE:

The any type can be disabled using the noImplicitAny flag. You'll learn more about TypeScript configuration as we proceed.

Functions

Function annotation in TypeScript is of two types: Parameter Type Annotation and Return Type Annotation.

Parameter Type Annotation

When you declare a function you can annotate the parameters to indicate the types of parameters the function expects. parameter type annotation comes after the parameter is declared, like so:

// JavaScript
function greetRomeo(name) {
    console.log("Hey Romeo, I'm " + name);
}

// TypeScript
function greetRomeo(name: string) {
    console.log("Hey Romeo, I'm " + name);
}

Any argument passed to the greetRomeo function will be checked. In the case above, the name parameter expects a string argument, anything else, say a number, will show an error.

NOTE:

TypeScript is strict about the number of parameters passed to a function. Even without annotation, it'll check that you passed in the right number of arguments.

Return Type Annotation

You can annotate the returned value from a function. Anything value return that doesn't match type annotated will be flagged for error.

JavaScript

function getAge() {
    return 23
}

TypeScript

function getAge(): number {
    return 23
}

Typescript can infer the return type based on the value return. Annotating the type value is mostly for documentation purposes.

Personally, I take documentation quite seriously. Fellow developers shouldn't have to peel their scalp to understand what codebase does.

Anonymous function

When a function is passed as a callback (most often anonymous functions), TypeScript can determine how that function will be called thus inferring the parameter type for such functions.

// No type annotations here, but TypeScript can spot the bug
const names = ["Romeo", "Waan", "Peter"];

// Contextual typing for function
names.forEach(function (s) {
  console.log(s.toUppercase()); // Property 'toUppercase' does not exist on type 'string'. Did you mean 'toUpperCase'?
});

// Contextual typing also applies to arrow functions
names.forEach((s) => {
  console.log(s.toUppercase()); // Property 'toUppercase' does not exist on type 'string'. Did you mean 'toUpperCase'?
});

Notice that the s parameter for both functions –– pure and arrow –– is not annotated, yet TypeScript could infer the correct type because it knows how the anonymous function will work on an array in that context. This is called contextual typing because the context where the function is used is known to TypeScript thus it (TypeScript) can infer the type the function should have.

Object types

Besides primitives, a common form of data type you deal with as a javascript developer is an Object; this is any JavaScript data type with properties and values.

To define an object type, you list the properties and their types. For instance, here's a function that takes an object as a parameter.

// JavaScript

function romeosProfile(profile){
    if (typeof profile === "Object") {
        console.log("Romeo's age is " + profile.name);
        console.log("Romeo's height is " + profile.height);
    }
}
romeosProfile({name: "Romeo", age: 23});

// TypeScript

// The parameter's type annotation is an object type
function romeosProfile(pt: {name: string, age: string}){
    console.log("Romeo's age is " + pt.name);
    console.log("Romeo's height is " + pt.height);
}
romeosProfile({name: "Romeo", age: 23});

The parameter of the function is annotated as an object type. the further annotation of the object type itself is optional which, if done so, will have a type of any.

Optional properties

Object types can specify some optional properties by appending a ? after the property name.

function romeosProfile(obj: {name: string, age?: number}) {
  // ...
}

// Both OK
printName({ name: "Romeo" });
printName({ name: "Romeo",  age: 23 });

Say you didn't provide an argument for the optional parameter and you accessed it, it will return undefined because the property doesn't exist. When reading from an optional property, make sure to check that it's not undefined.

function romeosProfile(pt: {name: string, age?: number}) {

  // Error - might crash if 'pt.age' wasn't provided!
  console.log(pt.age);

  if (pt.age !== undefined) {
    // OK
    console.log(pt.age);
  }

  // A safe alternative using modern JavaScript syntax:
  console.log(pt.age?);
}

Combining Types in TypeScript

The type system in TypeScript allows you to combine and form new types from existing ones.

Union Type

A union type is a type formed by combing two or more other types that represent values of any of the existing types. the combined types are referred to as the union's members.

Here is a function that accepts a string and a number as its parameter.

function printAge(age: number | string) {
    console.log("i'm " + " years old");
}
printAge(23) // I'm 23 years old
printAge("23") // I'm 23 years old
printAge({age: 23}) // Error

Working with Union Type

TypeScript will only allow an operation if it's valid (intersection of type property) for either of the union members. For instance, you can't perform a toUpperCase operation on a string | number union and that's because the operation is only valid for value with a type of string but the type value could be a number.

To get around a union type whose property may not intersect, you use Narrowing –– to "... deduce a more specific type for a value based on the structure of the code."

For instance, using a conditional to let TypeScript know that an operation for a certain type.

function printAge (age: number | string) {
    if (typeof age === "string") {
        console.log(age.toUpperCase());
    } else {
        // age is type of 'number'
        console.log(age)
    }
}

or if member of union type is an array:

function meetFriends(x: string[] | string) {
    if (Array.isArray(x)) {
        console.log("Hello, " +  x.join(" and ") + ". Nice to meet you all!")
    } else {
        // is a string and not an array
        console.log("Hello " + x);
    }
}

As indicated earlier, members of a union type whose value share (intersect) properties don't need narrowing:

function getFirstTime(x: number[] | string) {
    return x.slice(0, 3);
}

Type Aliases

Type aliases allow you to name a type and use it more than once by only referring to it by name. It is a name for any type.

// Object aliase type
type Profile = {
    name: string,
    age: number
}

// Union Type aliase type
type ID = number | string;

With the Profile type alias above, you can pass it as a parameter type for a function by simply referring to the name (Profile).

// Type Profile creates a type structure to be used as parameter type
function getProfile(pt: Profile) {
    console.log("Name: " + pt.name);
    console.log("Age: " + pt.age);
}
getProfile({name: "Romeo", age: 23});

Interfaces

Interfaces are similar to types aliases, and the two can be used interchangeably to create a named type for an object. The only difference is that a type alias can't be added new fields when once created, compared to an interface that is opened to be added more fields.

// Object interface
interface Profile = {
    name: string,
    age: number
}

// Valid and will be combined with above interface
interface Profile = {
    eyeColor: string
}

// Type Profile creates a type structure to be used as parameter type
function getProfile(pt: Profile) {
    console.log("Name: " + pt.name);
    console.log("Age: " + pt.age);
}
getProfile({name: "Romeo", age: 23});

It is generally preferred to use interface when creating a named type for objects, just in case you'd want to add to the existing fields.

interface Profile = {
    name: string,
    age: number,
    eyeColor: string
}


// Object takes the structure of defined interface using Type Assertion
const RomeosProfile: <Profile> {
    name: "Romeo",
    age: 23,
    eyeColor: "black"
}

Type Assertions

Type assertion allows you to declare (assert) a type on a variable so that the compiler won't infer it at runtime. This is because you, as the programmer, could have more information about the type of value that TypeScript can't or at least, it'll infer something not quite right.

Type assertion is similar to typecasting in other languages like C++, C# and java except that there is no runtime effect (all assertions are removed by the compiler) in TypeScript.

for instance, if you're accessing the DOM using document.getElementbyId, TypeScript understands that it'll return an HTMLElement, but you might know specifically that it'll be an HTMLCanvasElement.

You can use a type assertion to specify that:

const myCanvas = document.getElementById("main_canvas") as HTMLCanvasElement;

You can use an angle-bracket to achieve the same effect.

const myCanvas = <HTMLCanvasElement>document.getElementById("main_canvas");

Another instance is asserting an object, similar to the one you saw earlier.

interface Creator { 
    name: string; 
    code: number; 
}

// Using the `as` keyword
let person = {} as Creator; // Ok
person.name = "Romeo";
person.age = 23;


// Using angle-bracket
let person = <Creator> {}; // ok
person.name = "Romeo";
person.age = 23;

NOTE:

When dealing with TypeScript in React (.tsx format), only the as keyword is allowed because using angle-brackets in JSX will create a conflict in the React code.

Literal Types

With literal types, you can create and refer to specific strings and numbers in type positions.

For instance, a variable with a specific string type:

let x: "hello" = "hello";
x = "Howdy"; // Type '"howdy"' is not assignable to type '"hello"'.

When combined to form a union, literals can be used to create complex and useful type structures in type positions.

for instance, a function with a second parameter that only accepts certain values.

function creator(age: number, name: "Romeo" | "Waan" | "Peter"): void {
    console.log(alignment);
};

creator(23,"middle"); // Argument of type '"middle"' is not assignable to parameter of type '"Romeo" | "Waan" | "Peter

creator(23, "Waan") // No error, will log `Waan`

Also, a function that can only return numerical literals:

function compare(a: string, b: string): 1 | -1 | 0 {
    return a === b ? 0 : a < b ? 1 : -1;
}

compare("23", "34"); // No error, will log 1;

Literal types can be combined with non-literal types too.

interface Option {
    width: number;
}

function configure(x: Options | "auto") {
  // ...
}

configure({ width: 100 }); // No error
configure("auto"); // No error
configure("automatic"); // Error: Argument of type '"automatic"' is not assignable to parameter of type 'Options | "auto"'.

Although we didn't use it, the boolean (true and false) literal type can be used to achieve a similar concept as the ones above.

NOTE:

The boolean type is actually an alias that represents the union of true and false.

Alright, that's about it for the everyday types you'll encounter while using or reading TypeScript code. Before I round up things, let's look into configuring TypeScript using the tsconfig.json. file

TS Config

The TypeScript configuration file is tsconfig.json which sits at the root of the project. It's automatically created when the TypeScript is first initialized. The file specifies the root files and compiler options for the project.

Using the `.tsconfig` to compile project.

There are two ways you can do this:

By invoking the tsc CLI command with no input files, in which case the compiler uses the tsconfig.json (starting from the current directory and going the directory chain) file to look for the project file to compile.
By invoking the tsc CLI command with a --project or -p option that specifies the directory to the .tsconfig.json file containing the configuration.

When input files are specified on the command line, the ones specified in the tsconfig.json files are ignored.

Here is a reference to the configuration options you can make as fitting to a project.

Conclusion.

The basis of this article is to get beginners started with building blocks of TypeScript code. The TypeScript documentation answers questions this article fails to provide. Do check it out.

Let's connect on Twitter, I hear that my tweets are quite intriguing.

Cheers!

Django REST Framework TokenAuthentication

Romeo Agbor Peter — Thu, 16 Sep 2021 16:06:12 +0000

This article assumes you're familiar with Django and the basics of the Django REST framework web framework.

Implementing a token authentication in REST framework is not quite straightforward. After browsing the docs and scanning through blog posts, I found an "easy" way to implement the TokenAuthentication scheme.

Before delving in, it's best to explain just a bit what Django REST framework is, and some of its essential concepts.

Django REST Framework (DRF).

The Django REST framework is python framework for building decoupled and "API-first" web application. It allows you to convert your existing Django models to format that translated to and from JSON.

As the name suggests, DRF is built on top of Django framework. In fact, it was built to enable building REST API using the Django framework.

Key Concepts of DRF

Serializer

"Serializer" in DRF allow the serializing and deserializing Django model instances into different representation, such as json. This is done by creating a serializer.py file in the desired directory followed by the corresponding code responsible for doing the serialization.

View

Just as Django has the views.py file responsible for building logic and presenting data to the client in different forms. DRF builds on top that idea and provide its own views for presenting data. They are two ways to represent views in DRF: function-based views and class-based views.

In this post, I'll be using class-based views that'll inherit from REST framework's APIView.

Why the APIView?

It's optimize for content negotiation and setting the correct renderer on the response.
It catches all APIException exceptions and returns appropriate responses.
Incoming requests are inspected and appropriate permission and/or throttle checks will be run before dispatching the request to the handler method.

NOTE

Some developers prefer the naming the views file api.py. This is to keep separated from Django's views.py file.

Requests and responses

The REST framework provides a Response object that extends Django's HttpRequest. The extension allows it to provide a robust way of parsing requests. The Response object provide a request.data attribute that's similar to Django view's request.POST but its more suitable for building web APIs.

Routing

The REST framework has the routermodule for API URL routing to Django. It provides a consistent way of writing view logic to a set of URLs. To create routes for URLs, you create a router.py file in the desired directory and then include it in the Django URLconf (URL configuration).

The implementation in this post will not be using the REST framwork router, but Django's URLconf.

Token authentication

This is an HTTP authentication scheme that uses token as means for verifying and granting access to clients. Only clients with valid token granted access. A token is passed as a payload to the HTTP Authorization header for every request. The server receives the token and checks it with what it has stored. If the tokens match, then the client is verified and given access.

Installation and Configuration

To set up an isolated environment, you have use a virtual environment.

Installing Django & DRF

If the virtual environment is set up and activated, run pip install django djang-restframework in the terminal to install Django and DRF.

To start a project, run python django-admin startproject [project name] to start a new project. I'll be calling mine authentication.

Installed Apps

Django has to recognize and use the REST framework and the token authentication scheme. Add them to the list of installed apps in the settings.py file.

# Application definition

INSTALLED_APPS = [
    ...
    "rest_framework",
    "rest_framework.authtoken"
    ...

]

Setting Authentication Class & Permission.

Still in the settings.py file, the default authentication scheme will be set to TokenAuthentication and permission to AllowAny. The AllowAny is a general setting that applies to all views of application, it allows the client to have access to all available views of the web app. However, this can be further streamlined to restrict certain views to authenticated users only, which you'll see as you move on.

REST_FRAMEWORK = {
    "DEFAULT_AUTHENTICATION_CLASSES": [
        "rest_framework.authentication.TokenAuthentication",
    ],
    "DEFAULT_PERMISSION_CLASSES": [
        "rest_framework.permissions.AllowAny",
    ]
}

Migration.

To apply changes that require database integration (Django comes with default SQLite), they have to be migrated. Run python manage.py migrate to apply such changes.

TokenAuthentication.

TokenAuthentication is differs from SessonAuthentication. No state is created on the server when using a token authentication scheme. Only the validity of the token is checked. If there's a match, the user is granted access, or more definitely, is authenticated.

Create User.

A user account is needed to test the implementations. Django's manage.py command utility can be used to create a super user account.

python manage.py createsuperuser --username johndoe --email johndoe@gmail.com

Test View

Let's create a view with permission set only for authenticated users. Requests sent to the view with an invalid token won't be granted access. The view will handle a GET request that return a message of Hello, World! for valid tokens.

# views.py

from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework.permissions import IsAuthenticated 

class HelloView(APIView):
    permissions_classes = [IsAuthenticated] # <-------- Only authenticated users can access this view

    def get(self, request):
        context = {"message": "Hello, World!"} # <------ Response to the client
        return Response(context)

Add url pattern and view to the URLconf file, urls.py

# urls.py
 from django.urlsconf import path
 from authentication.views import HelloView

urls_patterns = [
    path("/api-token-auth", HelloView.as_view())
]

Let's test the view. A request without token will be sent.

Python has a lightweight HTTP client package called httpie. Install it and follow along.

..authentication> http http://localhost:8000/api-is-authenticated
HTTP/1.1 401 Unauthorized
Allow: GET, HEAD, OPTIONS
...
Content-Type: application/json
...
WWW-Authenticate: Token # <----------- Take note of this
...
{
    "detail": "Authentication credentials were not provided."
}

From the above, the request wasn't authenticated because no [valid] token was associated with the request. Also, if you inspect the header, you'd notice the www-Authentication: Token payload. That is to tell the client that a token is needed to access data on the http://localhost:8000/api-token-auth URL. Later on, we'll test the view again, but with a valid token.

Registration

The registration authentication is responsible for handling registration and creating user account. JSON request from the client will hold the credentials required to create the account. If credentials are valid, the account will be created.

To check if data is valid, it has to cross-check with serialized model data.

Create a serializers.py file and write the following code:


# serializers.py

from django.contrib.auth.models import User

from rest_framework import serializers


class RegistrationSerializer(serializers.ModelSerializer):
     class Meta:
        model = User
        fields = [
            "id", 
            "username", 
            "first_name", 
            "last_name", 
            "email", 
            "password", 
            "is_active", 
            "is_staff"
        ]
        extra_kwargs = {"id": {"read_only": True}, "password": {"write_only": True}}
        read_only_fields

    def create(self, validated_data):

        username = validated_data["username"]
        first_name = validated_data["first_name"]
        last_name = validated_data["last_name"]
        email = validated_data["email"]
        password = validated_data["password"]

        user = User.objects.create_user(
            username=username,
            first_name=first_name,
            last_name=last_name,
            email=email,
            password=password,
        )

        return user

For the view code to handle logic for incoming request. The request will be a POST request.

The view will pass incoming data to the RegistrationSerializer class for validating and creating the user. The serializer will return an object that tells if the data is valid or not. The view will check if data is valid. If valid, it'll save it, generate token, and return response. If not valid, it'll return error response.


# views.py

from django.contrib.auth.models import User

from authentication.serializers import RegistrationSerializer

from rest_framework import serializers
from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework import status
from rest_framework.authtoken.models import Token
from rest_framework import permissions

class RegistrationView(APIView):
     """Registeration View"""

    def post(self, request, *args, **kwargs):
        """Handles post request logic"""
        registration_serializer  = RegistrationSerializer(data=request.data)

        # Generate tokens for existing users
        for user in User.objects.all():
            if not user:
                break
            else:
                try:
                    Token.objects.get(user_id=user.id)
                except Token.DoesNotExist:
                    Token.objects.create(user=user)

        if registration_class.is_valid():
            user = registration_serializer.save()
            token = Token.objects.create(user=user)

            return Response(
                {
                    "user": {
                        "id": serializer.data["id"],
                        "first_name": serializer.data["first_name"],
                        "last_name": serializer.data["last_name"],
                        "username": serializer.data["username"],
                        "email": serializer.data["email"],
                        "is_active": serializer.data["is_active"],
                        "is_staff": serializer.data["is_staff"],
                    },
                    "status": {
                        "message": "User created",
                        "code": f"{status.HTTP_200_OK} OK",
                    },
                    "token": token.key,
                }
            )
        return Response(
             {
                "error": serializer.errors,
                "status": f"{status.HTTP_203_NON_AUTHORITATIVE_INFORMATION} \ 
                    NON AUTHORITATIVE INFORMATION",
            }
        )

next, create the URL pattern and add the view responsible for handling request to the URL.

# urls.py from django.urlsconf import path from authentication.views import RegistrationViewurls_patterns = [    #...    path("/api-register-auth", RegistrationView.as_view())]

Lastly, test the RegistrationView . It should return the appropriate response with a token if required and valid credentials are provided.

http --json POST http://localhost:8000/api/auth/register username="JamesChe" email="jamesuche@gmail.com" first_name="james" last_name="uche" password="jamesuche123456"{    "status": {        "code": "200 OK",        "message": "User created"    },    "token": "b4784f96c3c65387bc8ea6463d5d4658cb32b0ac",    "user": {        "id": 2,        "first_name": "james",        "last_name": "uche",        "username": "JamesChe",        "email": "jamesuche@gmail.com",        "is_active": true,        "is_staff" true,    }}

Login

Implementing Login authentication using the REST framework is quite straightforward. There are two way to achieve setting up a login view: using built-in view or a custom view.

Using `obtain_auth_token` view.

REST framework provides the built-in obtain_auth_token view for creating and retrieving tokens for authenticated user.

Clients can obtain token using registered credential. The username and password are what's required. Once the view confirms the credentials, It'll obtain the token if it exists or create a new one.

In the urls.py file, import as follows: from rest_framework.authtoken.views import obtain_auth_token then add the view to the URLconf.

# urls.pyfrom rest_framework.authtoken.views import obtain_auth_tokenurl_patterns + [    path("/api-token-auth", obtain_auth_token.as_views())]

NOTE:

The naming of the URL pattern can be whatever you want.

To get token, the client have to send a post request to the URL. The client must provide the username and password of the registered user.

..authentication> http post http//localhost:800/api-token-auth/ username="johndoe" password=123456HTTP/1.1 200 OKAllow: OPTION, POSTSContent-Type: application/json......{  "token": "bad492c010451bcba6acf7437706b8dd30eb11d5"}

Remember the earlier HelloView view? Let's test it by sending a GET request to its URL, this time with the token we just got.

..authentication> http http://localhost:8000/api-hello "Authorization: Token bad492c010451bcba6acf7437706b8dd30eb11d5"HTTP/1.1 200 OKAllow: GET, HEAD, OPTIONS.........{    "message": "Hello, World!" # <------------ Message because user token is valid.}

And there! We're now able to access the view without restriction. the expected Hello, World! message is returned rather than a restriction message.

Using Custom View

Certain cases require extra data about the authenticated user be sent as response to the client. That "extra" data could be on a database. To retrieve such data, a serializer is needed to convert them to python native code format for easy serializing. The view will handle the necessary related logic and send response to the client.

Two serializer classes are needed for this: one to verify the user credentials and the other to return the necessary response.

# Serializers.pyfrom django.contrib.auth.models import Userfrom rest_framework import serializersclass UserLoginSerializer(serializers.Serializer):    """Login serializer"""        username = serializers.CharField(required=True)    password = serializers.CharField(required=True, read_only=True)class UserLoginResponse(serializers.ModelSerializer):    """Response serializer"""        class Meta:        model = User        fields = "id, username, first_name, last_name, email, password, is_active, is_staff"        read_only_fields = ["id", "password", "is_active", "is_staff"]

Next, in the views.py file, the view has to check if the incoming data from the request is a valid data using the serializer. If it's not it'll return a serializer error. if the data is valid, the credentials will be authenticate and a response message with the generated or obtained token will be sent back to the client.

# views.pyfrom django.contrib.auth.models import Userfrom authentication.serializers import LoginSerializerfrom authentication.serializers import LoginResponseSerializerfrom rest_framework import serializersfrom rest_framework.views import APIViewfrom rest_framework.response import Responsefrom rest_framework import statusfrom rest_framework.authtoken.models import Tokenfrom rest_framework import permissionsfrom django.contrib.auth import authenticateclass LoginView(APIView):    """Login View"""        permissions_classes = [permissions.isAuthenticated]        def post(self, request, *args, **kwargs):        login_serializer = LoginSerializer(data=request.data)                if login_serializer.is_valid():            user = authenticate(request, **serializer.data)                        if user is not None:                response_class = LoginResponseSerializer(user)                token, created_token = Token.objects.get_or_create(user_id=user.id)                                if isinstance(created_token, Token):                    token = created_token.key                                return Response(                    {                        "user": response_serializer.data,                        "status": {                            "message": "User Authenticated",                            "code": f"{status.HTTP_200_OK} OK",                        },                        "token": token.key,                    }                )            else:                raise serializers.ValidationError(                {                    "error": {                        "message": "Invalid Username or Password. Please try again",                        "status": f"{status.HTTP_400_BAD_REQUEST} BAD REQUEST",                    }                }            )                return(            {                "error": serializer.errors,                "status": f"{status.HTTP_403_FORBIDDEN} FORBIDDEN"            }        )

Create URL pattern and add view to URLConf file.

# urls.pyfrom django.urls import pathfrom authentication.views import LoginViewurlpatterns = [    #...    #...    path("/api-login-auth", views.LoginView),]

To test out the custom view, send a POST request with the required user credentials as JSON.

..authentication> http --json post http//localhost:800/api-login-auth username="johndoe" password=123456HTTP/1.1 200 OKAllow: OPTION, POSTS...Content-Type: application/json......{    "status": {        "code": "200 OK",        "message": "User Authenticated"    },    "token": "bad492c010451bcba6acf7437706b8dd30eb11d5",    "user": {        "email": "johndoe@gmail.com",        "first_name": "",        "id": 1,        "is_active": true,        "is_staff": true,        "last_name": "",        "username": "johndoe"    }}

Conclusion

Implementing TokenAuthentication in Django REST framework can be steep at first. But it start to make sense when you understand the concept: Rather having a session on the server, a token is instead created and is used to verify the user on every request.

I recommend using the REST framework APIView classes-bases for easy work. Only when keep repeating yourself should you look into other class-based to reduce repetition.

If all the application needs is just the token, then use the built-in obtain_auth_token view for that.

Customs views may need extra data returned to the user, in this case you should create extra serializer classes to achieve that.

I'll appreciate your feedback on this post. Cheers!

DEV Community: Romeo Agbor Peter

Developers should be asking more questions: - "Why does this exist?” - "Who is this for?” - “What problem does this actually solve?” - "Can I see the briefing on this"? We're creators, not a code monkeys.

10X Developers Don’t Just Ship Code; They Ship the Business.

10X Developers Don’t Just Ship Code; They Ship the Business.

Phone Book Binary Search With Python.

What is a Binary Search?

Programmatic Approach to Using a Binary Search.

Code implementation.

Conclusion

Python Normal Classes vs. Data Classes: Which Should You Use?

What are Normal Classes?

What are Data Classes?

differences between Normal and Data classes

Conclusion

Practical Implementation of the blockchain.

Blockchain in the Fintech.

Blockchain in Real estate.

Blockchain in a decentralised economy.

Blockchain in the legal system.

Blockchain as decentralised file hosting.

Conclusion

Motivation for Blockchain and its application as an information technology system.

Money the Motivator.

A Distributed Information Technology Part 1.

Conclusion

Introduction to Blockchain: Part 2

Blockchain as Peer-to-peer System.

Conclusion

Introduction to blockchain Part 1.

Conclusion

Blockchain Friday

Who is this newsletter for?

Stay tuned

TypeScript Generics 101

Generics?

Without Generics

The Generic Way

Calling Generic Functions

The End

TypeScript for Beginners

A quick view of the everyday types.

Installing TypeScript.

Everyday Types

Annotating Primitives

Arrays

Any

Functions

Parameter Type Annotation

Return Type Annotation

Anonymous function

Object types

Optional properties

Combining Types in TypeScript

Union Type

Working with Union Type

Type Aliases

Interfaces

Type Assertions

Literal Types

TS Config

Using the .tsconfig to compile project.

Conclusion.

Django REST Framework TokenAuthentication

Django REST Framework (DRF).

Key Concepts of DRF

Serializer

View

Requests and responses

Routing

Token authentication

Installation and Configuration

Installing Django & DRF

Installed Apps

Setting Authentication Class & Permission.

Migration.

TokenAuthentication.

Create User.

Test View

Registration

Login

Using the `.tsconfig` to compile project.

Using `obtain_auth_token` view.