Forem: hoaitx

Compilation of Libraries Supporting CLI Application Development for Node.js

hoaitx — Tue, 21 Jan 2025 04:19:00 +0000

Hello everyone. I wonder if anyone here has been using command-line applications (CLI)? If so, why did you choose it over a graphical user interface (GUI)? If I remember correctly, I have written a few articles about the process of creating some applications for myself. Honestly, for me, there are many cases where CLI proves to be much more useful.

Recalling my early days of switching from Windows to Linux, specifically Ubuntu. I have cursed countless times about this damn operating system. The interface is ugly, hard to use, and everything requires typing commands; how can anyone remember all those lines? It’s not like Windows is good. The interface is intuitive and easy to use. You just need to look to know where to click, everything is visible.

True to the saying, "what you hate, fate gives you". In the end, I became "addicted" to this command-line typing without even noticing. There must be a reason for this addiction; it helps me approach problems faster. Instead of moving the mouse around, I can just type, which is much quicker. Not to mention that many software applications are provided in CLI form, which in turn leads to the creation of management tools, allowing us to easily install our favorite applications with just a single command.

That was also the inspiration for me to tackle problems using CLI. Most of it is to help manage my blog. In the early days of exploring, there were so many new things that I didn’t know. It took a lot of time to learn while doing. Understanding that psychology, today I will compile some libraries that I know from my previous learning process. These libraries not only help you create quality applications but also make them more appealing to users.

Oh! All of these are Node.js libraries. If you are using other platforms like Go, Rust… I’m sure there are similar libraries. You just need to search based on the ideas of the libraries below.

Let's get started!

Framework

First, we need to talk about the framework; this is where you structure your CLI application. Imagine the framework helps shape, structure the code, and features to fit the nature of the CLI.

Notice that we often see command-line applications using a format like this:

$ mycli image --resize 512:512 /path/to/image

With mycli being the application name, image is almost a function, and the flag --resize is typically used to specify additional attributes. Finally, /path/to/image points to the data that needs to be processed.

If you are familiar with Node.js, you will see that CLI is quite similar to the node command, while the following parameters can easily be captured through the process.argv variable.

$ node index.js image --resize 512:512 /path/to/image
// console.log(process.argv); ['node', 'index.js', 'image', '--resize', '512:512', '/path/to/image']

In other words, just parsing process.argv is sufficient to classify and call the corresponding functions with the used parameters. At that point, the application is no different from a CLI.

yargs and commander are two foundational libraries to help us parse parameters as mentioned above. They provide very basic functions to serve as a foundation for other libraries.

oclif is one example. This tool helps us create powerful CLI applications by optimizing the workflow. oclif defines everything, from the directory structure to the help commands generated for new features. All you need to do is focus on writing the logic. After a "build" step, oclif produces a complete CLI application, including usage instructions without requiring you to do many additional steps.

Configuration File

In an application, apart from the default configurations or configurations hardcoded in the code, sometimes user configuration is still needed.

For example, you provide the user with the ability to set the input/output paths for files after processing. This option needs to be saved somewhere for future use. The easiest way is to create a text file and store all the information in it. Or more professionally, you can use the cosmiconfig library.

cosmiconfig is a library that automatically fetches configuration files into your application. cosmiconfig supports many formats such as .json, .yaml, .yml... After loading, cosmiconfig puts all the values into a variable that you can use in your application.

Input

Input is an essential part of CLI applications; besides receiving user data through flags like --resize, there are many other optimized ways.

inquirer is a library that provides many ways to receive user data. For example, displaying a text input box, yes/no questions, or select options... each time a certain command is typed.

Output

Have you ever used a CLI application that shows beautiful "loading" effects during interaction? Or lines of text with various colors to highlight important information? There are many libraries to help us achieve this.

ora is a library that creates beautiful "loading" effects. These effects are often used to signal to users that processing is underway and they need to wait. ora provides many different "spinning" shapes. Additionally, you can combine it with text to create continuous messages on the screen, indicating the progress of the ongoing process.

progress helps you create "downloading" effects using a combination of ASCII characters.

Sometimes you will need to draw a table to display information for output, cli-table3 is very suitable for this. Or if you simply want to enclose content in "boxes", boxen is a perfect choice.

Additionally, you can combine with chalk to style the text. This is a great library to change colors, add effects like "bold", "dim", "italic"... to highlight content. Or if you prefer a "rainbow" effect, gradient-string is unbeatable.

Utils

In addition to the main libraries mentioned above, there are still many other utility libraries that CLI can use.

open helps us open something like images, web addresses, or even applications. This library proves useful when we need the assistance of an external application that the CLI cannot handle.

clipboardy helps read data from the clipboard or issue commands to copy anything you want.

shelljs is used to run any other command-line programs through the shell.

And many other libraries that I cannot list all here.

Conclusion

Above is a compilation of some libraries that assist in creating a CLI application for Node.js. As a CLI enthusiast, I have researched and applied quite a few useful libraries in my applications. What about you? Are you using any additional tools? Please leave a comment for me and everyone to know. Thank you!

Using Cloudflare Tunnel to public Ollama on the Internet

hoaitx — Wed, 15 Jan 2025 03:20:56 +0000

Hello everyone. Tet is just around the corner, have you prepared anything for yourself and your family yet? It seems to me that as the year ends, everyone gets busier. Since the beginning of the month, the traffic to the blog has decreased significantly. Sometimes it makes me anxious because I don't know where my readers have gone. Maybe they are taking an early Tet break, or the chatbot is too strong, or it could be due to the content not being engaging enough anymore. 😥

I must admit that in these last few weeks, I have been in the mindset of a busy person, not having much time to write regularly. It could be due to the nature of the job, combined with many issues to handle, so I no longer have the mental space to relax. But it’s okay; today I successfully configured Cloudflare Tunnel in conjunction with Ollama to "public" an API endpoint on the Internet - something I couldn't do a few weeks ago. I thought many people would need this, so I decided to write an article about it right away.

At first, I intended to write a short post in the Threads section, but then I realized it had been too long since I wrote a lengthy article, so I changed my mind. Can you believe it? A long article can be condensed into just a few short lines. Conversely, a short article can easily be made "flowery" enough to turn into a lengthy piece that many might dread. So why should one strive to write longer?

Wow! If I didn't say it, no one might know the reason. Writing is a way for me to relieve stress. By writing, I can connect with my readers, share, chat, or weave in stories and lessons I have learned. In other words, writing serves both as a form of relaxation and a means to interact with everyone.

Since launching the short article section Threads, I never expected so many people would be interested in it. Oh, but to say I didn't expect would be an exaggeration because I did a lot of research before implementing this feature. "Coding" a feature isn't hard; the challenge lies in how to operate it. Threads must ensure that the frequency of posts isn't interrupted; if I write an article infrequently, would anyone even come back to check for updates? This inadvertently creates pressure on how to both gather and summarize interesting and prominent news for readers. Many days I got too busy and forgot to write, and sure enough, the next day I had to publish a make-up post to keep my credibility intact. 😆

I know that many people enjoy reading, and I am one of those who loves writing. Sometimes reading isn't always in the mindset of being "chased by a deadline," on the way to find a solution, or learning something new... I believe that for many people, reading is similar to writing: it is for relaxation. Relaxing while gaining knowledge and experience is indeed a two-for-one deal, isn't it? 😁

I've talked too much already; let's get to the main point. Today I successfully configured Cloudflare Tunnel along with Ollama to publicize an API endpoint on the Internet. From there, anyone can access it without being confined to the local server (localhost) anymore. After reviewing the documentation for Ollama, it turned out to be simpler than I thought!

Cloudflare Tunnel & Ollama

If you don't know about Cloudflare Tunnel, please refer back to the article Adding a "Tunnel Locally" Tool - Bringing Local Servers to the Internet. This is a tool that helps us map local servers to the Internet, effectively turning your computer into a server that anyone with an IP address or domain name can access.

Ollama is a tool that allows us to run some large language models (LLMs) on our computers with just a single command. It simplifies the installation and usage of models. The standout feature is that it supports APIs compatible with OpenAPI.

In a previous article, I mentioned creating a Tunnel through a six-step process - a bit lengthy, right? In fact, Cloudflare Tunnel has a much quicker startup process, requiring only the installation of cloudflared and then using a single command:

