DEV Community: Faizan

MCP: The Simple Protocol to Make AI Actually Useful

Faizan — Tue, 22 Jul 2025 05:33:14 +0000

MCP is like creating a universal plug for AI tools. Here’s why that matters

Let’s be honest. AI assistants are smart, but they’re mostly stuck inside a chat window. They can write an email, but they can’t send it. They can plan a trip, but they can’t book it.

To do real things, they need to connect to other apps and services — what developers call “tools.” And right now, that connection is a mess.

Every time a developer wants their AI agent to use a new tool, like a weather API or a flight booking system, they have to build a custom bridge. It’s like needing a different, clunky adapter for every single device you own.

This is the problem that the Model Context Protocol, or MCP, is trying to solve.

So, What is MCP?

Think of it this way: Remember the days before USB? (If you are not that old, imagine it for understanding’s sake.) You had a different cable for your keyboard, your mouse, your printer… it was a tangled nightmare. Then USB came along and created one standard plug that just worked for everything.

MCP aims to be the USB for AI.

It’s a proposed set of rules( by Anthropic, the company behind Claude) — a standard language — that lets any AI agent talk to any tool without needing a custom-built connector. It’s a simple, universal agreement on how to ask for things and get a response.

How It Works (The Simple Version)

Instead of a developer writing tons of “glue code,” an MCP server handles the conversation. The process is straightforward:

The Handshake: An AI agent connects to an MCP server and asks, “Hey, what can you do?”
The Menu: The server sends back a simple list of its available tools and what information each one needs. For example:
- get_current_weather(location: string)
- book_flight(destination: string, date: string)
- add_to_calendar(event_name: string, time: string)
The Request: The AI agent, now knowing the menu, can make a clear request. “I need to use the get_current_weather tool. The location is 'Kolkata'.
The Result: The MCP server takes that request, runs the actual code to get the weather, and sends the answer back to the AI agent in a standard format.

The AI agent doesn’t need to know the messy details of how the weather API works. It just needs to know the standard way to ask. The MCP server handles the rest.

Why Should You Care?

This might sound like a technical detail, but its impact is huge.

If you’re a developer:

Less grunt work. You can stop writing endless custom API wrappers. Just make your tool available via an MCP server, and any compliant AI can use it.
Wider reach. Build a tool once, and it’s instantly compatible with an entire ecosystem of agents. You can focus on creating a great tool, not on the plumbing.

If you’re not a developer:

More capable AI. This is how we get AI assistants that can do things. Your AI could seamlessly check your flight status, order your lunch, and update your project management board, all without you lifting a finger.
Things will just work. No more worrying about whether your AI assistant has the right “plugin” or “integration.” If both the agent and the tool speak MCP, they can work together.

Is This the Future?

MCP is still a new idea. It needs big players — the companies building the AI models and the companies building the tools — to adopt it.

But the logic is solid. Standardization is what unlocks real progress. The internet runs on standard protocols like TCP/IP. Our devices connect using standards like USB and Wi-Fi.

MCP is a bet that the same thing needs to happen for AI agents. By creating a simple, open standard for communication, it could clear the path for a new wave of AI applications that are far more useful and connected to the real world. It’s an idea worth watching.

Thank you for reading! If you have any feedback or notice any mistakes, please feel free to leave a comment below. I’m always looking to improve my writing and value any suggestions you may have. If you’re interested in working together or have any further questions, please don’t hesitate to reach out to me at fa1319673@gmail.com.

What is Secure Coding?

Faizan — Sat, 03 Aug 2024 08:44:44 +0000

Imagine building a house without a sturdy foundation or reliable locks on the doors. It might look impressive from the outside, but inside, it’s vulnerable to collapse and break-ins. Secure coding is akin to constructing that solid foundation and installing those reliable locks. It ensures that your software is robust, resilient, and safe from malicious intrusions.

Secure coding is the practice of writing software that protects itself against cyber threats and vulnerabilities. It involves implementing security measures during the coding phase rather than after the software is built. This proactive approach minimizes the risk of attacks, safeguarding sensitive data, and maintains the integrity and availability of the system.

Insecure code, on the other hand, is like leaving your house with the doors wide open. It exposes your software to numerous threats, such as data breaches, unauthorized access, and service disruptions. Without secure coding practices, your application becomes an easy target for hackers, jeopardizing both user trust and business operations. By understanding and implementing secure coding best practices, you can solidify your software against these risks and ensure a safer digital environment.

In this article, we will explore the most common security threats, principles of secure coding, and the best practices for secure coding, which will help you make your software robust and safer.

Common Security Threats

SQL Injection

SQL Injection is like giving someone an invitation to tamper with the blueprints of your house. When a website or application accepts user input and incorporates it directly into an SQL query without proper validation, an attacker can insert malicious SQL code. This code can manipulate the database, allowing the attacker to access, modify, or delete data. For example, instead of entering a username, an attacker might input a code that tricks the database into revealing all user passwords.

