For my use case, that felt like overkill. I did not need ranking dashboards or large-scale indexing, and honestly I did not want to pay for it. A friend jokingly said, “Why don’t you just send a curl request to Google and parse the HTML?” It sounded dumb at first, but the idea itself was not completely wrong.

The real issue is that Google has very strong protections and the markup changes often. That makes it unreliable.

So I chose DuckDuckGo. It has a html.duckduckgo.com endpoint that returns stable, JS-free HTML. DuckDuckGo provides this for text-only browsers, accessibility tools, and low-bandwidth use cases. It is predictable and easy to parse.

So I built the core functionality in Go. The core does two things:

• Sends requests to html.duckduckgo.com and parses the HTML to extract search results.

• Sends direct HTTP requests to public web pages and extracts readable text from them, as long as the page is openly accessible and not behind authentication.

This is important to say clearly: this is not a web-scraping or crawling tool. It does not bypass protections or execute JavaScript. It is meant for simple, repeatable searches and lightweight text extraction for agents and backend systems.

I chose Go for the core mainly because of networking. Go’s standard library gives solid HTTP, TLS, timeouts, cancellation, and connection reuse out of the box. The workload here is network I/O, not heavy computation, and Go handles that very reliably.

Once the core was working, I needed to expose it as a JavaScript library. I already knew this pattern from tools like esbuild and Prisma, where the core is written in a different language and wrapped by a JS layer. I wrote a JS wrapper that spawns the Go binary. Platform-specific binaries (darwin-arm64, darwin-x64, linux, windows) are listed as dependencies, so the correct one gets installed based on the user’s platform. At this point the library was around version 0.0.4, and everything worked fine locally. I posted about it on LinkedIn.

The real problem showed up later. I bundled my backend (built using Bun and Hono) into a single binary. In that setup, the JS wrapper could no longer reliably find the Go binary. The issue was not Go itself, but assumptions about filesystem layout once everything is bundled.

My first thought was to port the Go core to JavaScript, but that would mean losing Go’s networking advantages. Then I looked at how native bcrypt works. Its core is written in C/C++ and exposed as a .node extension, which is a completely different architecture. I also considered rewriting the core in C or Rust and shipping it as a native addon, but that felt like serious over-engineering for a library where performance is dominated by network latency.

So I went back and researched how Prisma handles binaries. That led to the actual fix.

Now the library still ships with platform binaries, but if the binary is not found at runtime, it automatically downloads it from the GitHub releases page and caches it locally. There is also an option for users to manage the binary themselves if they want full control. This removed fragile assumptions and made the setup much more reliable.

The current version at the time of writing is 0.1.0.

I initially thought this would be a very small project. Feature-wise, it is. But it pushed me into areas I had not dealt with before: how JS runtime libraries really work, how native binaries are distributed, and how easy it is to make the wrong architectural choice early.

I named the library quack-search because it uses DuckDuckGo, and ducks make a quack sound.

GitHub: https://github.com/adistrim/quack
npm: https://www.npmjs.com/package/quack-search

Article Banner Image is AI-generated using Gemini.

That’s it. Thanks for reading.

Setting up your own VPN sounds cool (and it is), but honestly, I wouldn't recommend it unless you really know what you're doing. If you mess up the setup, you could end up making things less secure. But if you're serious about handling your own privacy and ready to manage it properly, stick around.

Prerequisites

• AWS Free Tier account (optional but beneficial for beginners)

• Basic familiarity with SSH and EC2 instances

Step 1: Launch an EC2 Instance with OpenVPN

1. Launch a new instance and search for the OpenVPN Access Server AMI in the AWS Marketplace.

2. Select an instance type:

   • t2.micro: Free under the AWS Free Tier, suitable for running OpenVPN Access Server.

   • t2.nano: An economical choice if not using the Free Tier, costing around $0.006 per hour, capable of supporting OpenVPN’s needs for up to two devices.

3. Configure network settings to allow essential traffic only. Open port 1194 (UDP) for the VPN connection and port 943 for the admin interface.

4. Launch the instance with an SSH key pair for secure access.

VPN Location Matters: The location of your VPN server is based on the AWS region where the EC2 instance is hosted. For example, if your instance is in us-east-1 (North Virginia), your internet traffic will appear to originate from the United States. Similarly, hosting in ap-south-1 (Mumbai) routes traffic through the Indian internet. Choose a region based on the geographic benefits or restrictions you prefer.

Step 2: SSH into the Instance and Set Up the Admin User

1. Once your instance is running, SSH into it by the SSH code provided by the AWS.

2. Accept the licenses and agreements & keep the default settings.

3. You’ll be prompted again to login but as openvpnas.

4. Configure the admin password for the OpenVPN Access Server by running:

    sudo passwd openvpn
   

   Enter a strong password for logging into the OpenVPN admin portal. The same credentials can be used to access the user portal.

