
Supabase's value proposition is to "give superpowers to your (SQL) database". When working with Supabase – and thereby SQL –, we go to great lengths to create a structured data model with tables and relations. It would be a shame then, that once we use this structured data in our JavaScript app, we lose all that structure and are left to deal with `any` types.

In this tutorial, we're going to learn how to use TypeScript to make our Supabase app more robust, and easier to code. This tutorial is framework-agnostic: whether you're using React, Vue, or vanilla JavaScript (that is, TypeScript), you'll be able to use the examples and methods outlined. I will assume that you already have some rudimentary knowledge of both SQL and TypeScript, and are comfortable executing simple commands in your terminal.

## TypeScript in the Supabase JavaScript client
When interacting with a Supabase app using the `@supabase/supabase-js` client, database calls usually start with:

```js
supabaseClient.from('table') //...
```

The `from` method of the Supabase client is generic in one type variable `T` which defaults to `any`. The signature of the `from` method is:

```js
from<T = any>(table: string): SupabaseQueryBuilder<T>
```

This type parameter is passed down to the query builder, and goes on to be used when you call `select`, `insert`, and all other database methods you're already used to using with Supabase. For example, in the case of a `select`, `await`ing the result of the operation will get you back an object of type `PostgrestResponseSuccess<T>`, which is defined as:

```js
interface PostgrestResponseSuccess<T> extends PostgrestResponseBase {
  error: null
  data: T[]
  body: T[]
  count: number | null
}
```

The gist of it is that calling `select<any>` on a Supabase project will get you back an array of `any` as the `data` property of the response. If you were able to pass your own type when calling `from('table')`, then you'd get back a response where the `data` property would be an array of that type. You can certainly create these types manually, but that is error prone. The Supabase team is currently working on a solution to generate the types automatically from your database schema, but meanwhile they have a [temporary solution](https://supabase.com/docs/reference/javascript/generating-types), which consists in using the `openapi-typescript` NPM package to introspect the OpenAPI specification generated from your database schema. In this tutorial we're going to explore the solution provided by the Supabase team, and expand on it to make it more easily usable.

## Defining a schema
For the purposes of this tutorial, we'll be defining the following tables:

```sql
create table public.posts (
	id uuid primary key default uuid_generate_v4(),
	user_id uuid not null references auth.users,
	title text not null,
	content text
);

create table public.comments (
	id uuid primary key default uuid_generate_v4(),
	user_id uuid not null references auth.users,
	post_id uuid not null references public.posts,
	content text
);
```

If you want to follow along, you can create a new Supabase project and execute the above SQL in the SQL Editor. Note that since our goal is to explore the types, we're not dealing with Row-Level security and associated policies here: they don't affect the generated types.

## Generating the types
With this schema created, we can now generate the types using `openapi-typescript`. To do this, we need to have the URL of our Supabase project, as well as the anon-key. These can be found under the Settings > API section of Supabase Studio. Armed with these two values, execute the following command in your terminal:

```sh
npx openapi-typescript https://<YOUR URL>.supabase.co/rest/v1/?apikey=<YOUR anon-key> --output generated-types.ts
```

After a few seconds, you'll have a new file called `generated-types.ts` in the directory where you executed the command. If you open this file, you'll find that the types generated contain more than what we need for the purposes of this tutorial. They contain types for API paths, parameters, and others. The types of interest to us are defined under the `definitions` interface, and they look like this:

```js
export interface definitions {
  comments: {
    /**
     * Format: uuid
     * @description Note:
     * This is a Primary Key.<pk/>
     * @default extensions.uuid_generate_v4()
     */
    id: string;
    /** Format: uuid */
    user_id: string;
    /**
     * Format: uuid
     * @description Note:
     * This is a Foreign Key to `posts.id`.<fk table='posts' column='id'/>
     */
    post_id: string;
    /** Format: text */
    content?: string;
  };
  posts: {
    /**
     * Format: uuid
     * @description Note:
     * This is a Primary Key.<pk/>
     * @default extensions.uuid_generate_v4()
     */
    id: string;
    /** Format: uuid */
    user_id: string;
    /** Format: text */
    title: string;
    /** Format: text */
    content?: string;
  };
}
```