Cross-site Scripting (XSS)

It is like someone tricking you into running dangerous commands in your own home, like convincing you to open an email that infects your computer. XSS occurs when an attacker injects malicious scripts into web pages viewed by other users. These scripts can hijack user sessions, deface websites, or redirect users to malicious sites. For instance, an attacker could post a harmful script in a comment section, which then runs in the browser of anyone who views that comment.

Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is like someone tricking you into signing a document without knowing its contents. CSRF attacks occur when an attacker tricks a user into performing actions they didn’t intend to do, like changing their account email or making a transaction. This is often done by exploiting the user’s authenticated session with a website. For example, if you’re logged into your bank account, an attacker could send you a link that, when clicked, transfers money to their account without your knowledge.

Remote Code Execution (RCE)

Remote Code Execution (RCE) is comparable to letting a stranger remotely control your home appliances. RCE happens when an attacker exploits a vulnerability to run arbitrary code on a target system. This can lead to complete control over the affected system, allowing the attacker to steal data, install malware, or disrupt operations. For example, if an application allows user-uploaded files without proper checks, an attacker could upload and execute a malicious file, taking over the server hosting the application.

Principles of Secure Coding

Though there are many, I will show you the 3 most important here that you should always try to follow:

Security by Design

Security by Design is like building a house with security features integrated from the ground up. Instead of adding locks and alarms after construction, security measures are considered and implemented during the initial design and development stages. This approach ensures that security is an inherent part of the system, making it more robust and less prone to vulnerabilities.

Least Privilege Principle

The Least Privilege Principle is similar to giving each person in your house access only to the rooms they need. In cybersecurity, this means granting users and systems the minimal level of access required to perform their functions. By restricting permissions, you limit the potential damage in case of a security breach.

Defense in Depth

Defense in Depth is akin to having multiple layers of security around your house: a fence, security cameras, locked doors, and an alarm system. This strategy involves implementing several layers of defense mechanisms to protect against threats. If one layer is compromised, the other layers continue to provide protection.

Best Practices for Secure Coding

Input Validation and Sanitization

Input validation and sanitization are like filtering and cleaning water before it enters your home. Validation ensures that the data is in the expected format and type, while sanitization removes any harmful elements. These practices prevent malicious data from exploiting vulnerabilities in your application. For example, validating email addresses to ensure they follow the correct format and sanitizing user inputs to remove SQL injection attempts.

Techniques and Tools

Employing the right techniques and tools is akin to using advanced tools and materials for constructing a safe building. Techniques such as code reviews, static code analysis, and automated testing help identify and mitigate security vulnerabilities. Tools like OWASP ZAP for web application security testing and SonarQube for code quality analysis are invaluable in ensuring secure coding practices.

Authentication and Authorization

Authentication and authorization are like verifying a guest’s identity before granting them access to specific areas of your house. Authentication confirms that users are who they claim to be, while authorization determines what resources they can access. Secure methods include using multi-factor authentication (MFA) and role-based access control (RBAC) to ensure robust security. For instance, requiring a password and a one-time code sent to a user’s phone for logging in.

Error Handling and Logging

Proper error handling and secure logging are like having a detailed incident report without revealing sensitive information. Error handling ensures that the application gracefully manages unexpected issues without crashing or exposing sensitive data. Secure logging involves recording activities for audit purposes while protecting sensitive information.

Data Encryption

Data encryption is like storing valuables in a safe. It converts data into a coded form that is unreadable without the decryption key, protecting it from unauthorized access. Implementing encryption for data at rest and in transit ensures that sensitive information remains confidential and secure.

Dependency Management

Managing dependencies is like regularly maintaining and updating your home’s safety features. Keeping libraries and dependencies up-to-date ensures that your application is protected against known vulnerabilities. Regularly reviewing and updating these components, and using tools like Dependabot or Snyk, helps in identifying and mitigating risks associated with outdated or insecure dependencies.

Conclusion

Adopting secure coding practices is crucial for creating reliable and safe software. By validating and cleaning user inputs, using the right tools, securing authentication and authorization processes, handling errors properly, encrypting data, and keeping dependencies up-to-date, you protect your applications from various threats. As technology advances, staying proactive about security helps ensure your software remains secure and trustworthy in an ever-changing digital world.

GitHub Actions Explained

Faizan — Wed, 24 Jul 2024 12:31:18 +0000