$ cloudflared tunnel --url http://localhost:11434  
...  
Your quick Tunnel has been created! Visit it at (it may take some time to be reachable):  
https://tennis-coordination-korea-wv.trycloudflare.com  
....

Immediately, you will see a random address that cloudflared has generated. It maps to the address http://localhost:11434 on your computer. When accessed from another machine at https://tennis-coordination-korea-wv.trycloudflare.com, we see the same result as accessing http://localhost:11434 on the local machine.

The above is just an example of mapping any port on your machine to the Internet; for Ollama or many other tools, additional configuration for the hostname in the headers is required. In the Ollama documentation, it instructs:

$ cloudflared tunnel --url http://localhost:11434 --http-host-header="localhost:11434"

After that, try calling the API using the new URL. Note that you must run the llama3.2 model from Ollama beforehand.

curl https://tennis-coordination-korea-wv.trycloudflare.com/api/generate -d '{  
  "model": "llama3.2",  
  "prompt": "Why is the sky blue?"  
}'

Wonderful! At this point, everything is done, and you have an API endpoint pointing to Ollama on the local server that anyone can access. However, if you have a domain in Cloudflare and want to maintain a fixed address like api-ollama.2coffee.dev, you need to configure it according to the six steps.

Keeping a Fixed Domain

It's very simple; after completing step 4 in the article Adding a "Tunnel Locally" Tool - Bringing Local Servers to the Internet, modify the contents of the config.yml file as follows:

tunnel: [tunnel-uuid]
credentials-file: path/to/.cloudflared/.json  

ingress:  
  - hostname: api-ollama.2coffee.dev  
    service: http://localhost:11434  
    originRequest:  
      httpHostHeader: "localhost:11434"  
  - service: http_status:404

Then run:

$ cloudflared tunnel run [tunnel-uuid]

Although this method can help you create an API address similar to OpenAI's ChatGPT, it has many limitations, such as depending on the machine configuration and the model being used. Ollama can only handle one query at a time, so making continuous or simultaneous requests will not be efficient.

Hello the Last Day of 2024, Let's see what we accomplished last year!

hoaitx — Sat, 04 Jan 2025 07:57:03 +0000

This is a submission for the 2025 New Year Writing challenge: Retro’ing and Debugging 2024.

Hello! Another year is about to pass, just a year ago today, I was still struggling to outline plans and goals, and in a blink, here I am today, sharing with you what I have accomplished. It is even more meaningful to share this with the community Dev.to.

But first, I will reveal some statistics of mine.

The Statistics

In 2024, I wrote an additional 56 new articles, totaling over 100,000 words. It's amazing! Even I can't imagine writing that much. I welcomed 89 new members. Especially after launching the anonymous comment feature, I received an additional 95 new comments across all articles. Additionally, I committed to maintaining a daily post in the Threads section for over 5 months. As of now, the number of short posts has reached 159, and it will continue to grow in the future.

It's a bit disappointing that the email newsletter sign-up feature flopped, recording only 4 subscribers. On the other hand, the number of people subscribing to new post notifications in the browser is 142. Of these, about 60 are active users (who frequently receive notifications of new posts).

So what about reader activity?

There have been over 77,000 views across all articles, along with more than 40,000 new users. The number of active users is over 44,000. This means about 4,000 readers return to the blog more frequently.

Can you guess which article was read the most? That would be Using GPT-4 for Free with Github Copilot with over 9.5k views. Next is the blog's "signature" article How to Delete a Commit That Has Been Pushed?. The most visited page is the homepage with over 12k views. The most impressive is the Threads page, which, despite being newly created, still made it to the "top" 9 most visited pages.

Compared to 2023, how did these figures grow or decline?

Fortunately, most metrics have increased. According to statistics from Google Analytics, the number of active users has increased nearly 73% compared to last year, with new users up by 60%. The only downside is that the average reading time for articles has decreased by 30%. I wonder if it’s because my writing has gotten worse, so no one bothers to read anymore, or if people are gradually losing patience with long articles 😅.

When it comes to traffic sources, users are still finding the blog through Google, which remains in first place, increasing by over 50%. One thing that shocked me is that the number of direct visitors has increased by nearly 190%. Wow! This means they are proactively visiting without needing to go through Google anymore.

Furthermore, the blog has shown signs of appearing in search results from AI-based search engines like ChatGPT, Google Gemini, and Bing...

What have I learned?

2024 was also the time I became interested in the concept of Serverless. I learned and worked more with this new architecture. Serverless helps me minimize costs while alleviating concerns about system operation.

I took an interest in Rust and learned it. During my learning process, I documented and created a series of articles about my self-learning journey. I'm glad to see a lot of interest. Although I still can't use it fluently, to be honest, it's very powerful. I hope to apply Rust soon in the near future.

With the help of a brother, I learned a lot about large language models, RAG, and Generative AI. I applied artificial intelligence in many features of the product while enhancing my work productivity. Notably, the blog has integrated many features such as smart search or related post suggestions to enhance user experience.

Finally, I "Tear Down and Rebuild" my blog, replacing it with a newer tech stack. I recounted this process in an article. So far, everything is working perfectly.

Reflecting on the Goals of 2024:

In 2024, I will maintain all activities like last year. I will continue learning, writing, and spreading motivation, enjoying the spirit of coffee & books.

It's great that my enthusiasm and spirit have not diminished. I have learned many new things, many new technologies, and especially released an open-source personal note-taking app within 3 months. It's called OpenNotas. Simple, secure, focused on writing. Many articles you read originated from here 😄.

I have read many new books. Among them, I must mention notable literary works from Vietnam and abroad. They are very good! I cannot deny how important reading influences my writing skills.

Not stopping there, I hope that in 2024 I will elevate my personal brand, making more people know about me, even more!

I have actively participated in social media, especially Facebook and recently Threads. I have been diligent about reading more articles, interacting more with everyone, and proactively making friends and exchanging with many people I hadn’t known before. Wow, I wonder if that’s enough to make people know about me more? Surely it's a little bit 😅.

Another memorable milestone is posting on Dev.to and receiving a lot of attention from everyone. I have over 6,000 followers now. Thank you all for your interest in me.

Goals for 2025

In the new year, I will definitely maintain my old habits. At the same time, this is a challenging time to break through and harvest more results from the foundations I have laid for a long time. Thank you and wish everyone achieves all their goals in the new year 2025.

Semantic Search Feature

hoaitx — Tue, 17 Dec 2024 02:48:35 +0000

Hi there, have you noticed that the autumn atmosphere has become clearer in Hanoi recently? The morning was cool, and the evening came with strong winds. But behind that was a busy week for me. I was focused on running the "deadline" for my company's project, and in the evening, I tried to complete the search function for my blog. This deadline was different from usual because it was the main feature for the year for the product. And as for the blog, the search function had to be completed sooner or later, and this was the perfect time to do it.

Before switching to Fresh, my blog already had a search function. The way I did it back then was to use Postgres's fulltext-search. For those who don't know, before using Postgres, I also used redisearch for search. Generally speaking, Postgres gave better results, while redisearch was more complex. But in reality, my blog data wasn't that massive, so redisearch didn't have a chance to shine.

When I switched to Fresh, AI was booming. Many people were talking about AI and what it could do. After completing the basic features and getting ready to work on the search function, I thought, "Why not try using AI?" So, I decided to "release" the new blog version without the search function.

To create a search function with AI, I had to spend a lot of time researching and experimenting. I learned about how to implement it, how to use LLMs models, embeddings models, vector data types, how to convert data to vectors, and how to query...

To put it simply, a vector is a finite set of numbers, like in mathematics. The number of elements in the set determines the size (dimension) of the vector. The larger the size, the more the vector can generalize the data it represents. To convert regular data (text, speech, images, etc.) to vectors, there are many ways, but thanks to the popularity of LLMs today, you can just put the data into an embeddings model, and it will give you vector data.

Semantic search (semantic search) is different from traditional fulltext keyword search. Fulltext search is based on the amount of text characters entered to match and return the most relevant results. Meanwhile, semantic search is based on the content. Suppose your article is explaining how node.js works. When searching for the phrase "how node.js works", semantic search can find the article. On the other hand, fulltext search will try to find articles containing the words "node.js", "works", ...

To query vector data, you need at least two steps. First, convert the query into a vector, then use the query functions. For example, with pg-vector - a Postgres extension that supports vectors - there are query functions like:

