DEV Community: Khushal Bhardwaj

doing github-actions local-first!

Khushal Bhardwaj — Sat, 11 Jan 2025 15:28:42 +0000

Hey there! Let’s talk about something that’s been a game changer for me: act. It basically lets you run your GitHub Actions on your machine without a whole lot of configuration—none for me!

So if you're too excited to check this out on your own, check out act here.

OR if you want a personalized tutorial on how I went about it, there you go...

I wanted this for a loooong time. If you’re like me, you’ve probably spent way too much time pushing commits with names like “testing action 1” to “testing action 1001” because I can't get these configs right the first time. 😭 It’s a drag, right?

Why Use `act`?

act lets you run your GitHub Actions locally using Docker. This means you can test your workflows without waiting for them to run on GitHub. It’s a huge time-saver and a life-saver if you're writing complex workflows!

Getting Started

Install it however you like; follow the instructions here. I installed it using GitHub CLI (don't hate me for using it).

gh extension install https://github.com/nektos/gh-act

Create your workflow in the .github/workflows directory, however you want it.
Run act to execute every action, or you can do something specific like act push to run all the actions triggered by a push. You can do a lot more.
If you installed it using GitHub CLI like me, just do gh act ....

NOW HERE'S a problem I faced on my machine: if you don't get this, you're done!

If Docker on your machine needs sudo access (like mine does), you might hit a snag. When you try to run gh act, it won’t have access to Docker. So, what do you do?

The Simple Hack

Here’s a quick fix: use sudo -E to run commands while keeping your user context. This way, you can run gh act with Docker access without any hassle.

Run Your Workflow: Use this command:

   sudo -E gh act push

The first run might take a bit since it downloads everything (images), but after that, it’s smooth sailing. No more endless commits just to test your actions!

So there you have it! With act, you can save time and avoid the hassle of pushing multiple commits just to test your actions. If you want to learn more, check out the official documentation for act here.

Winston Transports??

Khushal Bhardwaj — Sun, 21 May 2023 19:09:05 +0000

Brief Introduction to what is `winston`?

Winston is a node package that provides a simple and universal logging library. It supports multiple transports, such as file, console, and syslog. Winston is easy to use and can be customized to meet your specific needs.

Did you see the words multiple transports and customized in the above definition of winston (that I asked Google Bard to write)? Yeah, winston is probable the most sophisticated and customizable logger out there.

What are transports?

So we know that winston supports multiple transports, but what is a transport anyway?

In winston, transport is essentially a storage device for your logs. Each instance of a winston logger can have multiple transports configured at different levels.

So transport is basically like where you want to store your logs.

There are some most basic ones like:

The Console

import winston from "winston"

export const logger = winston.createLogger(
    { 
        transports: [
            new winston.transports.Console()
        ],
    }
)

Files

...
new winston.transports.File({ filename: "logs/all.log" })
...

Console and file are like the most basic ones, Console basically prints your logs to the console and file one just stores your log in the defined file. You can go crazy with the options and do a lot more stuff, like storing logs of only a specific level, let’s say error or something.

The default ones are great, and they make for the most basic use cases, but if you’re going into production and logs are just more than something you’ll use to debug and get HTTP status codes.

There are a lot of platforms that allows you to store your logs and do crazy things with them (basically alerts and analytics). Some of them are Logtail, and an open source one is Highstorm.

To upload your logs to them, you’ll need custom transport. winston give you the power to create custom transports pretty easily with the winston-transport package, and here’s how you do it…

Custom Transports

So basically custom transports are to upload your logs to some sort of storage or maybe do something else with it, like creating alerts and stuff.

Here’s how you create basic custom transport for winston:

// my-transport.ts

import Transport, { TransportStreamOptions } 'winston-transport';
import type { LogEntry } from "winston";

export class MyTransport extends Transport {
  constructor(
    opts: TransportStreamOptions
  ) {
    super(opts);

        /*
            * Consume any custom options here. e.h:
                * Connection information for databases
                * Authentication information for APIs
        */
  }

    // this functions run when something is logged so here's where you can add you custom logic to do stuff when something is logged.
  log(info: LogEntry, callback: any) {
        // make sure you installed `@types/node` or this will give a typerror
    // this is the basic default behavior don't forget to add this.
        setImmediate(() => {
      this.emit("logged", info);
    });

    const { level, message, ...meta } = info;

    // here you can add your custom logic, e.g. ingest data into database etc.

        // don't forget this one
        callback();
  }
}

Now you can add your custom transport very easily as:

// logger.ts

import {MyTransport} from "./my-transport.ts"

const options = {
    // custom transport options
}

const myTransport = new MyTransport(options)

export const logger = winston.createLogger({
    ...
    transports: [
        ...
        mytransport,
        ...
    ]
});

Pretty easy to write, yup, thanks to winston being the best logger out there with this level of customization. With the above example, you can create any custom transport you want with whatever fancy logic you want.

Check out these to dive deeper:

npm: winston-transport

npm: winston

Here are some packages that provide transports to do various things (mostly upload to their service):

npm: @logtail/winston

npm: winston-transport-sentry-node

npm: winston-kafka-transport

npm: @shelf/winston-datadog-logs-transport

Functions in Memory (Stack)

Khushal Bhardwaj — Mon, 19 Sep 2022 17:11:54 +0000

Checkout my twitter thread explaining how functions work in memory (stack).

// Detect dark theme var iframe = document.getElementById('tweet-1571901815616344065-782'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1571901815616344065&theme=dark" }

Things to keep in mind to understand functions behavior

When a function is called, it gets in the stack, and stays there until its execution.
When the function completes executions, it gets off the stack and returns to the program flow.

Here's a program with a main function that call some other functions and that function call some other function. As they get called, they are loaded into the memory stack.

When the function, completes execution the functions gets off the stack and the program returns to the previous program flow, aka to the previous function that called that function.

When there is nothing left in the stack, even the main function that is loaded by default, gets off the stack, the program finishes execution.

Takeaways

When the function is called, it is loaded on the stack with its arguments.
When it completes execution, it gets off the stack and the program returns to its previous program flow.

If "A" function calls "B" function, "A" function will remain in the stack (and in scope also) until the "B" function returns. It means that not only the currently executing function remains in the function but also all the parent function that called it.

Italic Fonts

Khushal Bhardwaj — Wed, 07 Sep 2022 09:00:05 +0000

Making fonts italic in your code editor or your terminal can be hard since there’s not such default visual settings that you can just turn on like to make the fonts bold (only some of them have it). But italic fonts look great and really cool if you have a font that support font ligatures.

Terminals

Here are some setting to add in your terminal settings to make the fonts go italic.

Windows Terminal

Open the JSON settings from the settings tab in the terminal

And add the following settings into that JSON file



"profiles": {
  "list": [
    {
      "font": {
        "face": "VictorMono NF",
        "weight": "bold",
        "axes": {
            "ital": 1 // this is what does the magic
        }
      },
    },
    ...
  ]
}

Gnome-Terminal

Gnome-Terminal is the default terminal app on most of the Linux distributions, to use italic fonts there’s no additional configuration required, you just need to choose the italic font style from your terminal preferences.

To do that, go to preferences > profile > text > font.

One thing to note is that you should download the whole font family of the font that you want and then choose the italic font. The italic font style won’t show up if you don’t download the whole font family. So it’s better to download them all.

VS Code

To make fonts italic in VSCode irrespective of your theme, put the following settings into your settings.json



"editor.tokenColorCustomizations": {
    "textMateRules": [
      {
        "scope": [
          "comment",
          "entity.name.type.class", // class names
          "keyword", // import, export, return
          "constant", // String, Number, Boolean..., this, super
          "storage.modifier", // static keyword
          "storage.type.class.js" // class keyword
        ],
        "settings": {
          "fontStyle": "italic bold" // comments are italic
        }
      },
      {
        "scope": [
          "invalid",
          "keyword.operator",
          "constant.numeric.css",
          "keyword.other.unit.px.css",
          "constant.numeric.decimal.js",
          "constant.numeric.json"
        ],
        "settings": {
          // following will be excluded from italics (VSCode has some defaults for italics)
          "fontStyle": "bold"
        }
      }
    ]
  },

The above settings does make the following things italic

class names
keywords
constants
memory modifiers and class keyword

Also, it exempts the custom italic style to certain things that VS Code has default italic config for.

Example Code with Italic Fonts

Credits

REST with Rust

Khushal Bhardwaj — Mon, 05 Sep 2022 06:54:47 +0000

This was originally published here.

Calling REST APIs with rust may seem like a daunting task at first because of the steep and long learning curve of rust as a programming language.

We know that contacting with REST APIs is something that we come across creating almost any other app that comes to mind.

We’ll make use of the reqwest library to make our request that is essentially a higher level implementation of the default HTTP client.

# Cargo.toml
reqwest = { version = "0.11", features = ["json"] }
tokio = { version = "1", features = ["full"] }
dotenv = "0.15.0" # optional
serde = {version = "1.0.144", features = ["derive"]}

We import the following libraries to make this work

Library	Purpose
reqwest	to make our requests
tokio	to make async requests and other async stuff.
serde	to deserialize the json response into a rust struct

Making Basic GET Requests

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let resp = reqwest::get("<url>").await?;
    let resp_json = resp.json::<HashMap<String, String>>().await?;

    println!("{:#?}", resp_json);

    Ok(());
}