In the rapidly evolving landscape of software development, the ability to automate testing and deploy applications efficiently stands as a cornerstone of success. GitHub Actions, a powerful feature within the GitHub platform, has emerged as a pivotal tool in this regard. By enabling developers to create custom workflows for continuous integration (CI) and continuous deployment (CD), GitHub Actions simplifies the complexities of the CI/CD pipelines, fostering a culture of continuous improvement. Leveraging GitHub workflows, automation, and the GitHub marketplace’s vast array of pre-built and custom actions, developers can streamline their development processes, ensuring that integration and deployment are as seamless as possible.

This comprehensive guide aims to unfold the multifaceted capabilities of GitHub Actions, providing readers with a detailed roadmap from the basics to more advanced features.

What You Need to Know About GitHub Actions

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that run tests whenever you push a change to your repository, or that deploy merged pull requests to production. GitHub Actions can automate your workflow, allowing you to build, test, and deploy your code right from GitHub, saving you a lot of time and effort.

Automate Workflows

Automate, customize and execute your software development workflows right in your repository with GitHub Actions. You can discover, create, and share actions to perform any job you'd like, including CI/CD, and combine actions in a completely customized workflow.

For example, you can use GitHub Actions to automatically build and test your code every time you push a commit to GitHub, ensuring that your code is always up-to-date and working as expected.

Customizable and Integrative

GitHub Actions are highly customizable. You can create your actions or use actions from the GitHub Marketplace to build workflows that meet your specific needs. GitHub Actions integrates seamlessly with other GitHub features, such as pull requests and issues, making it easy to manage your entire workflow in one place.

Community and Affordability

GitHub Actions has a large and active community. You can find many pre-built actions in the GitHub Marketplace, and you can also share your actions with the community. GitHub Actions is free for public repositories, and you get 2,000 free minutes of build time per month for private repositories, making it an affordable option for developers of all sizes.

Getting Started

GitHub provides starter workflows for a variety of languages and tooling. For instance, you can publish Node.js packages to a registry as part of your continuous integration (CI) workflow, or create a continuous integration (CI) workflow to build and test your PowerShell project. To get started, you can use the user interface of GitHub.com to add a workflow that demonstrates some of the essential features of GitHub Actions.

Building Your First Workflow

To get started with GitHub Actions, you'll need to set up the environment, create a basic YAML file, and test the workflow. Here's a step-by-step guide:

Setting Up the Environment

Create a new directory named .github/workflows within your repository. This is where GitHub will look for workflow files.
Inside the .github/workflows directory, create a new YAML file with an .yml or .yaml extension. You can give it any name you prefer, such as github-actions-demo.yml .

Creating a Basic YAML File

3. Copy the following YAML code into your newly created file :

on: [push]

jobs:
  build:
    name: Hello world
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Write a multi-line message
        run: |
          echo This demo file shows a
          echo very basic and easy-to-understand workflow

This basic workflow is triggered whenever code is pushed to the repository (on: [push]). It defines a single job build that runs on the latest Ubuntu runner (runs-on: ubuntu-latest). The job consists of two steps:

The first step checks out the repository code using the actions/checkout@v2 action.
The second step runs a multi-line Bash script that prints a message to the console.

4. Commit the YAML file to your repository's default branch.

Testing the Workflow

5. After committing the workflow file, navigate to the "Actions" tab in your repository on GitHub.com. You should see your new workflow listed there.

6. Click on the workflow to view its execution details. The workflow should run automatically after your commit if everything is set up correctly.

7. Expand the job run to see the output of each step. You should see the message you defined in the run step.

By following these steps, you've successfully created and tested your first GitHub Actions workflow. You can now build upon this foundation to automate more complex tasks, such as running tests, building and deploying applications, and more.

Detailed Breakdown of Components

A workflow is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked into your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule.

Workflows, Jobs, and Steps

A workflow must contain one or more events that will trigger it, one or more jobs that will execute on a runner machine and run a series of steps, and each step can either run a script or an action. A job is a set of steps in a workflow executed on the same runner, where each step is either a shell script or an action. An action is a custom application that performs a complex but frequently repeated task, helping reduce repetitive code in workflow files.

Events and Triggers

An event is a specific activity that triggers a workflow run, such as creating a pull request, opening an issue, or pushing a commit. Workflows can also be triggered on a schedule, by posting to a REST API, or manually. There are various types of events, including repository events like creating or modifying issues, pull requests, releases, discussions, and more.

GitHub provides filters to control when a workflow should run based on activity types, branches, file paths, and other criteria. For example, the branches filter causes a workflow to run only when a push to a specific branch occurs, and the paths filter allows it to run workflows based on changed file paths.

Actions and Runners

A runner is a server that runs your workflows when triggered, with each runner executing a single job at a time. GitHub provides Ubuntu Linux, Microsoft Windows, and macOS runners, where each workflow run executes in a fresh, newly-provisioned virtual machine.