You can see L2 distance, Cosine distance, L1 distance... as vector comparison methods. Depending on the use case, you choose the query type accordingly. For example, in the search problem, I chose the Cosine distance method - that is, the two vectors should have a similar shape.

How to do it

First, choose a suitable database. I'm using Turso as my main database. However, Turso is based on SQLite, which isn't optimized for vector data. Although they introduced an extension to support vectors, it's a bit complicated.

pg-vector is the opposite. It's widely used and is a Postgres extension. When it comes to Postgres, I think of Supabase, which offers free usage. Supabase has pg-vector integrated, and activation is just a click away, making it a great choice.

Next is choosing models. To save costs, I've been looking for free models from the start. I couldn't help but mention groq with its Completions API. However, groq doesn't have embeddings models, so I had to find another one.

nomic-embed-text is an embeddings model I found in Ollama's library. It can vectorize text. Additionally, Nomic provides a free embeddings API with limitations. However, I should remind you that Nomic isn't a multilingual model. It supports Vietnamese to a limited extent, so the generated vector might not be optimal for Vietnamese semantics.

After preparing everything, it's time to write code to add vector data and search logic.

First, convert the article content into a vector and store it in Supabase. Instead of converting the entire article content, I summarize the main content of the article before feeding it into nomic-embed-text. This helps remove unnecessary information and reduce the input token count for the model to process.

Another note is that although these models have free APIs, they always come with limitations. Processing data for the first time is very expensive, as I have over 400 articles in both Vietnamese and English. A better approach is to run the Llama 3.2 3B and nomic-embed-text models locally. I use LM Studio for this.

The search logic is simple. Take the user's query -> pass it through nomic-embed-text to convert to a vector -> query cosin with the article vector and sort by the closest distance between the two vectors.

However, if the user searches for keywords like node.js, javascript, etc., it's likely that semantic search won't return results because the data is too short, and the generated vector doesn't contain enough meaning, making the cosine distance too large. Therefore, to handle this case, I need to maintain a fulltext search mechanism. Fortunately, Supabase supports this type of search.

Challenges

Looking back, it seems simple, but the most challenging part for me was the data preprocessing steps.

An article usually conveys multiple ideas, including main and secondary content. Typically, searchers are only interested in the main content of the article, and they tend to search for related things. If I convert the entire article content into a vector, it will be "diluted" or "noisy" because the vector size is limited. I think that if I can remove secondary information and emphasize the main idea, the search will be more accurate. Imagine an article with 1500 words converted into a 1024-dimensional vector, compared to an article with only the main content of 500 words in the same vector. Which one represents the data more "clearly"?

Users' search patterns are also hard to predict because everyone searches differently. Some people like to keep it short, while others like to write longer or provide context for their questions... Therefore, processing user input data is also a challenge. How can I convert it into a concise and relevant query that matches the search content on the blog?

The quality of the AI model used is also an issue. Generally, the more trained a model is, the better it is, and commercial models come with quality assurance. However, to minimize costs, I'm currently using free LLMs models with limitations. Hopefully, one day I'll be able to integrate more powerful models to improve the search quality for my blog.

5 things I like about Deno

hoaitx — Thu, 12 Dec 2024 10:15:07 +0000

The problem

Deno stable version was introduced about 3-4 years ago. At that time, it received quite a bit of attention because none other than Ryan Dahl, the creator of Node.js, was also the patron of Deno. Huh! You heard that right. Why would he create a new tool to compete with his own "child"?

Ryan Dahl admitted that Node.js has critical weaknesses. Initially, Node.js was designed to focus on simplicity and flexibility. But over the years, everything has gone beyond control. Node.js has developed very powerfully, gaining more attention, and as people tried to pack everything into this rising star, it became more complicated than necessary.

Deno was born to address the weaknesses of Node. However, at the time of its launch, it did not showcase its strengths. Its performance was even inferior to Node.js, not to mention the lack of npm support – which was one of Node's biggest advantages. This made things increasingly difficult.

Being a curious person, I quickly experimented with some code snippets using Deno and realized the inconvenience regarding the library system. "Wow, it might take a long time for my favorite libraries to appear on this platform; everything looks both new and unfamiliar," I thought!

Everything changed when I started "Tear Down and Rebuild" my blog. After many times of hesitating and pondering over technology choices, the name Fresh appeared. However, Fresh requires Deno as its runtime environment. Having no prior deployment experience but thinking "it's just a JavaScript runtime environment!" gave me more confidence. The next story is this article.

Today, I will summarize 5 points that I feel "like" when working with Deno.

TypeScript support

Deno natively supports TypeScript. This means you can run a .ts file directly without going through a conversion step to .js like other libraries usually do. Many people wonder if this is different from using a tool to run TypeScript code like ts-node? The answer is definitely yes because ts-node requires TypeScript configuration files to work in complex cases, while Deno does not. The default support for TypeScript simplifies the process of running .ts code directly.

I often create scripts to handle some minor tasks for myself. Every time I create a new script, I always hesitate between choosing .js or .ts. And when Deno appeared, .ts became the default choice. Even in Node projects, when I need to write a script to perform a quick task, I still prefer choosing .ts and using Deno to execute that code.

No more multiple configuration files

The more I engage with JavaScript/TypeScript projects in general or Node.js in particular, one thing that I have always wondered about or even found annoying is... there are too many configuration files. Each different project has files with different names. From package.json, package-lock.js, and an additional tsconfig.js if the project uses Typescript... Not to mention if I need to configure a few more things like webpack, vite, tailwind, postcss... oh my! In the beginning, due to being unfamiliar, I had to read to understand the significance and usage of each configuration file that appears in the project, reading while silently cursing, "How on earth can you create hundreds of configuration files like this?"

When moving to Deno, I was amazed to find that there were no configuration files at all. That means you can run the project without any config – sounds surreal, right? If there is any, it is just a single deno.json file. Deno cleverly eliminated many complicated configurations or placed them into a single json file. What a relief to open a project without worrying about the appearance of a strange name again!

Support for Web APIs and Node APIs

Deno has been and is trying to support Web APIs as much as possible. Web APIs are a standardized set of APIs available in the browser. Good support for Web APIs can allow programs running in Deno to also run in the browser, following the write once – run anywhere paradigm. This opens up avenues for "Universal" libraries.

If you have ever worked with Serverless, especially with Cloudflare Workers, you would know that Workers are not completely compatible with Node.js, so using Node-specific libraries is likely to not work. On the other hand, if a library uses or is compatible with Web APIs, it runs smoothly. This also applies to Deno.

Support for Node APIs allows Deno to run most "packages" on npm. Thus, you can freely use npm packages without worrying about compatibility anymore.

New security mechanism

It's quite strange that there is an obvious fact that when starting a Node project, it will by default have all the user's permissions. This means the program can freely access files or execute commands in the system on behalf of the user. Quite dangerous, isn't it? Imagine if you accidentally "run" someone else's project without checking it first, and it scans all the data on your machine, sending it back to some server, or encrypting all files for ransom, then consider your life ruined, a mistake that cannot be corrected!

Deno addresses this flaw by adding flags to request permissions when running applications. Permissions can include file access, internet access... If the program wants to access the file system or connect to the internet, it must at least request permission. For example:

$ deno run --allow-read --allow-write --allow-net index.ts

There are many permissions that need to be "requested"; for more details, refer to Security and permissions | Deno Docs. The quickest way is to allow all permissions by using the -A or --allow-all flag.

Performance is continually improving

I remember the early days when it was just introduced; Deno seemed to lag behind Node.js in terms of program performance. Specifically, benchmark tests showed the difference between Deno and Node when running the same program; Deno always came up short. At one point, bun.sh suddenly appeared. Bun emerged as a phenomenon because it outperformed both Node.js in terms of performance. This made Deno seem even more dull.

In reality, when using bun to run some Node applications, I encountered quite a few issues and even bugs. It seems bun is not ready for "production." So at that time, I concluded that Node is still the go-to choice for those who love stability.

Recently, with the release of Deno 2.0, significant efforts have been made to improve performance and enhance the programming experience of this "black dinosaur." According to the latest documentation they released, Deno stands out in every aspect compared to the well-known names Node and bun.

Conclusion