Step 3: Access the OpenVPN Admin Portal

1. Open a browser and navigate to the admin portal at:

    https://your-ec2-instance-public-ip:943/admin
   

2. Log in with the credentials you set in the previous step.

3. Configure your VPN settings as needed. This includes adding users, enabling multi-factor authentication (Optional).

4. Make sure both the options in the routing section are marked YES: Configuration/VPN Settings. Save the settings and update the running server.

   

   Note: OpenVPN Access Server's free license allows up to 2 simultaneous connections, suitable for personal use across two devices.

Step 4: Download and Install the OpenVPN Client

1. Now that your OpenVPN server is set up, open this URL:

    https://your-ec2-instance-public-ip:943
   

   This page provides a download link for the OpenVPN client, pre-configured to connect to your server.

2. Download and install the client on your device, then enter your VPN credentials when prompted. You’ll now be securely connected to your OpenVPN server on AWS!

Conclusion

In just a few steps, it’s possible to set up a fully working, self-hosted VPN on AWS that keeps internet connections secure and private from anywhere. This setup is a good enough option for anyone who wants more control over their online security without paying for a huge monthly subscription. Even though it’s self-hosted, the VPN runs fast (actually fast) and reliably thanks to AWS’s strong infrastructure, making it perfect for streaming and browsing.

However, I do not recommend setting this up unless you exactly know what you're doing. Self-hosting a VPN means you are responsible for securing the server, managing the EC2, handling firewall rules, and monitoring for potential vulnerabilities. A badly configured VPN can actually expose you to more risks than using a trusted paid service.

Benefits (only if managed well) according to me:

• Privacy and Control: Since the VPN is self-hosted, all data stays private without being handled by any third party services.

• Geographic Flexibility (not as flexible as traditional VPNs): AWS lets users pick server locations from different regions, like us-east-1 for the U.S. or ap-south-1 for India, offering more choices based on where the connection needs to be routed.

• Cost Efficiency: Using AWS’s Free Tier and affordable instances like t2.nano helps keep costs low while still getting good performance.

After using this setup for a long time now, it has been extremely reliable on both laptop and mobile. The VPN connection feels smooth, even when streaming 4K videos, with almost no noticeable difference compared to a regular connection. CPU usage on the EC2 instance usually stays under 10%, except during heavier activities like video calls, or being active on Discord (I haven’t tested it for gaming).

Git is a free and open-source distributed version control system (DVCS) that is widely used in software development. It helps track changes, collaborate with others, and manage branches effectively.

This brief introduction only touches on the basics of what Git can do. For a deeper dive, check out this link.

What are Branches?

Imagine the codebase as a linear highway representing its history. A regular Git branch is like an exit ramp off that highway, creating a new path for development that diverges from the main road (often called master or main). On this new branch, you can work independently, making changes without affecting the main codebase.

To create a regular branch named feature-branch, use the following command:

git checkout -b feature-branch

This command creates a new branch and switches your working directory to it.

Regular branches offer the advantage of isolating new features for testing while maintaining a connection to the project’s history. For a detailed understanding of branches in Git, check out this link.

What are Orphan Branches?

Unlike regular branches that extend from existing history, orphan branches are like entirely new roads built from scratch. They have no connection to the main codebase or any other branch's history.

To create an orphan branch named experimental-code, use the following command:

git checkout --orphan experimental-code

This command creates a new branch named experimental-code and detaches your working directory from any previous branch, making it the starting point for the orphan branch.

Orphan Branch Use Cases

• Standalone Experiments: When exploring a radical new feature or refactoring approach, you might not want to clutter the main branch's history. An orphan branch allows you to experiment freely.

• External Code Integration: If you're incorporating code from an external source that doesn't align with your project's history, creating an orphan branch helps maintain a clean separation.

• Brand New Repositories: When requesting a code review for a brand new repository, an orphan branch provides a clean slate for reviewers.

Key Differences to Remember

• History: Regular branches maintain a connection to the main codebase's history, while orphan branches have no such connection.

• Merging: Merging orphan branches back into the main branch can be trickier than standard merges due to the lack of shared history.

Conclusion

Regular branches and orphan branches each serve unique purposes. Regular branches are ideal for most development workflows, offering isolation while preserving historical context. Orphan branches, on the other hand, are useful for scenarios where a clean break from existing history is needed. Understanding the strengths and considerations of both types of branches allows you to effectively leverage them to enhance your Git development experience.

During my first internship, I had to write code that was supposed to be deployed on the servers. The code that ran perfectly on my machine (thanks, 127.0.0.1) was pretty bad on the servers. It was a humbling experience, but it opened my eyes as a beginner to the crucial fact: development isn't just about what works on my machine – it's about making things work consistently in different environments.