GitHub-hosted runners are available for public and private repositories, with different specifications and pricing models. For private repositories, jobs use the account's allotment of free minutes and are then charged per minute. GitHub also offers larger, managed virtual machines with more resources, static IP addresses, Azure private networking, and advanced features like GPU and ARM-powered runners.

The communication between GitHub and self-hosted runners works by the runner connecting to GitHub (outbound) and keeping the connection open, allowing events to be pushed to the runner through the established connection.

Advanced Techniques

Integrating with Third-Party Tools

When a third-party application requests access to your GitHub data, it will display the developer's contact information and the specific data being requested. Since the application is developed by a third party, GitHub does not have information on how the requested data will be used, so it is important to contact the developer if you have any concerns.

Applications can have read or write access to your GitHub data. Read access allows an application to view your data, while write access permits it to modify your data. Scopes are named groups of permissions that an application can request to access public and non-public data. For example, if an app requests the user:email scope, it will have read-only access to your private email addresses. However, currently, you cannot scope source code access to read-only.

It is recommended to regularly review your authorized integrations and remove any unused applications or tokens to minimize potential risks. Additionally, you should use credentials with minimal required permissions and be mindful that any user with write access to your repository has read access to all configured secrets.

Managing Workflow Secrets

Sensitive values should never be stored as plaintext in workflow files but rather as secrets. Secrets are encrypted before reaching GitHub, helping minimize risks related to accidental logging. GitHub uses a mechanism to redact secrets from run logs, but this redaction is not guaranteed due to the various transformations secrets can undergo.

To ensure proper secret redaction and limit associated risks, follow these best practices :

Avoid structured data as secrets: Structured data like JSON or XML can cause redaction failures since redaction relies on finding exact matches.
Register all used secrets: If a secret is used to generate another sensitive value, register that value as a secret to ensure redaction.
Audit secret handling: Review the source code and actions used in your workflows to ensure secrets are not sent to unintended hosts or printed to logs.
Use minimally scoped credentials: Ensure that the credentials used in workflows have the least required privileges.
Audit and rotate secrets: Periodically review and remove unnecessary secrets, and rotate secrets to reduce the window of potential compromise.
Consider requiring reviews for access: You can use required reviewers to control access to environment secrets.

GitHub-hosted runners take measures to mitigate security risks, such as providing software bills of materials (SBOMs) and blocking access to malicious sites. However, self-hosted runners can be persistently compromised by untrusted code and should be used cautiously, especially for public repositories. To improve security, you can use the REST API to create ephemeral, just-in-time (JIT) runners that perform at most one job before being automatically removed.

Scaling with Self-Hosted Runners

You can automatically scale the number of self-hosted runners in your environment based on webhook events with a particular label. However, GitHub recommends implementing autoscaling with ephemeral self-hosted runners, as persistent runners cannot guarantee that jobs are not assigned during the shutdown.

To add an ephemeral runner, include the --ephemeral parameter when registering the runner using config.sh . The runner will be automatically de-registered after processing one job, and you can then automate the process of wiping the runner.

You can create an autoscaling environment by using payloads received from the workflow_job webhook, which contains information about the stages of a workflow job's lifecycle. You can register and delete repository, organization, and enterprise self-hosted runners using the API and appropriate authentication methods.

When adding self-hosted runners, consider the level of ownership and management. If a centralized team will own the runners, add them at the highest mutual organization or enterprise level. If each team will manage its runners, add them at the highest level of team ownership, such as the organization level.

Conclusion

From navigating the basics and crafting your first workflow to diving deep into advanced techniques and security best practices, the guide has aimed to equip you with the necessary knowledge to automate, integrate, and optimize your software development processes efficiently. Emphasizing GitHub Actions' adaptability, the discussion highlighted how this powerful tool can streamline workflows, foster continuous improvement, and enable a culture of innovation by leveraging automation, seamless integration, and community-driven enhancements.

FAQs

1. What exactly are GitHub Actions?
GitHub Actions is a CI/CD platform that automates your software's build, test, and deployment processes. It enables you to create workflows that automatically build and test every pull request to your repository or deploy merged pull requests to production environments.

2. How do GitHub Actions differ from other CI/CD tools?
While both GitHub Actions and other CI/CD tools like GitLab CI/CD automate software deployment processes, they differ in usability and configuration. GitLab CI/CD has a visual editor for simple workflows and requires YAML for more complex setups. GitHub Actions uses YAML extensively, supported by a large community that provides prebuilt workflows and tools to ease configuration.

3. What types of actions can you create with GitHub Actions?
In GitHub Actions, you can develop Docker container actions, JavaScript actions, and composite actions. Each action type requires a metadata file that specifies the inputs, outputs, and the main entry point of the action. The metadata file must be named action.

4. What is the relationship between GitHub Actions and workflows?
GitHub Actions is a tool that automates workflows within the GitHub platform, where you can also manage code and collaborate on pull requests and issues. A workflow in GitHub Actions refers to an automated sequence of operations set up in your GitHub repository to handle tasks like building, testing, and deploying applications.