Above are the points I like when working with Deno. There are a few more features, such as providing Deno Deploy for free to deploy applications. However, I still occasionally come across articles that "criticize" performance and the module system, as well as low compatibility with Node. These limitations have been addressed in the latest 2.0 version. My perspective on Deno has changed compared to when it was first launched, and I hope Deno will receive more attention from the community and make even more breakthroughs in the future.

What about you? Have you used Deno? Do you have any praise or criticism regarding this JavaScript runtime environment? Please leave your comments below!

Using GPT-4 for Free Through Github Models (with Limitations)

hoaitx — Mon, 25 Nov 2024 02:16:26 +0000

As a social media user, it is not difficult to see posts asking if anyone wants to share a ChatGPT Plus account. By subscribing to the Plus version, you can use the latest and most powerful models, such as gpt-4, gpt-4o, or o1-preview... This shows that the demand for using these models is very high. Many users do so for research and study purposes. Or simply to experience something new, to see what is outstanding compared to what is already known.

With a price of $20 a month, I am sure many people will hesitate. We have too many bills to pay in a month, and there are many more important things to spend on. Therefore, if someone is willing to "chip in" to share the costs, it would be great; the cost would be reduced exponentially. If five people share, each person only needs to pay $4. However, this also creates many new problems. Currently, ChatGPT limits the number of queries within a certain time frame. Therefore, if someone "accidentally" uses up all the queries, the next user must wait until the limit resets. Not to mention the financial risks of sharing with strangers. Thus, it is best to only share with people you know.

Previously, I wrote an article about how to use GPT-4 for free through Github Copilot. But in the end, this was just an unofficial "trick," and I warned readers that there was a risk of their Copilot accounts being "flagged." As of now, it is uncertain whether this method still works, but readers should not follow it anymore. According to statistics, that article still has many readers. Wow! The allure of GPT-4 is remarkable!

On the occasion that Github just public previewed Github Models for anyone with a Github account to access their models, including many models of GPT and other well-known models like Llama, Mistral... In this article, I will guide everyone on how to use GPT-4 for free in a way that is as similar to ChatGPT as possible. And of course, it is not as good as the official version, with many limitations included, but it is still worth experiencing.

Github Models

Github Models is a feature that Github supports developers to use large language models (LLMs) for free for testing purposes - as they say. After completing the testing phase, users must deploy their applications with other providers because the testing models have many limitations in speed and context. However, if only used for personal purposes, it is acceptable.

We all know the website ChatGPT is for everyone - especially free users - to chat with gpt-4o, 4o-mini... After a few exchanges, you will run out of queries and be "downgraded" to the gpt-3.5 model. ChatGPT saves the history of exchanges, allowing users to review past conversations. This is also the easiest way for users to interact with GPT models.

If you are not a developer, or perhaps are a developer but have not noticed, OpenAI - the company behind ChatGPT provides an API to interact with their models. Simply put, instead of using the web chat, you can completely call the API to do the same thing. For example, a conversation in the API would look like this:

curl https://api.openai.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "model": "gpt-4o",
    "messages": [
      {
        "role": "system",
        "content": "You are a helpful assistant."
      },
      {
        "role": "user",
        "content": "Hello!"
      },
      {
        "role": "assistant",
        "content": "Hi there! How can I assist you today?"
      },
      {
        "role": "user",
        "content": "What is the capital of Vietnam?"
      }
    ]
  }'

You will see that an API call includes all the content of the conversation. This means that to continue the conversation, you need to send back all the previous content between you and GPT. This explains that it is the context of the conversation. GPT does not store state, so the best way to help it understand the content being discussed is to resend all previous content.

The special thing is that by calling the API, you can use the latest models without necessarily subscribing to the $20 GPT Plus package. However, API calls cost money, and the billing is very different from the web version. You pay more if you call the API more often, and the length of the conversation also incurs more costs since the API charges based on input/output tokens. Not to mention, the input/output costs differ depending on the model you use.

"Wow, this is really confusing. Just calculating the costs is already so complicated that it might be easier to just subscribe to Plus 😆." Surely many people will think like that after reading this, but it's true! You spend money to buy satisfaction; that is the pinnacle of sales art. If you spend a little time and get to use it for free, then it forces us to read and experiment more.

Below is the pricing table based on input/output tokens for the gpt-4o mini model.

Input tokens are the number of characters sent, while Output tokens are the number of characters that the model responds with. This means that the more you send or the more the model responds, the more money you spend. Tokens are calculated based on a few principles; basically, you can think of them as roughly equivalent to words (1 token = 3/4 word), meaning 3 words will correspond to 3 tokens. A more standard formula can be found at Tokenizer | OpenAI Platform.

After registering an account on Github, access Marketplace Models and you will see a list of models available for use. Click on any model, for example, here is OpenAI GPT-4o mini. Click on the Playground button at the top right of the screen. Here you will see a chat interface very similar to ChatGPT. Try starting a conversation as usual. Congratulations, you are now using the gpt-4o mini for free.

However, this method is a bit inconvenient as it does not save the conversation history, and the interface is not very user-friendly. Next, I will guide you through a much more "professional" way.

Lobe Chat

Lobe Chat is an open-source project that provides an interface and features to interact with large language models. Simply put, Lobe Chat provides a chat interface similar to ChatGPT.

Lobe Chat helps us manage conversations. In addition, it also tries to integrate many other features, but in the scope of this article, I will not mention them yet. Lobe Chat interacts with LLMs via API, so you need to configure the connection for calls to the corresponding model server. Here I will guide you to configure for Github Models.

First, you need to obtain Github Tokens for basic authentication. Go to Personal access tokens | Github. Click on "Generate new token (classic)." Enter a name for the token and choose the expiration time for the token as you wish. You do not need to select any scopes. Click on Generate token at the bottom and save the token you just received.

Next, install Lobe Chat on your computer. You can deploy Lobe Chat to many cloud services like Vercel, Zeabur... with just one click because Lobe is a web-based application. Or if using Docker, simply run one command.

$ docker run -d -p 3210:3210 --name lobe-chat lobehub/lobe-chat

Access http://localhost:3210 to see the interface of Lobe Chat. Next, we need to set up the API configuration for it to work.

Click on the Lobe Chat avatar at the top left, select "Settings," click on the "Language Model" tab, and you will see the OpenAI setup screen. You need to fill in "API Key," "API Proxy Address," and "Model List." The API Key is the Github token you just created above, and the API Proxy Address at the time of writing this article is:

https://models.inference.ai.azure.com

In the "Model List" box, enter the names of the models you want to use. To know the exact name of the model, visit each model on Github Models, click on Playground, and switch to the "Code" tab. For example, here I enter "gpt-4o," "gpt-4o-mini." Click on the "Check" button to verify if the configuration is correct. If "Check Passed" appears, it has been successful.

Now let's try to create a new conversation.

Wonderful!

Limitations

There are a few notable limitations that you need to be aware of while using it.

First is the limitation on chat speed and the number of API calls per day. Github labels each model to determine these limitations. For example, looking at the table below.

These labels are found in the details of the model. For example, for gpt-4o labeled "High," it means that in one day, you can only make 50 requests - equivalent to 50 questions, and you are limited to 10 requests per minute as well as a maximum of 2 requests concurrently.

Additionally, pay attention to the "Tokens per request" which is the amount of tokens in/out for each request. For example, with gpt-4o it is "8000 in, 4000 out," meaning the maximum number of words sent is 8000 words, while the number of words that the model responds with is only a maximum of 4000. Meanwhile, gpt-4o supports input tokens up to 131k and output up to 16k. Clearly, there are too many limitations. Hopefully, in the future, Github will "expand" these limits.

You also cannot create images or audio. Lobe Chat only stores conversations on your computer, so you can only review the conversation created on your machine or switch to configuration on a cloud service.

Although there are still many limitations, for those who want to experience or use it infrequently, this is a "lifesaver" solution. If you exhaust the limits of this model, you can switch to another model to continue using. Besides GPT, there are still many powerful models waiting for you to explore.

Do you find this method interesting, or do you have any methods you want to share? Please leave your comments below the article. Thank you.

Introduction to hono.dev - Building a Serverless API Easily

hoaitx — Tue, 24 Sep 2024 15:09:59 +0000

Express.js is certainly a library that any JavaScript/Node.js developer knows. It helps us build a REST API server quickly. Besides, there are many libraries and middleware created to be compatible and easily integrated into projects using express.js, making it increasingly popular and well-known.