Here we do the following key things:

We add the tokio::main attribute to our main function to use await within our function.
We change the return type of the main function from unit type - () to a Result<(), Box<dyn std::error::Error>> to catch errors from the request if any.
Then we make the request using the get function and await on that, and also we use the turbofish operator to only get the return type of the future
- More info on why we are using this operator, here.
Then we deserialize the JSON response to a HashMap<String, String> for convenience and await on that.

Adding headers to our request

To add headers to our request, we first make a request client and use that to add headers to our application.

use reqwest::header::HeaderMap;

#[tokio::main]
async fn main() {
    ...
    let client = reqwest::Client::new();
    let mut headers = HeaderMap::new();
    headers.insert("content-type", "application/json".parse().unwrap());

use reqwest::header::HeaderMap;

#[tokio::main]
async fn main() {
    ...
    let client = reqwest::Client::new();
    let mut headers = HeaderMap::new();
    headers.insert("content-type", "application/json".parse().unwrap());
    headers.insert("Authorization", format!("Bearer {}", API_TOKEN).parse().unwrap());

    let resp = client.get("<url>")
                                .headers(headers)
                                .send()
                                .await?;

    ...
}

Here’s what we did above:

We create a request client to send our request.
We create a mutable instance of the HeaderMap Instance that is similar to HashMap
We insert our headers as key-value pairs to the header.
- We use .parse().unwrap() on the &str to convert the string type to the header value type.
We then add our headers to the client request by using the .headers() method.
Also, one thing different from directly using the get method is that we have to call the send method on our request before awaiting on it.

Sending post request with JSON body

We send the post request by using the post method on the request client or directly from the library and use the json method to add body to the post request.

The body here is just a HashMap in rust.

...
let mut body = HashMap::new();
body.insert("username", "myusername");
let resp = client.post("<url>")
    .json(&body)
    .send()
    .await?;
...

Deserializing the JSON response

We can deserialize the JSON response from the API by using the json method on the sent request, and get that into our preferred shape or type by calling it generically with that type.

One thing to note is that the type must implement the Deserialize trait.

First thing first we create the type we want our JSON response in and implement the deserialize trait on it, implementing the trait ourselves is tedious and unreliable, so we use the serde library that we imported before do that for us.

use serde::Deserialize;

// deriving the Debug trait also to be able to print it
#[derive(Debug, Deserialize)]
struct APIResponse {
    message: String;
    error: String;
}

We can then use the above struct to deserialize our response as:

...
let resp_json = resp.json::<APIResponse>().await?;
...

References

Should I adopt Service Oriented Architecture (SOA)?

Khushal Bhardwaj — Thu, 01 Sep 2022 13:37:25 +0000

This article was originally published here.

The main principle of Service-Oriented Architecture is to segregate the concerns to move the business logic and the vulnerable data layer off to the API routes directly. In this, we isolate different parts of the logic in such a way that makes sense.

In this three layer or tier system we usually divide the logic of a route or a function of the application into Controller, Service, and Data Access Layer.

Controller (Routes)

Its purpose is to deal with requests from the user to the application and deal with the different routes that have different functions. It also modifies the incoming data from the user to be able to consume it within our business logic.

It's also responsible to return the processed or requested data to the user in a suitable format. Generally, the routing mechanism controls which request hits which controller.

It's tempting to put the business logic inside the controllers but is advised not to, since as your application grows it will quickly become overwhelming and the spaghetti code inside the controller might just overshadow the real purpose of the controllers and create our application vulnerable and lot less maintainable.

Services ~ The Logic

This is where the actual logic of the application resides, it contains our CRUD operations, validations, authentication and authorization of users and data. This is the business logic layer where the data from the user is processed that the service gets from the controller and the data access layer is summoned the return data to the user.

A major advantage of splitting our business logic like this is that our codebase becomes a lot more maintainable, and we write clean code and tend to make a lot less make mistakes.

The service layer is the actual heart or core of our application it contains all the magic of the application, for example the application generates invoices from the user’s data, this is where the invoice will be generated, and the data will be persisted, and a response will be sent to the user via the controller.

Data Access Layer

It's the layer where the logic related to our data persisted in some sort of database is modified, read, and deleted. It doesn’t really have a rigid structure like the other two. And what I mean by structure is that the controllers and the services are put into different files, but this is actually some sort of ORM like prisma or mongoose which **can talk to the persisted data.

Why use it?

The most common question in your mind would be that why should I use this, and not put all the logic inside a single function or layer so to say. I know that I have persisted that it makes the codebase more manageable, but that isn’t such a solid reason to do so, for like small projects with less logic and fewer routes.

To convince you into using this approach, here are some advantages to this 3-tier-architecture:

Scalability

It makes our application much lighter and that’s what makes it much more scalable.
Easy Integration

When you are creating an application, it is probably using some sort of third-party library or is talking to some other application to send a response to the user. This service-based architecture which promotes segregation of logic is great at it.
Security

This approach to the problem is best because it validates the data over and over again and reduces the probability of some malicious data entering our application, since data is modified and validated at every layer checkpoint, so without any extra effort it gives you the security edge.
Testing

It also makes it much easier to test the application, since the logic is isolated to services and controllers can be checked easily, which results in easy testing experience and fewer bugs in your application.
Reusable Code

Developers are often pressed by the fact that they should write DRY (don’t repeat yourself) code, this service-based architecture is perfect for code reusability, for example a service can be used in multiple controllers or other services with methods like dependency injection, etc.

Is it that good?

The Service-Oriented Architecture is not the best fit for all sorts of use cases, in some cases it might be a disaster to adopt this.

One of the major disadvantages of it is its high overhead, and high starting cost.

High Overhead

This architecture has a high overhead within the application, and not only it may suck in memory but also in developer experience as there’s a lot of boilerplate code required to make this work.
High Investment

This architecture demands high investment of money and time from the start. It demands different developer roles for each layer and also required a lot of development time.

Should I adopt it?

The big question is, should I actually adopt this highly boilerplate rich, secure and complex architecture? This question can’t be answered with just this. You have to make this decision yourself based on your requirements, project size, budget and time.

If you’re creating a minuscule application that just have few routes and some logic, you shouldn’t adopt this, since it will become a pain to maintain it for such tiny project.

But, If you wish to create a highly complex large project with a lots or routes and tons of logic, it may be a good fit for you.

Either way, you’ve to decide this yourself. There are some really nice frameworks out there that make starting with it much easier, like NestJS and Spring Boot for APIs and Backend Stuff and AngularJS for Client Side.

what made me a developer?

Khushal Bhardwaj — Thu, 18 Aug 2022 16:31:12 +0000

Disclaimer: I'm directly writing it in the editor, so wear your seatbelts before starting, 'cuz I don't know where we'll land.

TLDR; Here are some things that you can learn from my journey, 'cuz I know I'm bad at talking:

Learn in public, start out on Twitter or any other community.
Don't start with YouTube, start with something more structured.
Don't hesitate to ask and reach out to people when in a problem.
Follow me on Twitter (couldn't resist that)

I've imagined myself so many times (I'm not weird you also have done so 😒) getting interviewed, so this should be a smooth ride.

My first introduction to computer was at my uncle's house, played games, and then at my cousin's house, played more games and then at our own house when my mom and dad suddenly got me one, GTA is rad.

The above was me shitting or probably boasting my game and GTA skills (you better not get ahead yourself), the real journey to computers start when I got bored with games and obviously didn't want to study, so I started playing with the good old Windows XP "professional", crashed it couple of times set a cursive font as the system font (probably the worst decision of my life 😥).

I first coded HTML on a much older PC than myself, I know I said "coded", this doesn't make any sense, right? It sure does to a boy who only played GTA with some cheat codes 🥴.

BTW, GTA cheat codes is the best piece of code... period.

Then after that short first date with programming it obviously didn't work out, fast-forward 2-3 years and here I am sitting in quarantine ready to learn code.

I started with YouTube and stayed at YouTube for like one and a half year, learned some cool python and hated JavaScript at first, but there isn't any choice but to love it at the end, obviously those skills looked like shit because of imposter syndrome.

So the first actual learning you can take away with you after reading the above sh*T, is that Never Ever start programming with YouTube**.

The reason I say this not because the YouTube people aren't good or the content they make is, they are great, and it's not just I'm saying it they actually are that's what makes it harder for a beginner. When you see someone so good at programming when you aren't even able to do hello world, it feels like shit. We just forget that they actually prepare a lot of that beforehand and have many takes making that project or anything.

Also, you can fall into Tutorial Hell, it's terrible and do really exist. I thought I knew what it was and that I'm not falling for it, but I did anyway because that's actually so tempting.

It's better to start out with something more structured and reliable solution than YouTube like freeCodeCamp or any other website that you find helpful. Also, it's really helpful if you start learning in public, the community that may look overwhelming at first is really, really helpful and supportive, you can't believe how many people are ready to help you out or stop you if you're doing something wrong.

And that doesn't mean you should never or can't learn anything from it, you can but be patient, I watch a lot of tech YouTube, but now it's okay because I know what I'm doing.

After I got out of that imposter syndrome and forced myself to recreate the projects without looking at them, going through docs and tech forum, I was finally able to get out of it for good.

Shortly after that, I created a whole CMS for a local business in Django and then remodeled it again with NextJS x tRPC and Prisma. And now I'm doing another project with them where I'll create them a static landing page and a blogging platform.

So the second thing you should keep in mind, after you get your basics done don't think that I'm not ready yet aka imposter syndrome, you're always ready be confident in yourself and just try out.

I said it I didn't know where we'll land, here I am ranting about my tech journey. So glad that you read it this far.

I'm always open to connect and collaborate, just reach out. 😜

The type-safe guide to tRPC

Khushal Bhardwaj — Thu, 28 Jul 2022 16:12:00 +0000

This isn't the best guide to use tRPC, probably there are better ways to do this, like create-t3-app, the best I could find.

Most of what is here is from the tRPC's documentation, you can refer them, super helpful and easy to read.

What is tRPC?
tRPC is a typescript library, so to say, that makes it easy to create type-safe APIs without schema or any sort of code generation.

Where to use?
Create the typed server and then import its type and use it with an adaptor in the client side.

How does it implement type-safety?
tRPC encourages using the zod, a library for type validation of input and output arguments.

Is tRPC only limited to React?
tRPC's core API is built to work with any client, but right now it supports React and can be used with React Meta Frameworks like NextJS or SolidJS, since it uses React Query under the hood to talk to the server and maintaining type-safety across the data-pipeline or data-flow.

For now, it has first-party adaptors for React, NextJS, Express, Fastify, SolidJS, and some community packages like for tRPC for SveleteKit

What are its features?

Lightweight, a tiny bundle size for such a powerful library.
Type-safe to the max!
Support subscriptions with websockets library.
Request batching
- Request can be made simultaneously and then are batched into one.
Strong User base and helpful Community

tRPC x NextJS

Recommended file structure:

.
├── prisma # <-- if prisma is added
│   └── [..]
├── src
│   ├── pages
│   │   ├── _app.tsx # <-- add `withTRPC()`-HOC here
│   │   ├── api
│   │   │   └── trpc
│   │   │       └── [trpc].ts # <-- tRPC HTTP handler
│   │   └── [..]
│   ├── server # <-- can be named backend or anything else
│   │   ├── routers
│   │   │   ├── app.ts   # <-- main app router
│   │   │   ├── post.ts  # <-- sub routers
│   │   │   └── [..]
│   │   ├── context.ts      # <-- create app context
│   │   └── createRouter.ts # <-- router helper
│   └── utils
│       └── trpc.ts  # <-- your typesafe tRPC hooks
└── [..]

Components

Router

This is the router where the actual business logic will reside, create a backend folder inside the src directory and put all this stuff there.

If using prisma otherwise this is optional,
src/server/utils/prisma.ts

import { PrismaClient } from "@prisma/client";

declare global {
    var prisma: PrismaClient | undefined;
};

export const prisma = global.prisma || new PrismaClient({
    log: ["query"]
});

if (process.env.NODE_ENV != 'production') global.prisma = prisma;

src/server/router/context.ts

import * as trpc from "@trpc/server";
import * as trpcNext from "@trpc/server/adapters/next";
import { prisma } from "@/server/utils/prisma"; // this is optional

export const createContext = async (
    options?: trpcNext.CreateNextContextOptions
) => {
    const req = options?.req;
    const res = options?.res;

    return {
        req,
        res,
        prisma, // this is optional
    };
};

type Context = trpc.inferAsyncReturnType<typeof createContext>;

export const createRouter = () => trpc.router<Context>();

Using Contexts

We can create router without using the above context by just using trpc.router() that will work just fine. But if you are using some external API like in the above case we are using prisma, it's better to use pass in repeatedly used instances to context to avoid having multiple ones for every query we use that in, that may affect our performance and can also be vulnerable.

src/server/router/index.ts

import {createRouter} from "./contex";
import {exampleRouter} from "./example.router";

export const appRouter = createRouter()
    .merge("example.", exampleRouter)
    .query("posts.count", {
        async resolve({ctx}) {
            return await ctx.prisma.patient.count();
        }
    });

export type AppRouter = typeof appRouter;

API handler aka NextJS adaptor:

The exact filename is necessary to make this work!

src/pages/api/trpc/[trpc].ts

import * as trpcNext from "@trpc/server/adapters/next";
import { appRouter, AppRouter } from "@/backend/router";
import { inferProcedureOutput } from "@trpc/server";
import { createContext } from "@/backend/router/context";

// export API handler
export default trpcNext.createNextApiHandler({
  router: appRouter,
  createContext: createContext,
});

Hooks
These are the React hooks necessary to maintain the type-safety, this will give you React Query like hooks to fetch the API.

src/utils/trpc.ts

import { createReactQueryHooks } from "@trpc/react";
import type { AppRouter } from "@/backend/router";
import { inferProcedureOutput } from "@trpc/server";

export const trpc = createReactQueryHooks<AppRouter>();

export type TQuery = keyof AppRouter["_def"]["queries"];

// helper type to infer query output
export type InferQueryOutput<TRouteKey extends TQuery> = inferProcedureOutput<
  AppRouter["_def"]["queries"][TRouteKey]
>;

Example query in React Component
Now that tRPC is set up, this is how we use it inside react components.

src/pages/index.tsx

// we use the instance we created that has our router type definitions
import { trpc } from "@/utils/trpc";

export default SomePage() {
    const { isLoading, data:postsCount } = trpc.useQuery(["posts.count"]);
    return <div>...</div>
}

SSG Helpers

SSG Helpers are helper functions that can be used to pre-fetch queries on the server upon request to reduce loading time.

They are to be used when working with SSR and SSG or ISR.

How to use it with getServideSideProps function of NextJS pages.

// /pages/posts/[id].tsx
export function getServerSideProps(
    context: GetServerSidePropsContext<{id: string}>
) {
    const { id } = context.params;

    const ssg = createSSGHelpers({
        router: appRouter,
        ctx: await createContext(), // { } if no context in your router
        transformer: superjson
    });

    ssg.fetchQuery("posts.get", {id});

    return {
        props: {
            trpcState: ssg.dehydrate(),
            id
        }
    }
}

export default function PostPage(props: InferGetServerSidePropsType<typeof getServerSideProps>) {
    const {id} = props;

    // this query will be fetched instantly because of the cached
    // response of the query we fetching on server
    const {isLoading, data} = trpc.useQuery(["posts.get"], {id})

    return ...
}

References

Check out this amazing talk by Theo on tRPC vs GraphQL and their risks.
Check out Theo on YouTube or any other social media platform, he has a lot of content about tRPC
Follow Alex aka Katt, the creator of tRPC.

Spinning up MySQL Database with Docker

Khushal Bhardwaj — Thu, 21 Jul 2022 20:08:00 +0000

This article was originally published on my blog, visit it here.

This is the best way to start since you don't have to install MySQL locally and configure it and run into like thousands of issues and in the end not being able to make it, docker makes it much easier for me or probably for you also to spin up a MySQL database in minutes.

To get started, follow these steps:

Pull the latest image,

docker pull mysql:latest

You don't have to do it manually, it will download automatically if not installed when we spin up the container.

Start the container using the following command

docker run --name <container_name> -p 3306:3306 -v mysql_volume:/var/lib/mysql/ -d -e "MYSQL_ROOT_PASSWORD=<root_password>" mysql

This will create a new container with the name , with the mysql:latest image, and publish the ports 3306 to the local environment to use the instance outside the container.

This also sets up the volume for the container to persist the database's data, so that it doesn't reset on restarts of the host system or the container.

We also pass in the environment variable MYSQL_ROOT_PASSWORD to set a root password for the database.

If not provided, it will generate a random strong password, we can see it in the container logs using this command:

docker container logs <container_name>

You can pass in the following Environment Variables when starting the container:

MYSQL_ROOT_PASSWORD: Set up your password using this environment variable.
MYSQL_ALLOW_EMPTY_PASSWORD: Blank or Null password will be set. You have to set MYSQL_ALLOW_EMPTY_PASSWORD=1.
MYSQL_RANDOM_ROOT_PASSWORD: a random password will be generated when the container is started. You have to set MYSQL_RANDOM_ROOT_PASSWORD=1 to generate the random password.

Don't pass in the permanent password in production, as the password will be visible in the shell history, which we obviously don't want.
A possible solution is that we pass in a temporary password like temp123 and then change it afterwards.

We can change the root password as follows:

Get into the container using

docker exec -it <container_name> bash`.

mysql -u root -p

This will prompt you to enter the password which we set up before, in our case it was temp123.

After logging into the shell, run the following SQL query to change the password

ALTER USER 'root'@'localhost' IDENTIFIED BY '<new_password>';

References:

View this article on Instapaper with notes.
View the original one here.