Thank you for reading! If you have any feedback or notice any mistakes, please feel free to leave a comment below. I'm always looking to improve my writing and value any suggestions you may have. If you're interested in working together or have any further questions, please don't hesitate to reach out to me at fa1319673@gmail.com.

5 Common Myths About Artificial Intelligence

Faizan — Thu, 18 Jul 2024 14:42:06 +0000

Artificial intelligence (AI) has quickly gained traction in a variety of industries, promising transformative advances and novel solutions. However, amid the excitement and potential, a number of myths and misconceptions about AI have surfaced. These myths can lead to reluctance to implement AI technologies in businesses or unrealistic expectations of AI applications. In this article, we will debunk the five most common myths about artificial intelligence, separating fact from fiction and shedding light on the truth behind AI.

Myth 1: AI Will Take Over the World

The idea that artificial intelligence (AI) will take over the world and create a dystopian future in which intelligent machines rule over humans is one of the most prevalent fears related to AI. Books and films based on science fiction have contributed to this fear. In actuality, though, AI is incapable of independent thought or behaviour. AI systems work within the constraints imposed by their programming and data inputs because they are designed and developed by humans.

They are not sentient, and they are not capable of thinking or acting beyond the parameters of their programming.

Artificial intelligence (AI) is a tool that can be used to improve many facets of our lives and increase human capabilities. It is employed to solve challenging issues, make wise decisions, and optimise procedures. Even though AI has a lot of potential to change society, humans are still in charge of it at all times. AI must be developed and governed responsibly to ensure that it continues to be a useful tool and does not endanger humankind.

Myth 2: AI Will Take All of Our Jobs

Another widespread misconception regarding AI is that it will cause widespread unemployment because it will replace human labour in all industries. Although artificial intelligence (AI) can automate some jobs and procedures, it is not meant to completely replace people. AI technologies, on the other hand, are meant to improve efficiency, supplement human capabilities, and manage tedious or repetitive tasks. Artificial Intelligence frees humans from repetitive tasks so they can concentrate on higher order cognitive functions, creative expression, and difficult problem solving.

History has shown that technological advancements, including AI, disrupt the employment landscape by making some jobs obsolete and creating new ones. AI will certainly displace certain occupations as its capabilities improve, but it also creates new job opportunities. For example, the development and maintenance of AI systems require skilled professionals such as data scientists and machine learning specialists. Moreover, AI can enhance job productivity and create new roles that we may not even envision yet. Therefore, the long-term impact of AI on the job market is likely to be positive.

Myth 3: AI Is Sentient or Conscious

AI is often portrayed in popular culture as sentient beings with consciousness, emotions, and the ability to think and reason like humans. However, this is far from the truth. AI systems, no matter how advanced, are not capable of feeling emotions or having subjective experiences. They are not sentient or conscious entities; they are simply tools that can process information and make decisions based on algorithms and data inputs.

AI systems, particularly those based on machine learning algorithms, learn patterns from past data and make predictions without being explicitly programmed. They excel at specialized tasks such as natural language processing or image recognition, but their abilities are limited to the specific tasks they are trained for. They lack comprehensive comprehension or self-awareness like humans possess. It is important to understand this distinction to avoid overestimating the capabilities of AI.

Myth 4: AI Is a Threat to Humanity

The idea of AI as a threat to humanity has been a prevalent theme in science fiction stories and movies. However, in reality, AI is not inherently dangerous or a threat to humanity. The risks associated with AI come from how it is used and the decisions made by those who control it, rather than from the technology itself. Responsible development and ethical use of AI systems are essential to mitigate any potential risks.

AI can be used for both positive and negative purposes, depending on the intentions of its creators and users. It is crucial to ensure that AI is developed and used in a manner that aligns with ethical standards and societal values. Robust regulations and guidelines are necessary to prevent misuse of AI technology and to ensure that it is used for the greater good of humanity.

Myth 5: AI Is Magic

AI is often perceived as something mysterious and magical, capable of performing tasks that seem beyond human comprehension. However, AI is not magic. It is based on complex algorithms and data processing techniques that can be understood and explained. While the inner workings of advanced AI systems, such as deep learning algorithms, may be complex, they are ultimately based on mathematical principles and statistical models.

AI is a tool that can be harnessed by humans to solve problems and make informed decisions. It is not a mystical force that operates outside the realm of understanding. By demystifying AI and promoting a deeper understanding of its principles and limitations, we can harness its full potential and use it to drive positive change in various domains.

The Future of AI: Separating Fact from Fiction