Starting with express.js is not difficult. Just go through a few steps to install the library and write a little code, then use the node command to start the server. The deployment process is not much harder. Push the code to git, pull it back to the server, use a process management tool like pm2 to start it up, and that's it.

This is a nearly obvious process to apply when writing and deploying a Node server. Even later, when working for many companies, the process of pushing code to git, pulling it back to the server, and then "pm2 restart" - which I jokingly call the 3P process to operate the server - is still the same.

Until one day, my CTO mentioned Cloudflare Workers, a form of serverless. He said it could do this and that... a little bit each day, and it made me curious. Occasionally, I would read about it, but honestly, it was hard to understand. Although everyone knows the concept of serverless, its practical application is unknown.

What is mentioned many times will also attract attention. I started reading about serverless more seriously, but I still didn't know how to deploy the code to serverless. Because serverless has no server, where do the push-pull-pm2 restart happen?

It turned out that there was a separate process for deploying everything to serverless. Moreover, this process is even simpler than the traditional 3P. All you need to do is run the deploy command on your machine. When that's done, all the code will be uploaded to the serverless server and be ready to run immediately.

In this article, I won't discuss the process of deploying code to serverless. Before that, we need to know about a library that helps us build an API on serverless. Why? Because express.js and similar libraries cannot run on many serverless servers.

hono.dev

hono.dev is a library similar to express.js, providing solutions for building APIs. But why hono? Look at Cloudflare Workers' simple endpoint guide below:

export default {  
  async fetch(request, env, ctx) {  
    return new Response("Hello World!");  
  },  
};

This code will respond with the phrase "Hello World!". If you want to add a POST method, you need to check the condition:

export default {  
  async fetch(request, env, ctx) {  
    if (request.method === "GET") {  
      return new Response("Hello World!");  
    } else if (request.method === "POST") {  
      const data = await request.json();  
      return new Response(`Hello, ${data.name}!`);  
    }  
  },  
};

Too cumbersome and complex, an API server is not that simple, but a collection of dozens, hundreds of different endpoints. That's when hono shines.

import { Hono } from 'hono'  
const app = new Hono()  

app.get('/', (c) => c.text('Hello World!'))  
app.post('/', (c) => c.text(`Hello ${(await c.req.body()).name}`))  

export default app

Isn't it quick and easy?

Hono.dev is quite similar to express.js or koa.js. Hono focuses on simplicity, routing, and middleware. Using hono is similar to the REST API libraries you've been using for a long time.

For example, a simple middleware to measure the request processing time:

app.use(async (c, next) => {  
  const start = Date.now()  
  await next()  
  const end = Date.now()  
  c.res.headers.set('X-Response-Time', `${end - start}`)  
});

Hono is very lightweight, only 14kb for the hono/tiny package, making it ideal for environments with many limitations like serverless. In traditional server applications, package size or library size doesn't matter because system resources are abundant and easy to upgrade. However, in serverless environments, resources are scarce, so finding fast and lightweight libraries is essential.

You may have heard of the term "universal module" and "adapter", which are often used to describe a module that can work in multiple environments. From servers, browsers, or even serverless environments. To achieve this, universal modules utilize APIs supported by the environment to adapt and create adapters for us to choose from. Even if the project structure is good enough, we don't need to modify too much code to run in different environments.

Hono supports many adapters, making it perfect for serverless environments. Some notable names include Cloudflare Workers, Vercel, Netlify, AWS Lambda... or even Service Worker in browsers.

For example, this code snippet runs well in Cloudflare Worker:

import { Hono } from 'hono'  
const app = new Hono()  

app.get('/', (c) => {  
  return c.text('Hello Hono!') 
})  

export default app

And to switch to Netlify's serverless environment, we need to change the adapter:

import { Hono } from 'jsr:@hono/hono'  
import { handle } from 'jsr:@hono/hono/netlify'  

const app = new Hono()  
app.get('/', (c) => {  
  return c.text('Hello Hono!')  
})

export default handle(app)

Note that since the serverless environment has different deployment methods, the best way to choose a suitable configuration for each environment is to refer to Hono's documentation.

Hono's documentation is very simple and concise, and we can start building a project after just a few reads. Its own "homegrown" middleware is constantly being added to enhance the experience for developers, so we don't need to reinvent the wheel. Additionally, Hono is receiving attention from the community with impressive growth on Github.

This is a short introduction to Hono and what it can do. In the next article, we'll deploy a serverless API server to Cloudflare Workers from scratch!

A Few Useful Functions in Node.js Util Module

hoaitx — Sun, 22 Sep 2024 16:02:34 +0000

Node.js encompasses a range of components that come together to form a JavaScript runtime environment. In our series on Node.js Architecture - Introduction to Node.js, we explored the various components that make up Node.js and their respective functions.

Within Node.js, there are numerous built-in modules - i.e., modules that are integrated from the outset. One such module is util, which, in my opinion, deserves more attention. The util module comprises a collection of small utility functions that can be helpful in certain situations. In this article, we will delve into some of these functions...

util.promisify and util.callbackify

The callback is one of the earliest ways to handle asynchronous code. However, callbacks have several limitations, such as creating nested code and causing the infamous "callback hell." Occasionally, reading a piece of code written in a callback style can be overwhelming. Adding new functionality can be challenging, as it requires introducing an additional layer of logic.

In Node.js, there is a utility function to convert asynchronous functions using the callback style to Promises. This function is useful when you want to transition to a Promise-based approach and then combine it with async/await to make your code more concise and easier to follow.

const util = require('node:util');
const fs = require('node:fs');

const stat = util.promisify(fs.stat);

async function callStat() {
  const stats = await stat('.');
  console.log(`This directory is owned by ${stats.uid}`);
}

callStat();

Conversely, we have util.callbackify to convert Promise-based functions back to callbacks.

const util = require('node:util');

async function fn() {
  return 'hello world';
}
const callbackFunction = util.callbackify(fn);

callbackFunction((err, ret) => {
  if (err) throw err;
  console.log(ret);
});

util.deprecate

If you frequently use libraries, you may have noticed console messages indicating that a function is deprecated.

oldFunction() is deprecated. Use newFunction() instead.

This is a notification that the oldFunction is nearing the end of its support lifecycle and may be removed in the future. It is a common approach to remind developers that a function is approaching its "retirement" and to use an alternative function instead.

In Node.js, there is a simple way to display this notification if you need to warn others that a function is nearing its end-of-life.

const util = require('util');

function oldFunction() {
    console.log('This function is deprecated!');
}

const deprecatedFunction = util.deprecate(oldFunction, 'oldFunction() is deprecated. Use newFunction() instead.');

Simply "wrap" the oldFunction inside util.deprecate. Each time oldFunction is called, the warning message will appear in the console.

util.types

From ES6 onward, we have additional functions to check the type of data: boolean, array, object, etc.

The util module has a types property that extends the capability to check data types.

For instance:

console.log(util.types.isPromise(Promise.resolve())); // true
console.log(util.types.isRegExp(/abc/)); // true
console.log(util.types.isDate(new Date())); // true

A comprehensive list is available at util.types | Node.js documentation.

util.isDeepStrictEqual

isDeepStrictEqual is the most efficient method to compare two objects and determine if they are identical.

const util = require('util');

const obj1 = { a: 1, b: { c: 2 } };
const obj2 = { a: 1, b: { c: 2 } };

console.log(util.isDeepStrictEqual(obj1, obj2)); // true

In addition to these functions, the util module provides many other utility functions, such as util.styleText to format text output in the console, and util.parseEnv to parse the contents of environment variables in .env files.

For more information, refer to:

Node.js v22.8.0 documentation | Util

Using pm2 to Manage Node.js Applications

hoaitx — Fri, 02 Aug 2024 10:40:07 +0000

The Problem

When I first encountered Node.js and also learned how to use Linux, nodemon was a library that I often used to develop applications, as it would automatically "reload" the new code upon saving without needing to manually "kill" and restart the application, a feature now commonly referred to as "hot reload."

After development comes deployment. While practicing running the application on the server, I struggled to figure out how to run it. If I used the conventional method of typing "node index.js" or even used nodemon, whenever I exited the terminal or disconnected from the server, the application would also "disappear." I understood that the application would exit if the connection to the server was lost. So what to do?

It was only later that I learned that to keep the application running continuously, we need a process management tool. This is not only necessary for Node but for most other languages as well. For Node, the most mentioned name is probably pm2.