After my internship was over I carried those lessons forward with me and embraced them.

The CI/CD - Continuous Integration (CI) Continuous Deployment/Delivery (CD)

What is it? In simpler words making an environment that tests the new merge (new code addition) and if that code passes the test without any red flags then it gets staged for the deployment, and this whole process is automated the best example for beginners is GitHub Actions.

Benefits of CI/CD:

Early Detection of Bugs: Automated tests run on every code commit, catching issues early.

Consistent Releases: Frequent, smaller updates reduce the risk and complexity of big releases.

Faster Feedback: Devs receive immediate feedback, allowing them to address issues quickly.

Reduced Manual Effort: Automation minimizes the manual steps involved in integration and deployment.

Setting Up a CI/CD Pipeline:

Version Control: Start by using a version control system like Git. All your code changes should be committed to a shared repository (e.g., GitHub, GitLab).

CI Configuration: Set up a CI server to automate the build and test process. Popular tools include Jenkins, GitHub Actions, and GitLab CI/CD.

Example: GitHub Actions for CI for anodeproject

Create a .github/workflows/ci.yml file in your repository:

name: CI Pipeline

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v2

    - name: Set up Node.js
      uses: actions/setup-node@v2
      with:
        node-version: '21'

    - name: Install dependencies
      run: npm install

    - name: Run tests
      run: npm test

This configuration runs the CI pipeline on every push, checking out the code, setting up Node.js, installing dependencies, and running tests.

This ci.yml can be extended depending on the deployment environment we are working with.

Dockerizing

Basically packing up code in a cartoon (container) box with all the dependencies and environment it requires, which makes it easy to ship/share.

Containers bundle the application code with all its dependencies, libraries, and configuration files, ensuring that the application runs consistently across different environments.

Benefits of Using Docker

Consistency: Docker containers ensure that your application behaves the same way in the development, testing, and production environments.

Isolation: Each container is isolated from others, preventing conflicts between applications.

Portability: Docker containers can run on any system that supports Docker (Raspberry Pi too), making it easy to move applications between environments.

Scalability: Docker makes it straightforward to scale applications horizontally by running multiple container instances.

Getting Started with Docker

Installing Docker: Before you can start using Docker, you need to install it on your local machine. Docker provides detailed installation instructions for different operating systems on its official website.

Creating a Dockerfile: A Dockerfile is a text file that contains instructions on how to build a Docker image. Here’s a simple example for a Next.js application:

FROM node:21-alpine

WORKDIR /usr/src/app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 3000

CMD ["npm", "run", "dev"]

Building the Docker Image: With your Dockerfile ready, you can build the Docker image using the following command:

docker build -t my-next-app .

Running the Container: Once the image is built, you can run it as a container:

docker run -d -p 3000:3000 my-next-app

If everything is alright then the web application will be running at localhost:3000

Code for Collaboration: Writing Clear and Understandable Code

I've come to realize that my code isn't solely for my understanding (although sometimes it feels nice that nobody else can understand what's happening here). But good code is not just for others; it makes my own life easier in the long run. Using clear variable names and comments makes my code easier to navigate, for both myself and my teammates. This makes projects more collaborative and maintainable in the long run.

Principles of Writing Understandable Code

Descriptive Variable Names: Instead of using cryptic abbreviations or single-letter variable names, opt for descriptive names that convey the purpose of the variable. For example:

# Bad
x = 10
y = calculate(x)

# Good
number_of_items = 10
total_price = calculate_total_price(number_of_items)

Meaningful Comments: Comments should explain the intention behind complex code segments or provide context where necessary. However, strive to write self-explanatory code whenever possible.

// Bad
// Increment counter
counter += 1;

// Good
// Increase the counter by one
counter += 1;

Consistent Formatting: Consistent formatting improves code readability and makes it easier to understand at a glance. Follow established coding conventions or style guides for the programming language you're using.

// Inconsistent formatting
if(condition){
doSomething();
} else{
doSomethingElse();
}

// Consistent formatting
if (condition) {
    doSomething();
} else {
    doSomethingElse();
}

Modularization: Break down complex tasks into smaller, modular functions or classes. Each function or class should have a single responsibility, making it easier to understand and maintain.

# Monolithic function
def process_data(data):
    # Lengthy code here...

# Modularized functions
def clean_data(data):
    # Clean data logic...

def analyze_data(data):
    # Analyze data logic...

def visualize_data(data):
    # Visualize data logic...

Conclusion

Deploying my code these past few months has opened my eyes to a whole new world. It's pushed me to think beyond the familiar local environment and see the bigger software delivery picture. This journey has also emphasised the importance of writing code that's not just functional, but also collaborative and maintainable.

So I have graduated from my GitHub comfort zone? Maybe Yes.

But, there's always A LOT left to LEARN.