As AI continues to evolve and shape our world, it is crucial to separate fact from fiction and dispel the myths surrounding this transformative technology. By understanding the true capabilities and limitations of AI, we can make informed decisions about its implementation and development. AI is not a threat to humanity, but a powerful tool that, when used responsibly, has the potential to enhance our lives, improve productivity, and drive innovation in diverse fields.

Thank you for reading! If you have any feedback or notice any mistakes, please feel free to leave a comment below. I’m always looking to improve my writing and value any suggestions you may have. If you’re interested in working together or have any further questions, please don’t hesitate to reach out to me at fa1319673@gmail.com.

Sending Emails in Node.js Using Nodemailer

Faizan — Fri, 12 Jul 2024 12:01:43 +0000

In Today’s Article, I will explain how to send e-mails from your Node.js server with the use of a library named “Nodemailer”.

But before we begin, it’s important to note that a foundational understanding of creating APIs in a Node.js server, whether with or without Express.js, is assumed. If you’re unfamiliar with these concepts, I recommend exploring resources on creating an Express.js server and APIs first. You’ll find ample tutorials, YouTube videos, and articles online to build a strong foundation. Once you’re comfortable with the basics you can follow along with this article. So for the people who already know these things, let’s dive right into the heart of the matter.

Set up your Express.js Server

Open your project directory and run the below commands to set up your node+express server. You can use either npm or yarn package manager, I am using npm here.

npm init -y

This will initialize your Node.js project.

npm i express cors

This command will install Express and Cors for your server.

Now create an index.js file which will be your main file and paste the below code:

const express = require('express');
const cors = require('cors');

const app = express();
const port = 3000;

// Use the cors middleware to enable CORS for all routes
app.use(cors());

// Use the express.json() middleware to parse JSON data from requests
app.use(express.json());

// Define a sample route
app.get('/', (req, res) => {
  res.send('Hello, Express server is up and running!');
});

// Start the server
app.listen(port, () => {
  console.log(`Server is running on port ${port}`);
});

Then run:

node index.js

This will start your server on port 3000, you can check if your server is running by going to http://localhost:3000

Installing and Using Nodemailer

Now that you have your Express server up and running, it's time to install nodemailer which we will use to send emails. Run the command below:

npm install nodemailer

This will install nodemailer as a dependency in your Node.js project. Now require it in your index.js in a const variable below const express shown below:

const nodemailer = require('nodemailer')

Testing with a Test Account

Now that you have installed nodemailer, we will try sending emails with nodemailer with a test account first before using our gmail account. For that, you have to create an API endpoint in your server and define a few things

app.post('/testingroute', async (req, res) => {

});

Inside the route, you have to define 2 things, a transporter and a test account for which nodemailer provides functions

// This will create a test account to send email
let testAccount = await nodemailer.createTestAccount();

// This is a transporter, it is required to send emails in nodemailer
let transporter = nodemailer.createTransport({
        host: "smtp.ethereal.email",
        port: 587,
        secure: false,
        auth: {
          user: testAccount.user,
          pass: testAccount.pass,
  }
});

Now you have to define your message which will go to your email, i have given a sample of how to do it, feel free to edit as you like it.

let message = {
   from: '"Fred Foo 👻" <foo@example.com>', // sender address
   to: "bar@example.com", // list of receivers
   subject: "Hello ✔", // Subject line
   text: "Hello world?", // plain text body
   html: "<b>Hello world?</b>",
};

and now the only thing left is to send an email, the transporter is used here, and the full API endpoint will look like below :

app.post('/testingroute', async (req,res) => {

    let testAccount = await nodemailer.createTestAccount();

    const transporter = nodemailer.createTransport({
        host: "smtp.ethereal.email",
        port: 587,
        secure: false,
        auth: {
          user: testAccount.user,
          pass: testAccount.pass,
        }
      });

    let message = {
        from: '"Fred Foo 👻" <foo@example.com>', // sender address
        to: "bar@example.com", // list of receivers
        subject: "Hello ✔", // Subject line
        text: "Hello world?", // plain text body
        html: "<b>Hello world?</b>",
    };

    transporter.sendMail(message).then((info)=> {
        return res.status(201)
        .json({
            message: "you should receive an email!",
            info: info.messageId,
            preview: nodemailer.getTestMessageUrl(info)
        });

    }).catch( error => {
        return res.status(500).json({error});
    })

});

To test this API endpoint, I am using Postman, you can use whatever you want, below is an image for your reference of how to test it using Postman

Now you have to go to the URL you will get in a preview of your API response as in the image above and you will be able to check the mail received in test account as below:

Now that you have seen how nodemailer works and how to test it using a test account, it's time to put our Gmail account and send real emails to users from our Node.js server.

Sending Emails using Gmail

For sending emails using Gmail we have to set up a new route, let's call it signup, here I will use a library called Mailgen to send professional-looking emails, you can install it using the command below:

npm install mailgen

and require it as we did for Nodemailer,