Since I discovered pm2, I have been able to easily deploy my applications. However, over time, as I worked on many projects and encountered other technologies like Docker, Kubernetes, etc., pm2 gradually became less essential, as those tools already integrated management capabilities.

Recently, while maintaining several projects, most of which used pm2, I had to spend time revisiting the documentation on how to use it, as it had been a while since I last used it. At that time, I suddenly realized that there had been many changes during that period. Many new features had been added, or there were features that I was not aware of.

But I must honestly say that pm2 is still a very powerful Node.js application management tool. Anyone working with Node should take the time to learn about it. Therefore, in today's article, I will highlight some of the main features of this tool.

What is PM2?

pm2 is a daemon process manager that helps you manage and keep your applications always online.

Installing pm2 is very simple, through npm which is integrated with Node.

$ npm install pm2@latest -g

After that, you can start your Node application:

$ pm2 start app.js

The application runs in the background, and to see all running applications:

$ pm2 list

The most useful feature of pm2 is that it keeps the application running in the background, meaning that even if you exit the server, your application will still run.

Most people know that when running a Node application, it only runs on one core of the CPU. If the computer is multi-core, Cluster mode will help distribute all processes to the remaining cores. For example, if the CPU has 4 cores and you want to run on all 4, it's very simple.

$ pm2 start app.js -i max

max indicates all cores will participate; if you want a specific number, replace max with a number.

pm2 has a logging mechanism that writes logs to files for later retrieval. This information includes commands printed to the console like console.log. To view the logs:

$ pm2 logs 0

Where 0 is the id of the process, or you can replace it with the name of the process.

To stop a process:

$ pm2 stop 0

To restart after stopping:

$ pm2 start 0

Or to restart:

$ pm2 restart 0

Or to completely delete the application, ensuring it was stopped beforehand:

$ pm2 delete 0

The pm2 start commands are discrete and singular. Imagine if instead of one, there were multiple Node processes that needed to start at the same time? That's when ecosystem becomes useful. The ecosystem is a mechanism that groups all applications into a configuration file and starts them with a single command.

To create a configuration file, use the command pm2 ecosystem, which generates a file ecosystem.config.js like the following:

module.exports = {
  apps : [{
    name: "app",
    script: "./app.js",
    env: {
      NODE_ENV: "development",
    },
    env_production: {
      NODE_ENV: "production",
    }
  }, {
     name: 'worker',
     script: 'worker.js'
  }]
}

Adjust the configuration to fit your project and start it using:

$ pm2 start ecosystem.config.js

In the event of a server restart, pm2 does not automatically start, causing all applications to become inactive. To address this issue, use the command:

$ pm2 startup

But before that, you need to "commit" the processes to be started at startup with the command:

$ pm2 save

pm2 save creates a "snapshot" of the currently running processes to restore them later.

Advanced PM2

Pm2 has some relatively useful advanced features in certain cases.

RPC Function works by running a function via the command line. For example, there is a function countActive that returns the number of people currently online.

First, create a file rpc.js with the content:

const tx2 = require('tx2');

tx2.action('countActive', (reply) => {
  const num = UserModel.count();
  reply({ num: num });
})

setInterval(function() {
  // Keep application online
}, 100);

Run it:

$ pm2 start rpc.js

Then, if you want to trigger the countActive function, simply use:

$ pm2 trigger rpc countActive

Pm2 also provides an API to manage pm2 via RESTFul API. Simply put, this means you can create a server to add/edit/delete other applications using pm2, done through calling the API. You can read more details at PM2 API.

And a few other advanced features as well.

Recently, pm2 has also launched the pm2 plus service, which allows comprehensive monitoring of applications such as real-time monitoring interface, reporting, logging, and notifications... It can be seen that it is quite similar to APM (Application Performance Monitoring) applications. However, since there is no free package, I haven't had the chance to experience this service. If you have or are using it, please leave a comment at the bottom of the article!

I'm Under DDoS Attack

hoaitx — Mon, 01 Jul 2024 06:10:18 +0000

Since the moment I started building my website, I have always considered the possibility of it being targeted for destruction. There are various forms of attacks such as DDoS, spam, or attacks on certain security vulnerabilities... Do you think I have made any enemies that I should be worried about? Actually, no, I have never had any conflicts with anyone, but I can't escape the "watchful eyes" of these malicious actors on the internet. This is not the first website I have built, so paying attention to these unfriendly behaviors is not new to me.

Recently, my blog has been experiencing a higher frequency of DDoS attacks. In its nearly 3 years of existence, I have lost count of the number of attacks. The lighter ones would cause the server to "freeze," resulting in slow response times. The heavier ones would cause the server to completely crash, making it inaccessible. So far, there have been no significant damages, but it is always a hassle to deal with this mess. It's not like we always have a computer and internet access nearby.

DDoS attacks are not new, but their destructive power is extremely high. Whatever the reason may be for an attacker to decide to DDoS a website, they must find great satisfaction in seeing the website crippled.

In the past, I hosted everything on DigitalOcean (DO) with a modest server configuration that was stable enough for the current user load. Occasionally, I would encounter a minor DDoS attack that would bring the server down. Initially, DO would issue warnings that the server was using more than 70% or even 90% of the CPU without knowing the cause. The UptimeRobot tool would send alerts that my website was inaccessible. Later, upon checking the access logs, I discovered that I was being DDoSed.

Most of the attack durations are very short, and during those times, I could only grit my teeth and wait until it ended, sometimes even occurring in the middle of the night. When I woke up the next morning and rebooted the server, everything would go back to normal.

People might think, why not take measures to protect against DDoS? My feeling about that would be :|, because I don't know how to effectively defend against it. Everyone thinks the first step would be to set up rate limits, and let me tell you, I did that. Each IP address is limited to only 10 requests per second. So why not upgrade the server then? Where do I find the money to do that? $6 a month may not be much, but it serves as a financial safety net and covers the normal traffic if there are no malicious actors. Then, should I install more monitoring tools? Do you think I can install anything on a Shared CPU 1GB, 20SSD server?...

Actually, I've thought a lot about this issue, but I just can't effectively block DDoS attacks. Remembering the OSI 7-layer model that most technology students are taught. We have Layer 7 - the topmost layer - the application layer. The rate limits that I applied were at Layer 7, and the software installed also operated at Layer 7... Layer 7 is the layer that directly interacts with your application or server. In simple terms, if an attacker can send an HTTP request to your server, they are attacking at Layer 7. And as you understand, your server will have to process their requests, whether it be simply rejecting the request, it still requires some CPU time to process. A single request might be simple, but what about thousands, hundreds of thousands of requests at once? As you can see, my blog crashes.

About 3 weeks ago, I wrote an article migrating from DO to Cloudflare. Everything was carefully planned, starting with migrating the frontend, then the API, and eventually everything to avoid maintaining a centralized server like DO. Perhaps this article "ticked off" some individuals and they decided to see if the "new home" could withstand DDoS attacks.

The answer is yes, but only partially. After discovering that the main blog was no longer SSR, attackers quickly realized that the API calls were still going to DO, and they continued attacking the API, with the consequence being the same - it crashed.

Finally, I couldn't bear it anymore. Even with limited time, I had to perform a large migration to Cloudflare to put an end to these attacks.

Solution

Cloudflare (CF) - a name not unfamiliar to many. Years ago, many people knew it for its free proxy servers, free SSL, CDN, and caches... there were many interesting things there. In the beginning, I used Cloudflare but didn't fully understand its functionalities, or even after setting up my website, I found that the access was slower or the caching features were quite annoying. However, recently Cloudflare seems to have transformed, with clearer operations, more documentation, and a stronger community.

Cloudflare stops Layer 3, 4 DDoS attacks. This means it can block suspicious requests before they reach Layer 7, your application. CF acts as a shield for you. All you need to do is configure it to block all suspicious queries.

To be honest, CF has many features that I haven't fully understood. But first, let's focus on defending against DDoS attacks, we can explore the other features later. The simplest way to defend against DDoS is by transferring your primary domain to Cloudflare, enabling the proxy and setting up rate limits.

Rate limiting is a way to limit the number of accesses within a specified period of time. This is one of the simple yet effective methods to counter DDoS attacks. Suddenly, an IP continuously sending requests to your address, whether with a motive to cause destruction or "unintentionally" using a certain "loop" command that they laugh about when asked, "Sorry, I accidentally triggered a bug"... Well, this is quite a "bug," and if you can't "fix" it, let me help.