Notice that the `definitons` interface has one entry for `posts`, and another one for `comments`. The fields marked as `NOT NULL` in the schema are mandatory in the corresponding TypeScript type, and those that are not, like the `content`, are optional. You'll also note that despite our `id`s being defined as `uuid` in the database, the corresponding TypeScript type is `string`: there's no native UUID type in TypeScript, so that's the best the automated tool can do.

## Using the generated types
The easiest way to use these generated types is to pass them directly to the type parameter of the `from` method of the Supabase client. For example, to fetch typed posts, you can do:

```js
const result = await supabaseClient.from<definitions['posts']>('posts').select('*');
console.log(result.data[0].title)
```

And you'll get the full benefits of TypeScript's type checking, as can be seen in the following screenshot from a VS Code session:

![TypeScript suggestions from supabase query](typescript-suggestions-supabase-select-query.png)

In addition to the suggestions you get from TypeScript, you'll notice that `result.data` is underlined with a red squiggle: TypeScript is warning us that `result.data` could be `null` here. To comply, we can either wrap the `console.log` in an `if (result.data)` block, or use `result.data?.[0].title` depending on our needs.

## Making the generated types easier to use
Having to type `from<definitions['posts']>` every time we want to query a post is verbose. To help with this, we can define our own types. Rather than work in the `generated-types.ts` file, let's create our own `types.ts` module. This way, as we change our schema and re-generate the types, our own code won't be overwritten.

```js
import type { definitions } from './generated-types';

export type Post = definitions['posts'];
export type Comments = definitions['comments'];
```

Then, when we want to query these entities, we can import the aliased types instead:

```js
import type { Post } from './types';

await supabaseClient.from<Post>('posts').select('*') //...
```

Even that can get a little verbose over time. We can still make mistakes by using the wrong type and table name combination, mistype the table name, etc. We can define some helper functions to alleviate this. Let's do that in a module called `db.ts`:

```js
import type { Post, Comment } from './types';

export const db = {
	posts: () => supabaseClient.from<Post>('posts'),
	comments: () => supabaseClient.from<Comment>('comments'),
};
```

Then, in our application code, we can simply do:

```js
import { db } from './db';

await db.posts().select('*')//...
```

We don't need to explicitly type the `db` variable, TypeScript will automatically infer its type based on the return values of the functions defined there.

## Types for nested relations
Our example schema defines entities Post and Comment in such a way that a post can have multiple comments. Supabase allows us to retrieve posts with their comments using the following `select` syntax:

```js
supabaseClient.from('posts').select(`
*,
comments(*)
`)
```

What would be the return type of such a query? We'd still get posts, but each post would have an array of comments associated to it. We can easily compose the types we have so far and create a `PostWithComments` type like this:

```js
type PostWithcomments = Post & {
	comments: Comment[];
}
```

## Types for partial selections
When fetching large quantities of rows, we sometimes want to project only a portion of the available data. For example, if we have a page where we're listing all posts in our database, we only need the `id` and the `title` of these posts. Fetching the `content`, arguably the heaviest field in the dataset, would be counter-productive. For this reason, both SQL and Supabase allow us to select a limited set of fields from our tables. For example, to fetch the post `id`s and `title`s only, we can do:

```js
supabaseClient.from('posts').select('id, title')//...
```

If we were to use our `Post` type here, TypeScript wouldn't complain. After all, TypeScript has absolutely no idea what kind of data we're getting back, since that data is completely dynamic and is coming from a JSON API. Somewhere in the depths of the libraries we're using, there's a `JSON.parse` in there which turns the API response from PostgREST into JavaScript objects, and the library is simply telling TypeScript that these are of a certain type.

What more, nothing is preventing us from selecting columns that don't exist in the database. As our schema is changing and our app is getting larger, it would be nice if the newly generated types could warn us of these things.

Here's an example of a utility function that allows us to select only certain fields from posts in a type-safe way, both for the columns we're selecting and for the data type being returned:

```js
function selectFromPosts<F extends keyof Post>(columns: F[]) {
	return supabaseClient.from<Pick<Post, F>>('posts').select(columns.join(', '));
}

// Example usage
const postsForHomepage = await selectFromPosts(['id', 'title']);
```

There's a lot going on here so let's look at it part by part:

* First, you'll note that this function has a generic type `F extends keyof Post`. `keyof` is a TypeScript type operator which returns a union type of all the keys of the type we call it on. In this case, `keyof Post` is the union type `'id' | 'user_id' | 'title' | 'content'`.
* The function defines a single parameter `columns` which is an array of `F`, that is, an array of strings that are keys of `Post`.
* The function calls `from` with the type `Pick<Post, F>`. `Pick` is a utility type that is the TypeScript "equivalent" of lodash's `_.pick` function: it takes a type, and keys from that type, and returns a new type composed of only those keys. In this case, if `F` turns out to be `'title' | 'content'`, then `Pick<Post, F>` will be the type `{ title: string; content?: string }`.
* Finally, and most importantly, you'll note that when calling `selectFromPosts` in the example above, we don't pass a type parameter. This is where all the magic happens, by virtue of TypeScript's inference. When calling `selectFromPosts`, TypeScript is able to see, at compile-time, that we're passing an array with `'id'` and `'title'`. From this, it's able to _infer_ that `F` is `'id' | 'title'` without us having to explicitly state that. This inferred `F` is then used as a type parameter in `Pick`, and since we're returning the result of that `select`, TypeScript is able to infer that this call to `selectFromPosts` will return a response whose `data` property will be an array of `{ id: string; title: string }` :fire:

## Conclusion
I hope you found the methods described above to be useful to you. If anything, the examples I've used should inspire you to build your own types and functions on top of the Supabase client to make your application more robust, type-safe, and easier to write and read.

In a future blog post, I'll be expanding on these examples by looking at an interesting technique called "flavoring". This technique will allow us to distinguish between values that _should_ have different types, but are all typed as `string`, such as the UUID `id`s of the entities above. Meanwhile, let's go ship some type-safe Supabase code! :rocket:

In this article, we'll learn how to use automatic TypeScript types generation for a Supabase project, and how to use these types in an app

Using Supabase with TypeScript

In this tutorial, we'll learn how and when to use React hooks and states by building a useful OTP code component. In the process, we'll learn about controlled and uncontrolled inputs.

Learning about React hooks and state - Part 2: Building a custom input

In this tutorial, we'll learn how and when to use React hooks and states by building a custom OTP input component.

Learning about React hooks and state by example

In this tutorial, we'll be creating a blog with React and Next.js. For content management, the blog will be backed by WordPress.

Let's make a WordPress-based blog with React and Next.js


## Introduction
Articles exploring new technologies abound.  In this post, I want to go back to the basics and build a simple web server from scratch with NodeJS. In doing so, we will review the structure of HTTP requests and responses and get an introduction to [Node's `Stream` API](https://nodejs.org/api/stream.html).

First, we will quickly review [Node's built-in `http` module](https://nodejs.org/api/http.html). Following that, we will study the general structure of an HTTP request and response. Then, using Node's built-in `net` module, we will create a low-level TCP server and try to make a usable web server out of it.

It goes without saying that all of the code in this article has no business in any production app. It is only provided for educational value.

With that out of the way, let's get started!

## A quick look at Node's built-in `http` module
NodeJS comes with a simple HTTP server built in. This server allows us to listen on an arbitrary port and provide a callback function that will be invoked on every incoming request. 

The callback will receive two arguments: a [Request object](https://nodejs.org/dist/latest-v6.x/docs/api/http.html#http_class_http_incomingmessage) and a [Response object](https://nodejs.org/dist/latest-v6.x/docs/api/http.html#http_class_http_serverresponse). The Request object will be filled with useful properties about the request, and the Response object will be used to send a response to the client.

The "hello world" example using Node's `http` server:

```js
const http = require('http');
const server = http.createServer();
server.on('request', (req, res) => {
  console.log(`${new Date().toISOString()} - ${req.method} ${req.url}`);
  res.setHeader('Content-Type','text/plain');
  res.end('Hello World!');
});
server.listen(3000);
```

This will start a web server listening on port 3000. When a request comes in, a message will be logged in the console with the current date followed by the request's method and URL. 

This data comes from the parameter `req`, which is the Request object created by Node. This Request object also has a property called `.socket`, which is the lower-level TCP socket. 

Later on, we will be creating a TCP server and getting direct access to this socket for each new connection, then using it to make our web server.

In the code above, the fact that we have access to a nice object with `req.method` and `req.url` means that someone other than us went through the trouble of parsing the text of the request and making it into a nice object. 

In the next section, we'll look at the structure of an HTTP request to get hints on how to parse it.

## Dissecting HTTP
Here is a sample HTTP request:

```
POST /posts/42/comments HTTP/1.1\r\n
Host: www.my-api.com\r\n
Accept: application/json\r\n
Authorization: Bearer N2E5NTU2MzQ5MGQ4N2UzNjIxOTY2ZDU1M2YwNjA3OGFjYjgyMjU4NQ\r\n
Accept-Encoding: gzip, deflate, br\r\n
Content-Type: application/json\r\n
Content-Length: 28\r\n
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:58.0)\r\n
\r\n
{"text":"this is a comment"}
```

A few observations:
* Each line is delimited by `\r\n`.
* The first line is called the "request line." It's composed of three space-separated tokens:
  * The request method, `POST`. The standard methods are defined in [section 9 of the HTTP/1.1 specification](https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html).
  * The request URI, `/posts/42/comments`
  * The protocol version, `HTTP/1.1`
* Each following line is called a request header. It's composed of a field and its value, separated by a `:`. The standard headers are defined in [section 14 of the HTTP/1.1 specification](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html).
* There's a line with only `\r\n`. This line indicates the end of the request header. Anything after that is the request body.
* For this request, the body is a JSON document. This matches the `Content-Type` header. The JSON document is 28 bytes long, which matches the `Content-Length` header.

And this is a sample HTTP response:

```
HTTP/1.1 200 OK\r\n
Server: nginx/1.9.4\r\n
Date: Fri, 20 Apr 2017 16:19:42 GMT\r\n
Content-Type: application/json\r\n
Content-Length: 141\r\n
\r\n
{
  "id": "8fh924b42o",
  "text": "this is a comment",
  "createdAt": "2017-04-20T16:19:42.840Z",
  "updatedAt": "2017-04-20T16:19:42.840Z"
}
```

Again, a few observations:
* Like the request, each line is delimited by `\r\n`.
* The first line is called the "status line." It's composed of:
  * The HTTP version, `HTTP/1.1.1`
  * An [HTTP status code](https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10), `200`
  * A [reason phrase](https://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6), `OK`
* Each line after that is a response header, with the same structure as request headers.
* There's a line with only `\r\n`. This indicates the end of the response header and the start of the response body.
* The body is a 141-byte JSON document. This matches the values in the response headers.

In the next section, we will create a TCP server and be able to observe an HTTP request coming in, chunk by chunk. We will see how to read and parse the request, then send a response using Streams.

## Receiving and parsing an HTTP request
NodeJS provides the built-in `net` module to create a streaming TCP server. "Streaming" refers to the fact that the server can send and receive data over time, using [Node's `Stream` API](https://nodejs.org/api/stream.html).

Where the `http` server emitted a `request` event with Request and Response objects, the TCP server will emit a `connection` event with a Socket object. Socket objects are [Duplex Streams](https://nodejs.org/api/stream.html#stream_class_stream_duplex). In short, this means that they can both be read from and written to.

If we make an HTTP request to our TCP server, reading from the Socket will give us the text of the request. There are two ways to read from a readable stream: subscribing to its `data` event, or calling its `.read()` method. Let's look at the first one:

```js
const net = require('net');
const server = net.createServer();
server.on('connection', handleConnection);
server.listen(3000);

function handleConnection(socket) {
  socket.on('data', (chunk) => {
    console.log('Received chunk:\n', chunk.toString());
  });
  socket.write('HTTP/1.1 200 OK\r\nServer: my-web-server\r\nContent-Length: 0\r\n\r\n');
}
```

Put this code in a file called `server.js` and execute it from your command line with `node server.js`. In another terminal, use cURL to make a simple request to your server:

```
curl -v localhost:3000/some/url
```

You should see a verbose output from cURL, showing you the request and response headers. In the Node terminal, you should see something like this:

```
Received chunk:
GET /some/url HTTP/1.1
Host: localhost:3000
User-Agent: curl/7.54.0
Accept: */*

```

Let's make a `POST` request with some data:

```
curl -v -XPOST -d'hello=world' localhost:3000/some/url
```

This should give you the following output in your Node terminal:

```
Received chunk:
POST /some/url HTTP/1.1
Host: localhost:3000
User-Agent: curl/7.54.0
Accept: */*
Content-Length: 11
Content-Type: application/x-www-form-urlencoded

hello=world
```

If you were to send a longer request body, you would receive it in multiple chunks. But **a web server doesn't always need to process a request's body**. 

Often, the header part of a request is sufficient to start processing the request. Since we are writing a generic web server, we have to find a way to stop receiving request data from the socket as soon as we reach the string `\r\n\r\n` in the input. 

This is more easily done by using the `.read()` method of the socket, since we can control when to stop pulling data from the stream. Here's some code to do this:

```js
const net = require('net');
const server = net.createServer();
server.on('connection', handleConnection);
server.listen(3000);

function handleConnection(socket) {
	// Subscribe to the readable event once so we can start calling .read()
	socket.once('readable', function() {
		// Set up a buffer to hold the incoming data
		let reqBuffer = new Buffer('');
		// Set up a temporary buffer to read in chunks
		let buf;
		let reqHeader;
		while(true) {
			// Read data from the socket
			buf = socket.read();
			// Stop if there's no more data
			if (buf === null) break;

			// Concatenate existing request buffer with new data
			reqBuffer = Buffer.concat([reqBuffer, buf]);

			// Check if we've reached \r\n\r\n, indicating end of header
			let marker = reqBuffer.indexOf('\r\n\r\n')
			if (marker !== -1) {
				// If we reached \r\n\r\n, there could be data after it. Take note.
				let remaining = reqBuffer.slice(marker + 4);
				// The header is everything we read, up to and not including \r\n\r\n
				reqHeader = reqBuffer.slice(0, marker).toString();
				// This pushes the extra data we read back to the socket's readable stream
				socket.unshift(remaining);
				break;
			}
		}
		console.log(`Request header:\n${reqHeader}`);

		// At this point, we've stopped reading from the socket and have the header as a string
		// If we wanted to read the whole request body, we would do this:

		reqBuffer = new Buffer('');
		while((buf = socket.read()) !== null) {
			reqBuffer = Buffer.concat([reqBuffer, buf]);
		}
		let reqBody = reqBuffer.toString();
		console.log(`Request body:\n${reqBody}`);

		// Send a generic response
		socket.end('HTTP/1.1 200 OK\r\nServer: my-custom-server\r\nContent-Length: 0\r\n\r\n');
	});
}
```

The code is a bit longer because we need some logic to decide when to stop reading from the stream. This allows us to separate the header from the body and let the developer who will use our web server determine what to do with the body, if anything.

The key part here is the `socket.unshift` line, which "puts back" any extra data we read back into the readable stream. This will allow us to pass this socket along to our user in case they need to read from it.

And here's the full code of our basic web server, putting together everything we have seen so far. Our server exposes a function `createWebServer(requestHandler)`. This function accepts a handler of the form `(req, res) => void`, just like Node's basic web server. The comments in the code explain what each step is doing.

```js
const net = require('net');

function createWebServer(requestHandler) {
	const server = net.createServer();
	server.on('connection', handleConnection);
	
	function handleConnection(socket) {
		// Subscribe to the readable event once so we can start calling .read()
		socket.once('readable', function() {
			// Set up a buffer to hold the incoming data
			let reqBuffer = new Buffer('');
			// Set up a temporary buffer to read in chunks
			let buf;
			let reqHeader;
			while(true) {
				// Read data from the socket
				buf = socket.read();
				// Stop if there's no more data
				if (buf === null) break;
	
				// Concatenate existing request buffer with new data
				reqBuffer = Buffer.concat([reqBuffer, buf]);
	
				// Check if we've reached \r\n\r\n, indicating end of header
				let marker = reqBuffer.indexOf('\r\n\r\n')
				if (marker !== -1) {
					// If we reached \r\n\r\n, there could be data after it. Take note.
					let remaining = reqBuffer.slice(marker + 4);
					// The header is everything we read, up to and not including \r\n\r\n
					reqHeader = reqBuffer.slice(0, marker).toString();
					// This pushes the extra data we read back to the socket's readable stream
					socket.unshift(remaining);
					break;
				}
			}
			
			/* Request-related business */
			// Start parsing the header
			const reqHeaders = reqHeader.split('\r\n');
			// First line is special
			const reqLine = reqHeaders.shift().split(' ');
			// Further lines are one header per line, build an object out of it.
			const headers = reqHeaders.reduce((acc, currentHeader) => {
				const [key, value] = currentHeader.split(':');
				return {
					...acc,
					[key.trim().toLowerCase()]: value.trim()
				};
			}, {});
			// This object will be sent to the handleRequest callback.
			const request = {
				method: reqLine[0],
				url: reqLine[1],
				httpVersion: reqLine[2].split('/')[1],
				headers,
                // The user of this web server can directly read from the socket to get the request body
				socket
			};

			/* Response-related business */
			// Initial values
			let status = 200, statusText = 'OK', headersSent = false, isChunked = false;
			const responseHeaders = {
				server: 'my-custom-server'
			};
			function setHeader(key, value) {
				responseHeaders[key.toLowerCase()] = value;
			}
			function sendHeaders() {
				// Only do this once :)
				if (!headersSent) {
					headersSent = true;
					// Add the date header
					setHeader('date', new Date().toGMTString());
					// Send the status line
					socket.write(`HTTP/1.1 ${status} ${statusText}\r\n`);
					// Send each following header
					Object.keys(responseHeaders).forEach(headerKey => {
						socket.write(`${headerKey}: ${responseHeaders[headerKey]}\r\n`);
					});
					// Add the final \r\n that delimits the response headers from body
					socket.write('\r\n');
				}
			}
			const response = {
				write(chunk) {
					if (!headersSent) {
						// If there's no content-length header, then specify Transfer-Encoding chunked
						if (!responseHeaders['content-length']) {
							isChunked = true;
							setHeader('transfer-encoding', 'chunked');
						}
						sendHeaders();
					}
					if (isChunked) {
						const size = chunk.length.toString(16);
						socket.write(`${size}\r\n`);
						socket.write(chunk);
						socket.write('\r\n');
					}
					else {
						socket.write(chunk);
					}
				},
				end(chunk) {
					if (!headersSent) {
						// We know the full length of the response, let's set it
						if (!responseHeaders['content-length']) {
							// Assume that chunk is a buffer, not a string!
							setHeader('content-length', chunk ? chunk.length : 0);
						}
						sendHeaders();
					}
					if (isChunked) {
						if (chunk) {
							const size = (chunk.length).toString(16);
							socket.write(`${size}\r\n`);
							socket.write(chunk);
							socket.write('\r\n');
						}
						socket.end('0\r\n\r\n');
					}
					else {
						socket.end(chunk);
					}
				},
				setHeader,
				setStatus(newStatus, newStatusText) { status = newStatus, statusText = newStatusText },
				// Convenience method to send JSON through server
				json(data) {
					if (headersSent) {
						throw new Error('Headers sent, cannot proceed to send JSON');
					}
					const json = new Buffer(JSON.stringify(data));
					setHeader('content-type', 'application/json; charset=utf-8');
					setHeader('content-length', json.length);
					sendHeaders();
					socket.end(json);
				}
			};
			
			// Send the request to the handler!
			requestHandler(request, response);
		});
	}

	return {
		listen: (port) => server.listen(port)
	};
}

const webServer = createWebServer((req, res) => {
	// This is the as our original code with the http module :)
	console.log(`${new Date().toISOString()} - ${req.method} ${req.url}`);
	res.setHeader('Content-Type','text/plain');
	res.end('Hello World!');
});

webServer.listen(3000);
```

As mentioned in the beginning of this post, this server code has no business being used in production. Its only purpose is to learn more about streams and buffers.

Most of the code in there should be self explanatory. We are parsing the request and sending the response using the rules we learned in the previous section. 

The only new bit is the `Transfer-Encoding: chunked`, which is necessary when we don't know in advance the length of the response. You can [learn more about chunked transfer encoding on Wikipedia](https://en.wikipedia.org/wiki/Chunked_transfer_encoding).

## Conclusion
By using some lower-level building blocks such as `net`, `Stream`, and `Buffer`, we were able to create a rudimentary HTTP server based on a TCP server and some parsing logic. In the process, we learned a bit about how HTTP requests and responses work, as well as the basics of readable and writable streams and buffers.

In this article, we'll learn to use NodeJS Readable, Writable, and Duplex Streams to create a rudimentary HTTP server.

Fullstack Consultant

Ziad Saab

Check out my latest posts