const Mailgen = require('mailgen');

Now set up your new route signup,

app.post('/signup', async(req,res) => {

})

Here you have to define a few things you can send emails, so understand this carefully

let config = {
    service: 'gmail',
    auth : {
        user: '', //please put a gmail id
        pass: '' //please create an app password for gmail id and put here
    }
}

let transporter = nodemailer.createTransport(config);

let MailGenerator = new Mailgen({
    theme: "default",
    product: {
        name: 'Mailgen',
        link: 'https://mailgen.js/'
    }
});

config is where you have to put your Gmail account and password, if you don’t want to put your password, you can go to your Gmail account settings and generate an app password and put it here too. Check out this article to do so https://support.google.com/mail/answer/185833?hl=en

transporter is the same as in testing just that here it uses your gmail server.

and the new thing is MailGenerator, it is a great library to create and send professional-looking emails. You can learn more about it here.

Now you have to create a template response for your email to be sent to the user and give it to MailGenerator and the rest of the part is the same as in the testing route.

let response = {
        body: {
            name : "Daily Tuition",
            intro: "Your bill has arrived!",
            table : {
                data : [
                    {
                        item : "Nodemailer Stack Book",
                        description: "A Backend application",
                        price : "$10.99",
                    }
                ]
            },
            outro: "Looking forward to do more business"
        }
    }

let mail = MailGenerator.generate(response)

let message = {
        from : , // Give your email address
        to : yourmail@gmail.com, // give an email id 
        subject: "Place Order",
        html: mail
}

transporter.sendMail(message).then(() => {
        return res.status(201).json({
            msg: "you should receive an email"
        })
}).catch(error => {
        return res.status(500).json({ error })
})

So everything is done, Now is the time to test your API endpoint as we did with the test account, If you have followed the article carefully your users will receive email as below

Conclusion

In this article, we delved into the world of email communication within the Node.js environment using the powerful Nodemailer library. We embarked on a journey that covered the essentials of setting up Nodemailer, crafting and sending emails, test accounts, and even exploring advanced configuration options with our own Gmail account.

As developers, we understand the significance of effective communication in today’s digital landscape. Leveraging Nodemailer empowers us to seamlessly integrate email capabilities into our applications, enabling us to reach users with essential information, notifications, and personalized content.

Thank you for reading! If you have any feedback or notice any mistakes, please feel free to leave a comment below. I’m always looking to improve my writing and value any suggestions you may have. If you’re interested in working together or have any further questions, please don’t hesitate to reach out to me at fa1319673@gmail.com.

How to Deploy your NextJS App on a VPS

Faizan — Sat, 06 Jul 2024 16:11:07 +0000

Deploying Your Next.js Application on a VPS

Deployment — A crucial part of development that most crash courses and tutorials leave out of their curriculum. It is one of the underrated skills and a must-have to become an all-round developer. Today we are going to see how to deploy a Next.js application on a VPS (Virtual Private Server).

You must be thinking, why not just deploy it on Vercel? It is so simple and seamless. But let me tell you, while Vercel is a well-liked option, you might prefer to test on your own VPS or you might not feel comfortable with a managed hosting company, and the costs on Vercel increase exponentially very quickly.

This article will be a total guide on how to deploy your Next.js application, set up Nginx as a proxy server, connect your domain to the Next.js app, get an SSL certificate using Certbot, and run it using PM2. So let’s get started.

Things to Have Beforehand

Your own VPS
A Next.js application
Basic knowledge of SSH, Node.js, and basic Linux command-line usage
Domain for your application (optional, you can check your app running directly on IP also)

Set Up Your VPS

Connect to VPS using SSH: Replace your-vps-ip with the IP address of your VPS.

ssh root@your-vps-ip

Install Necessary Software

Update and Upgrade: Update the package list and upgrade installed packages to the latest versions.

sudo apt update
sudo apt upgrade -y

Install Node.js and npm: Install Node.js and npm on your VPS.

sudo apt install -y nodejs

Install PM2: PM2 is a process manager for Node.js applications. It keeps your app running and restarts it if it crashes.

sudo npm install -g pm2

Deploy Your Next.js Application

Here are three ways to deploy your application:

Transfer your application files to the VPS using SCP: Use the command below from your local machine’s terminal. Replace the paths as needed.
```
scp -r /path/to/your/nextjs-app root@your-vps-ip:/path/to/destination
```
Clone your application from a GitHub repository: If it is a public repo, clone directly (not recommended). For a private repo, generate SSH keys in your VPS and then copy the public key and put it in the keys section of your GitHub account to allow the VPS to clone your private repo using SSH.
```
git clone <Your repository link>
```

Create a new Next.js app on the VPS:

cd /path/to/your/nextjs-app
npx create-next-app@latest myapp

Now that we have deployed our application, it’s time to set up a reverse proxy Nginx server and connect the domain to our application. Then at last, we will build our app and start it with PM2.

Set Up a Reverse Proxy with Nginx

Install Nginx: Install Nginx, a web server that can act as a reverse proxy.
```
sudo apt install nginx -y
```

Adjust our Firewall: To allow Nginx and traffic on ports 80 and 443.

sudo ufw allow 'Nginx HTTP'
sudo ufw allow 'Nginx HTTPS'
sudo ufw enable
sudo ufw status

The status should show something like below:

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Nginx HTTP                 ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Nginx HTTP (v6)            ALLOW       Anywhere (v6)

Check if Nginx has started:
```
systemctl status nginx
```
Verify by going to the IP of your VPS http://your_vps_ip_address on a browser; it should show the default Nginx page.

Create Nginx Config: Create an Nginx configuration file to forward web traffic to your Next.js application.

sudo nano /etc/nginx/sites-available/nextjs-app.conf

Paste the below configuration and replace your-domain.com with your domain.

server {
  listen 80;
  server_name your-domain.com;

  location / {
    proxy_pass http://localhost:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
  }
}

Now delete the default config file:

sudo rm /etc/nginx/sites-enabled/default

Enable our configuration by creating a symbolic link and restarting Nginx:

sudo ln -s /etc/nginx/sites-available/nextjs-app.conf /etc/nginx/sites-enabled/
sudo systemctl restart nginx

Secure Your Application with SSL

Install Certbot with Snapd:

Install Snapd:

sudo apt install snapd

Ensure you have the latest Snapd version installed:

sudo snap install core; sudo snap refresh core

Install Certbot with Snapd:

sudo snap install --classic certbot

Create a symlink to ensure Certbot runs:

sudo ln -s /snap/bin/certbot /usr/bin/certbot

Obtain SSL Certificate with Certbot:

sudo certbot --nginx -d your_domain_name.com -d www.your_domain_name.com

Build Your Application and Start with PM2

Now that we have our app on the VPS, the domain connected with it, and SSL to secure it, it's finally time to build our Next.js app and get it running.

Go to your app and run the build command:

cd /path/to/your/nextjs-app
npm run build

Start the application using PM2:

sudo pm2 start npm --name "myapp" -- start

Save the PM2 process and set up PM2 to start on boot:
```
sudo pm2 save
sudo pm2 startup
```
Now go to your domain, and you will see your Next.js app running:
```
https://your-domain.com
```

Conclusion

Deploying your Next.js application on a VPS might seem challenging at first, but by following these steps, you can set up your server, install the necessary software, transfer your application, and secure it with HTTPS. This process gives you more control over your application and can lead to better performance and cost savings. Happy deploying!

Reference

Deploy NextJS App on VPS

DEV Community: Faizan

MCP: The Simple Protocol to Make AI Actually Useful

So, What is MCP?

MCP aims to be the USB for AI.

How It Works (The Simple Version)

Why Should You Care?

Is This the Future?

What is Secure Coding?

Common Security Threats

SQL Injection

Cross-site Scripting (XSS)

Cross-Site Request Forgery (CSRF)

Remote Code Execution (RCE)

Principles of Secure Coding

Security by Design

Least Privilege Principle

Defense in Depth

Best Practices for Secure Coding

Input Validation and Sanitization

Techniques and Tools

Authentication and Authorization

Error Handling and Logging

Data Encryption

Dependency Management

Conclusion

GitHub Actions Explained

What You Need to Know About GitHub Actions

Automate Workflows

Customizable and Integrative

Community and Affordability

Getting Started

Building Your First Workflow

Setting Up the Environment

Creating a Basic YAML File

Testing the Workflow

Detailed Breakdown of Components

Workflows, Jobs, and Steps

Events and Triggers

Actions and Runners

Advanced Techniques

Integrating with Third-Party Tools

Managing Workflow Secrets

Scaling with Self-Hosted Runners

Conclusion

FAQs

5 Common Myths About Artificial Intelligence

Myth 1: AI Will Take Over the World

Myth 2: AI Will Take All of Our Jobs

Myth 3: AI Is Sentient or Conscious

Myth 4: AI Is a Threat to Humanity

Myth 5: AI Is Magic

The Future of AI: Separating Fact from Fiction

Sending Emails in Node.js Using Nodemailer

Set up your Express.js Server

Installing and Using Nodemailer

Testing with a Test Account

Sending Emails using Gmail

Conclusion

How to Deploy your NextJS App on a VPS

Deploying Your Next.js Application on a VPS

Things to Have Beforehand

Set Up Your VPS

Deploy Your Next.js Application

Set Up a Reverse Proxy with Nginx

Secure Your Application with SSL

Build Your Application and Start with PM2

Conclusion

Reference

Epilogue