You might find this intrusive, weren't we talking about setting up rate limits on the server earlier, and it didn't work? Well, remember that Cloudflare acts as an intermediary for all requests before they reach your actual server, meaning it operates at Layer 7, and according to them, CF has the technology or the capability to counter DDoS at layers 3 and 4. In summary, setting up rate limits at CF will block a considerable number of requests before they reach your actual server.

Now, I will guide readers on how to configure rate limits to minimize DDoS attacks through Cloudflare. Please note that this is one of the methods I have used, and there are many other methods, so if you have a better approach, please leave a comment below the article.

First, of course, you need to register a Cloudflare account and set up the domain you want to protect against DDoS. Don't worry, Cloudflare will guide you through the process after successful registration.

Once the domain is activated, go to "Security" > "WAF" on the left navigation bar.

WAF, in simple terms, is Cloudflare's firewall, which allows you to configure, block, modify... user requests before they reach your actual server. Look to the right side, to reach your server, a request will have to pass through all these security layers of CF.

Right there on the screen, switch to the "Rate limiting rules" tab and click the "Create rule" button at the bottom.

Here, give a name to the "Rule" and select the path for which Cloudflare will set the limit. For example, here I choose "/", meaning that all paths of the main domain will be protected.

Next, set the limit by filling in the "Requests" and "Period" fields - the number of requests within a specified period, combining to form the rate limit. For example, here I choose 10 requests within 10 seconds for each IP address. If the limit is exceeded, users will receive an HTTP Status 429 error.

Finally, save the configuration and try spamming your website to test if it's working properly.

If you're wondering how to determine the number of requests, I suggest you "experiment". Keep trying until you find the right number, as it depends on the number of requests your website receives. For example, if a page loads 20 requests in total, the limit should definitely be higher than 20. Not to mention 1 second, then 2 seconds... and then it continues to make "n" additional requests, or users continuously navigate your website, generating "m" requests within a certain period of time... In conclusion, this number depends heavily on your website, so try and find a reasonable number.

Finally, all the statistics about requests exceeding the limit will be displayed here. You can click on that "0" to view the details. Here, you can see that I haven't had any requests exceeding the limit in the past 24 hours.

Moving - From DigitalOcean to Cloudflare Pages

hoaitx — Wed, 19 Jun 2024 16:14:49 +0000

If you're interested, you may know that I use DigitalOcean to host this blog, with a modest configuration of 1GB RAM and 20GB SSD, which is sufficient for the TechStack that I have chosen. I call it sufficient because it still performs well with the current traffic, but deploying with Docker sometimes creates storage issues for the images it generates. Docker is known as the "hard drive killer" when you have many Images, combined with CI/CD setup, it's a "devastating combo". Just think, a 20GB hard drive, without subtracting the operating system, how can continuous deployment be possible? Occasionally, the server reports that the hard drive is full and I have to go in and delete some files.

By chance, I came across Cloudflare Pages which provides a solution for deploying various types of websites, such as Vue, React, Nuxt.js, Next.js... I was curious to see what it had to offer. I spent a whole week researching it. Finally, I decided to try migrating the two interface pages to see if it could be done.

The Process of Moving

According to Cloudflare, Cloudflare Pages is a JAMstack platform for user interface developers and website deployment. Pages focuses on developers as it offers many solutions such as Git integration to support continuous deployment (CI/CD), as well as the deployment speed and performance of the application through it.

Realizing the potential of Cloudflare, I could move the two Front-end pages: the admin control panel (AdminCP) and the blog interface. The AdminCP is built with Vue.js using SPA, while the blog is built with Nuxt.js using SSR. For the SPA, the resource consumption is not much. As far as I can tell, it only takes up a few MB of memory because it is deployed through Nginx. On the other hand, SSR takes up quite a bit of memory, I must say it is the most memory-consuming among the running services. Simply because it is deployed through a Node.js server, and Node.js consumes a lot of memory. Both Vue and Nuxt.js are supported by Pages, so I can easily migrate these two pages. But before migrating, it is necessary to evaluate the required features.

First is the admin panel page, since it is built with Vue and uses SPA, migrating it to Pages isn't too complicated. All that needs to be done is to change the environment variables to receive the configuration during build.

As for the blog interface page, I came up with an idea: instead of using SSR as it is currently, why not try converting it to SSG? This way, I can use a command to generate the website into static HTML files and upload them to any host that supports static pages, not just Cloudflare Pages. Moreover, the speed will be much faster compared to regular SSR because there is no need to query the database and generate HTML code for each visit. Thinking about it, I spent a whole week modifying the Nuxt code to work well with SSG mode.

Finally, earlier this week, I completed the basic process of moving the two interface pages to Pages. Of course, there are still a few bugs that need to be fixed, but currently, it fully meets the reading and search needs of everyone.

Benefits of Moving

I can save some resource costs for the admin panel and blog interface pages. Although it is not much, now I don't have to worry too much about server overload or any errors that may occur, as it can still function normally since Cloudflare has stored all the HTML.

The CI/CD process is shortened and less complicated. Previously, I needed to write many scripts to support this through Gitlab CI and Docker, but now, anytime I push code to Gitlab, it can build automatically.

I have switched DNS to Cloudflare to take advantage of their CDN infrastructure and data caching mechanism. The blog now has an impressive access speed.

Lastly, Web in the EDGE may become a trend in the future. Meaning you don't have to deploy a specific server to run a website, you can just run it through services like Pages. To learn more about this trend, readers can visit The Future of the Web is on the Edge.

What's Left to Do

Although the majority of the migration process went smoothly, there are still some issues that need time to address.

The first is undiscovered or discovered but non-impactful errors. This issue only requires time to fix, or if readers discover any errors, they can leave a comment to inform me and I will fix them.

There are some features that become unnecessary or disabled after migrating to Pages, and they need to be removed to avoid confusion in the future.

Another issue is that there is no way to activate a notification after a successful or failed Page deployment. Hopefully, Cloudflare will soon add a notification feature or, at least, I will run a curl command along with the npm run generate command to send notifications to Telegram.

That's what's currently on the agenda. In the long run, it is to completely eliminate the need for a server and move all services to the cloud. Then I will be able to set up an automated system and not worry too much about infrastructure.

Promise: How to Use and Some Notes!

hoaitx — Sun, 09 Jun 2024 07:24:44 +0000

It would be a glaring omission not to talk about Promise in JavaScript. In fact, there have been many articles written about Promise, which you can find through Google or occasionally come across in a programming-related community. But because Promise is an important concept and everyone has a different way of explaining it, I still decided to write this article.

When I first learned JavaScript, Promise was the most confusing thing. I thought I understood it and knew how to use it, but in reality, there were still many long and painful stumbles that taught me valuable lessons. I read many articles about Promise in both English and Vietnamese, and gradually everything started to make sense, helping me understand and use it correctly.

This article will not go into the concepts of Promise but rather touch on some notes and possible misunderstandings. It aims to provide readers with a general understanding and help them avoid some mistakes when writing code.

What is a Promise?

A Promise is an object that represents a future result. In other words, a Promise represents the result of an asynchronous function.

A Promise has three states corresponding to the three possible outcomes of an asynchronous function:

pending is the initial state, waiting for the result.
fulfilled is the successful state, with a result value.
rejected is the failure state, with an optional error value.

For example, let's create a Promise that takes a number x and returns the fulfilled state if x is divisible by 2, and the rejected state otherwise.

function isEven(x) {
  return new Promise((resolve, reject) => {
    if (x % 2 === 0) {
      resolve(true);
    } else {
      reject(new Error('x is not even'));
    }
  });
}

In essence, a Promise represents a future result. In the above example, creating a Promise is not necessary because all the actions inside the isEven function are synchronous. So, when should we use a Promise and what makes a function asynchronous?

What makes a function asynchronous? I have mentioned it in many articles. Some I/O tasks provided by asynchronous functions cannot immediately return a result; they depend on external factors such as hardware speed, network speed, etc. Waiting for these actions can waste a lot of time or cause serious bottlenecks.

For example, when making a GET request to the address https://example.com, the processing does not simply depend on CPU speed anymore; it also depends on your network speed. The faster the network, the quicker you receive the result. In JavaScript, we have the fetch function to send the request, and it is asynchronous, returning a Promise.

fetch('https://example.com');

To handle the result of a Promise, we use then and catch for success and failure cases, respectively.

fetch('https://example.com')
    .then(res => console.log(res))
    .catch(err => console.log(err));

If after some processing time, fetch is fulfilled, the function inside then will be activated. Otherwise, if fetch is rejected, the function inside catch will be executed immediately.

Sometimes you may come across questions like predicting the result of the following example:

console.log('1');

fetch('https://example.com')
    .then(res => console.log(res))
    .catch(err => console.log(err))
    .finally(() => console.log('3'));

console.log('2');

This question is actually to test your understanding of asynchronous behavior in JavaScript. The result will be 1, 2, 3 instead of 1, 3, 2. This is because of the nature of asynchronous processing. Since the result of asynchronous behavior will be returned in the future, JavaScript thinks, "OK, this asynchronous function does not have an immediate result yet. Let it be and continue processing the following commands. When everything is done, check if it has a result." For more information on how asynchronous processing works, you can refer to articles on Asynchronous Programming in JavaScript.

Promise has some useful static methods for various use cases, such as all, allSettled, any, and race.

Promise.all takes an array of Promises, returns a Promise, and is in the fulfilled state when all Promises in the array are successful. Otherwise, it is in the rejected state when at least one Promise in the array fails.

Promise.allSettled is similar to Promise.all but always returns the results of all Promises in the array regardless of success or failure. Both Promise.all and Promise.allSettled are useful when you need to run multiple asynchronous functions immediately without caring about the order of the results.

On the other hand, Promise.race returns the result of the Promise that is settled first, regardless of success or failure. Promise.any returns the first fulfilled Promise in the array. race and any are suitable when you have multiple Promises that perform similar actions and need a fallback between the results.

Promise Replaces "Callback Hell"

It is surprising to know that JavaScript used to not have Promise. Yes, you heard it right. This fact led Node.js to also not have Promise in its early days, and that is the biggest regret the creator of Node.js has.

Previously, all asynchronous tasks were handled through callbacks. We would define a callback function to handle the result in the future.

For example, an early asynchronous request function was XMLHttpRequest. It handled the result through a callback.

function reqListener() {
  console.log(this.responseText);
}

const req = new XMLHttpRequest();
req.addEventListener('load', reqListener);
req.open('GET', 'https://example.com');
req.send();

reqListener is a function that is called when there is a result from the request to https://example.com. Handling asynchronous behavior with callbacks brought some troubles, including what is commonly known as "callback hell".

For example, an asynchronous function fnA takes a callback function with two parameters: data representing the successful result and err representing the error. Similar functions include fnB, fnC, etc. If we want to combine these processing functions together, we need to nest them inside each other.

fnA((data1, err1) => {
    fnB((data2, err2) => {
        fnC((data3, err3) => {
        ....  
        });
    });
});

When there are too many callbacks written like this, our code becomes a literal "callback hell". It becomes messy and hinders the reading and understanding process.

Promise was introduced to bring a new approach to handling asynchronous behavior. We still use callbacks, but we are able to limit the "hell" by connecting everything sequentially through then.

fnA()
    .then(data => fnB(data))
    .then(data => fnC(data))
    ...  
    .catch(err => console.log(err));

After that, many asynchronous callback-based functions were rewritten using new Promise. In Node.js, we even have a built-in module called util.promisify specifically for this transformation. Callbacks are still supported, but with the benefits that Promise brings, many new libraries are using Promise as the default for handling asynchronous behavior.

Promise in Loops

There are many unfortunate mistakes when using Promise without fully understanding its essence and one of them is handling sequential asynchronous operations in a loop.

Suppose you need to iterate through 5 pages, making paginated API calls from 1 to 5 and concatenate the return values in order into an array.

const results = [];
for (let i = 1; i <= 5; i++) {
  fetch(`https://example.com?page=${i}`)
    .then(response => response.json())
    .then(data => results.push(data));
}

The above code creates a loop to fetch data from page 1 to page 5, and the returned data is pushed into the results array. At first glance, the result would be an array of data in the order from the first page to the last page. However, in reality, each time it runs, you will find that the data in results is randomly ordered.

Remember fetch, it returns a Promise, representing a future result... While for is trying to loop through as quickly as possible, you can think of it as all 5 fetch commands being called and started "almost instantly". At this point, CPU speed is less important - it's the network speed that determines which fetch command has the first result. As soon as it has the result, it immediately pushes it into results, resulting in the data being added randomly.

To solve this issue, there are several ways. For example:

const results = [];
fetch('https://example.com?page=1')
  .then(response => response.json())
  .then(data => {
    results.push(data);
    return fetch('https://example.com?page=2');
  })
  .then(response => response.json())
  .then(data => {
    results.push(data);
    return fetch('https://example.com?page=3');
  })
  ...

This is crazy, and nobody writes code like this. Imagine what if there were 1000 pages? It's a joke, but the example above attempts to illustrate the idea of how to wait for the previous request to complete before proceeding to the next request.

Bluebird is a very good Promise library that provides many utility functions to make working with asynchronous functions easier.

The above example can be rewritten using the each function provided by Bluebird.

const results = [];
Promise.each([1, 2, 3, 4, 5], (i) => {
  return fetch(`https://example.com?page=${i}`)
    .then(response => response.json())
    .then(data => results.push(data));
});

Async/Await - The Missing Piece of Promise?

To create a Promise, we use the syntax new Promise, but with async/await, we simply declare an async function.

async function isEven(x) {
  if (x % 2 === 0) {
    return true;
  } else {
    throw new Error('x is not even');
  }
}

While Promise uses then to handle the return result at some point in the future, async/await is as simple as using await.

const result = await fetch('https://example.com');
const resultJSON = await result.json();

Starting from Node.js version 14.8, we have the top-level await feature, which means await calls are no longer limited to inside an async function; they can be used outside as well. Before that, await could only be used inside an async function.

async function getData() {
    const result = await fetch('https://example.com');
    const resultJSON = await result.json();
}

While Promise uses .catch to handle errors, async/await uses try...catch.

async function getData() {
    try {
        const result = await fetch('https://example.com');
        const resultJSON = await result.json();
    } catch (err) {
        console.log(err);
    }
}

It is evident that async/await allows us to write asynchronous code as if it were synchronous, without callbacks and without the need for then. We simply wait for the result using await.

However, this can also lead to some dangerous misunderstandings, such as forgetting the await keyword to wait for the result of an asynchronous behavior or mistakenly thinking that an asynchronous function is a synchronous one.

async function getData() {
    try {
        const result = await fetch('https://example.com');
        const resultJSON = await result.json();
        return resultJSON;
    } catch (err) {
        console.log(err);
    }
}

function main() {
    const data = getData();
    console.log(data);
}

In essence, getData returns a Promise, so the above program does not work correctly if the intention is to get data from an API call. To fix this, we need to change it.

async function main() {
    const data = await getData();
    console.log(data);
}

return vs. return await

Sometimes you may come across code that looks like this:

async function fn() {
    ...  
    return await asyncFn();
}

The function fn is returning an await of the asynchronous function asyncFn. The author probably intended for fn to always return the result of asyncFn, as await is waiting for the result of the asynchronous function, effectively turning fn into a synchronous function, or in other words, "not" returning a Promise.

Unfortunately, this is a dangerous misunderstanding. In essence, await is only meant to be used at the top-level or inside an async function, and if it is async, it must return a Promise. Therefore, fn always returns a Promise. So why use return await asyncFn()?

Simply using return asyncFn() can save you a bit of keystrokes, as there is no significant difference compared to return await asyncFn(). The big change happens when there is a try...catch in return.

Let's consider the following two functions:

async function rejectionWithReturnAwait () {
  try {
    return await Promise.reject(new Error())
  } catch (e) {
    return 'Saved!'
  }
}

async function rejectionWithReturn () {
  try {
    return Promise.reject(new Error())
  } catch (e) {
    return 'Saved!'
  }
}

The first function, rejectionWithReturnAwait, is intentionally using return await, and when this Promise is rejected, the catch block quickly catches the error and executes the return 'Saved!' statement. This means the function returns a Promise containing the string 'Saved'.

In contrast, rejectionWithReturn, without await, is attempting to reject a Promise.reject(new Error()), and the catch block is never executed.

References: