DEV Community: ujwal dhakal

Application Resilience: 4 Ways to Build It

ujwal dhakal — Tue, 22 Nov 2022 13:01:02 +0000

Do you ever wonder if you could keep your application from ? experiencing any failures or downtime at all?

The response is "No." You can't stop every single failure and downtime that could ever occur to an application.

You can improve a few areas to develop a robust system and mindset, so don't worry.

Systems that recover fast after failure are considered resilient systems. Quick failure recovery does not always imply that if something goes wrong, it will be fixed in a short period of time. If the items could be recovered immediately, they would be recovered. If not, a simple procedure to fix the situation would need to be developed.

How to build a resilient system

There are multiple ways to build a resilient system but in this system, we will discuss 4 points only.

1) Auto healing -

There should be some means of detecting downtime if your program or a particular component goes down. After a set amount of time, the program should be able to either continue the task from where it stopped off.

Let's talk about the ways to introduce auto-healing

Retry -: You should, if at all possible, have manual or automatic techniques to attempt again things that, for a variety of reasons, were not successful the first time. You can have a few possible retries, for instance, if you are running an eCommerce site and a consumer wants to pay using PayPal but PayPal is down.
Proper UX: In some circumstances, you can additionally plan the user experience (UX) of the application so that the end user is aware of any unfinished business. so that you can try again with less effort. For instance, anytime you post a video to Facebook, it will let you know after a short while whether the upload was successful or unsuccessful.

2) Monitoring -:

You may track the behavior of your application over time by using monitoring. When I use the word "behaving," I mean everything that is necessary for a business to function properly, including major errors, resource consumption, feature utilization, revenue numbers, and cost numbers.

Logs: If handled properly, logs can be a highly important source of information. They serve as proof that a certain event occurred. For instance, you keep track of every time a consumer tries to pay and when they are unable to pay at a specific time. It can be used to determine
Metrics: Metrics are a method for quantifying anything. Anything that is significant to you can be measured. For instance, the total number of 4xx status codes, the total number of registered users, the total number of users who were unable to make a payment using PayPal, etc.
Alerting: Even if you have solid metrics and logs, what if you always need to check to see if something is working or not as expected? The alerting method involves informing you if there is a problem with the expectation you've set. You can set up logs for anytime someone is unable to pay using PayPal so that you are notified through email, Slack, or SMS that the payment has failed for a specific user.

3) Testing

Testing is a method of determining what would occur if you either gave specific data to a specific function or clicked certain before or after the page loaded if a third-party service went down, etc. It involves confirming your hypotheses regarding specific features, techniques, scenarios, and so forth.

Your application can be used or abused in a variety of ways, therefore by validating your assumptions, you are already protecting yourself. It enables you to make wiser decisions on what to do next. Writing units, integration, and, if applicable, end-to-end tests are a few examples.

4) Incident Retros

Failures and other potential negative outcomes are unavoidable, as we've already stated. Even when anything goes wrong, there should always be a discussion or report regarding what, when, and how it happened.

On incident retros make sure to not blame anyone because the things happen not because of the person but because of not having the right process in the first place. After getting insights into how things happened. Try to come to a conclusion on setting up a process to over this kind of uncertainty for next time. For e.g User A was not able to pay because the payment service was down at that time could be a talk. Setting up a retry first on the first failure if payment still fails notify users that their action has failed. Create a simple way for users to retry the payment themselves.

Conclusion

Always remember that failure is inevitable; in light of this, attempt to think of three questions. What would happen, how would it affect us, and how could we handle this if something or some part broke down? With this attitude, you'll start displaying resilience in some way in your work. Building a robust system takes time and work, and the key is to start small and keep going.

How to use Protobuf with Go?

ujwal dhakal — Wed, 06 Apr 2022 19:08:47 +0000

How to use Protobuf with Go?

Have you ever been in a situation where you do not know the structure of data that services are either consuming or publishing?

Did you know that you have to write a schema only once which defines the structure data and the same schema can be used as validation before sending & receiving data using Protocol Buffers?

In this tutorial, you will learn about using Protobuf. You will send & receive a message asynchronously using Protobuf with RabbitMQ.

Prerequisites
Protobuf
Bootstrapping Project
Creating Protobuf Messages
Publishing a Message
Consuming a Message
Conclusion

Prerequisites

This tutorial will be a hands-on demonstration. If you’d like to follow along, be sure you have the following:

You have running Docker Composer in your machine.
You have a basic understanding of Docker, GO, Rabbitmq.

Protobuf

Protobufs are the Messaging Contracts. They are schema that describes the structure of the message. These files are written in .proto extension which is language-neutral i.e write once & use anywhere. Proto Messages are the structured schema that is inside .protofiles

You will write Proto Messages and with the compiler called Proto Compiler, you can generate the code which will have a way to serialize & deserialize data into that format.

There are many benefits of using Messaging Contracts like Protobuf :

With these Proto Messages, you will know what type of data you are sending & receiving
Serves as a documentation
Supports validation for serializing & deserializing
Proto messages are language-neutral and it supports various programming languages which means you can publish messages from Go & start consuming them from Php / Node etc

Bootstrapping Project

For creating a new test project follow the steps below:

Copy Dockerfile & docker-compose.yaml from this repository which will dockerized Go source code, Proto compiler & RabbitMQ
Create a file publish.go where you will write some code to publish events
Create a file consume.go where you will write some code to consume events

Creating Protobuf Messages

In an application, while you sending messages you will serialize data using the definition from Proto Messages. And when consuming messages you will deserialize them using the same Proto Messages. Let's create a Proto Message so your services can use them to send and receive messages.

Create a folder messages and inside that folder create a file called user_registered.go
Inside user_registered.go copy the following codes. Let's understand the code

syntax defines which proto version you are going to use
go_package defines the path where all your generated Protobuf code will be into
`import “validate/validate.proto”; it is importing the validator so that you can validate message using various rules without writing it by yourself
All message starts with a message keyword followed by name of the message. Inside the block, you can write key-value pairs where the key defines name & type & the value defines its order & rules if there are any. In our case, you are defining the first field userId which is an integer and should be greater than 0 and the next is an email which is a string and should not be empty.

\3. Run make build-proto on your project root. This command will generate two files user_registered.pb.go and user_registered.pb.validate.go that define type & includes all the validation logic that you specified on the text which you can later use on your code while serializing & deserializing.

Publishing a Message

As you have successfully created a Proto Message. Let's use the same auto-generated code while sending messages to other services for this you need to write a way to publish messages. Follow the following steps:

Create a directory pkg and a file rabbitmq.go inside pkg dir where you will make a connection with RabbitMQ. The following code the function getConnection is importing library and making a connection with RabbitMQ server and upon error function failOnError is terminating the application with an error.

\2. After successfully making a connection, write a function that will publish a message to RabbitMQ. The following code accepts queueName and payload as a message which will write a message to default exchange to JSON format.

\3. Create publish.go which will import publish function from rabbitmq.go to send data. The following code is using a struct that was generated by the proto using the proto compiler and it is encoding them into JSON after that it is calling to publish the function that you created earlier to send data to UserRegisteredqueue.

Try running make publish to verify that your code is actually working if you see Data has been published the output that means you were successful in publishing a message.

Consuming a Message

Until now you defined a photo message then you created a rabbitmq.goto create a way to publish messages & you used the same function publish.go to publish messages to RabbitMq. Now let's consume the message that you published earlier.

Inside rabbit. go add a function that will help in consuming a message. The following code makes a connection to RabbitMq & returns a channel that you can leverage to listen to incoming messages.

\2. Inside consume.go listen to all the messages and then print them. Let's understand the following code :

The main function is listening to message by creating a consuming client. While deserializing message it is importing UserRegistered struct from the auto-generated code to define the type of data. There might be cases where the producer might send invalid data due to various reasons so it is better to validate that data you are consuming are as per the contracts that you specified.
validateMessage accepts the JSON data and tries to validate as per the user_registered.proto definition and if the data breaks any validation rules it will throw a validation error

Conclusion

Throughout this tutorial, you have learned Protobuf & how to use them with GO & RabbitMQ.

Protobuf is one of the ways to implement Messaging Contracts there are more options like Pact, AsyncApi

Now with this knowledge, you can use Protobuf on any programming language to send & receive the data. You have also learned that it was easier to predict the data that you are consuming or publishing.

Let me know if you have any comments /suggestions/feedback.

Source code: https://github.com/ujwaldhakal/golang-protobuf
Ref: https://stackshare.io/protobuf

Manage Multiple Cron with Helm Flow Control

ujwal dhakal — Mon, 04 Apr 2022 12:39:00 +0000

If you want to set up a Cron on your application, using a cron in Kubernetes is straightforward. All you need to do is copy the CronJob template.

If you have one cronjob then it won't matter much but if you have many cronjobs then creating each file per cron can be not fun sometimes.

Helm has Flow Control which can be used to manipulate dynamic values in the template.

In this article, we will create a single cron and then we will loop through the collections of cronjob commands to create multiple cronjob resource.

Creating a single CronJob:

Create a cronjob by copying the following code.

The file above creates a cron that runs every minute and prints some text.

Creating multiple Cronjob Commands:

Now let's create multiple cronjob commands which will hold all unique placeholders. We will now create a separate cronjob file that will hold the values i.e name, frequency, command etc of cron. Let's create a cronjobs.yaml inside .helm/values/cronjobs.yaml.

We will be creating four cronjobs which will have their own id, name, command, and schedule. But you can add more dynamic values if you want.

Pass dynamic values to helm template:

So far we have worked single cronjob then we created multiple cronjob commands. Now we want to loop those cronjobs commands inside the single cronjob so that we do not have to create multiple files manually.

There are multiple commands we can use in Helm Flow Control. For this we will use *{{- range $cronjob := $.Values.cronjobs }}* to loop over the values and access the dynamic values like {{$cronjob.id}},{{$cronjob.name}},{{$cronjob.schedule}} . As shown in the code below:

The final piece of the puzzle is to pass those dynamic values while installing/upgrading Helm. In order to do so, you can pass those values by using the — values keyword with the full path of that cronjobs command file i.e*.`*helm/values/cronjobs.yaml. `The final command will look something like this:

helm upgrade — install — values “.helm/values/cronjobs.yaml” multiple-cronjobs .helm

Conclusion:

We set up multiple cronjobs using two files one for defining the specs of the whole Kubernetes cronjob and the next for defining the dynamic values i.e command, frequency, name, etc. You can build/manage complex configurations using the Helm Flow Control.

Github Link: https://github.com/ujwaldhakal/multiple-cronjob-helm

Build a simple automated deployment pipeline for Cloud Run (Step by step tutorial)

ujwal dhakal — Wed, 05 May 2021 02:59:00 +0000

Automating the deployment pipeline is always a challenging thing. It requires a lot of effort in setting up the server for multiple environments, preparing the build, and deploying the same build into the server.

We will go step by on configuring simple deployment pipelines so you could build furthermore from that.

Intro

In this post, I am going to show you how easily one can make a deployment pipeline for their next app by just copying down the source code. We will be using a simple NodeJs Dockerized application to be hosted on Cloud Run. By the end of this read, you will be able to make a deployment for any language.

In this tutorial, we will be using the following stacks -:

Container Registry -: It will store all Docker Images to be used in Cloud Run
Google Storage -: It will save our state of Terraform.
Cloud Run -: Serverless platform where our final app will be hosted
Terraform -: It will help us to spin up Cloud Run instance and to create multiple working environments like staging and production
Go -: It will help us to trigger Terraform command whenever we want to with Github Actions
Github Actions -: It will help us as an entry point to trigger those Go command and Go will trigger terraform

Why Cloud Run, Go and Terraform?

Cloud Run

Cloud Run is a managed compute platform that enables you to run containers and Google Scales Containers as per the request and you pay per usage. The management of the infrastructure overhead is handled by Google itself so we can focus on building apps. Google has awesome doc at Cloud Run

Go

Go is a very popular programming language these days due to its fast, reliable, and simple architecture. With Go, we can generate binaries that will execute without installing anything so this feature is pretty handy while working with OS

Terraform

Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. So with Terraform, we can build the infrastructure like we build an app with Code i.e Infrastructure as Code.

Assumptions

You are familiar with how Go works
You are familiar with how Cloud Run works i.e specifying container image. If not check this article https://ujwaldhakal.medium.com/automate-cloud-run-deployment-in-a-minute-cb85e7db9f82
You are familiar with how Terraform spins up a new server and how Terraform manages state
You are familiar with Dockerizing the application.

Deployment tutorial steps

We will be building deployment pipelines in the following four steps-:

1. Dockerize application

First, we will create an application and dockerize it. Let's create a index.js the file inside the src directory and create a hello world response.

index.js

Now let's Dockerize it by adding Dockerfile. This is a simple Dockerfile where there is a multi-stage build and I have added as production it so that we could use the same Docker file for local and production. The same environment will be used while building the Docker image in the coming steps where we will build and push images to Google Container Registry.

2. Infrastructure setup with Terraform

First, we will write a terraform file where we will tell Terraform to spin up the Cloud Run instance. Let's create a GitHub project and create a folder cicd under which there are files need for terraform to create a cloud run instance with a given image.

and you only need to replace dev.tfvars and credentials/dev-cred.json with your actual credentials. We could actually test by running terraform apply for this to work you need an image in a Google Container Registry

terraform apply -var image_tag=docker_image_tag -var-file=dev.tfvars -auto-approve

Once we are able to push the Docker image to Container Registry then we are able to use this but we want to make it more simple and automated like what if we could deploy by running ./cicd/deploy dev master where dev is environment and master is the branch name in Git. Let's work on few files to achieve this

3. Triggering Terraform with Go

With Go, we can create binaries that will run without installing any further dependencies. Go will build a docker image and push it to the container registry if the image does not exist in the registry and trigger Terraform to deploy a new image to Cloud Run.

I am using https://github.com/ujwaldhakal/gcp-deployment-utils this package for all utilities in this demo. Getting a commit hash of the current branch, logging into Container Registry, and Pushing images are all done by the go-gcp-docker-utils package.

If you look at https://github.com/ujwaldhakal/gcp-deployment-utils/blob/master/docker/docker.go#LC24 this Build function closely there is the **target** being used in Docker File because oftentimes the way build will be different in production and local environment so make sure you use **target** in your docker file.

Inside function initTerraform

cmd := exec.Command(“terraform”, “init”, “-backend-config”, “bucket=tf-test-app”)

tf-test-app is the name of our bucket which one has to create manually in cloud storage

This deployer.go generates a deployerbinary by running go build deployer.go . Deploy binary expects one parameter which is the name environment and it will prepare a service account JSON dev-cred.json ,dev.tfvarsand Github Commit Hash to be used on Terraform apply. After that, it will try to try to check whether the image we are trying to build already exists or not. If it already exists, it won’t build. If not, it will build and push. And finally, it will apply to terraform with given credentials.

Since it will run inside GitHub action after checking out to the branch with given branch name with./cicd/deploy dev master .We will use the same commit hash to create tag in docker image and use the same image to deploy.
Note-: Make sure your IAM JSON has service to read bucket , create & destroy cloud run , read and add container images to Google Container Registry

If you want to modify anything you could just copy the same function from utils package and paste it in your actual project and start using your own instead of using the package

4. Glue everything with Github Action and Bash file

Finally, these two things will run inside Github Action Container upon manual command trigger i.e deploy dev master . As we have recently created deploybash inside cicdwhich will process our deploy dev master command and triggers Github Repository Dispatch which will trigger deploy.yml with payloads i.e name of environment and branch. Github Action will checkout to the branch given at deploy command and that will trigger deployer binary with environment name and as we already discussed how deployer. go handles the incoming request

In order to run this, you need to obtain a Github Personal Token follow the link to get one, and put it inside the .env file. Usually, we don't track the .env file on git so for this purpose I am pushing it to Github

Once you trigger that command ./cicd/deploy dev master ,deploy file will trigger GitHub action deploy.ymlpass those dev and master arguments where the GitHub action will checkout to that given branch i.e master and pass the name of the environment to deployer.gobinaries. Once binaries know the commit hash and environment name it will load the necessary credentials and trigger terraform apply with a new image dash and it will take minutes to get reflected.

You will see a green checkmark next to the deploy text once your deployment is successful. You can find the link to action at https://github.com/username/reponame/actions

Add More Environments

We have only seen setting up one environment i.e **dev. **But with more team members we will need more environment that could be production, staging,test1, test 2 based on your preference.

To add more environments is simple as just copying config files and editing them as most of the challenging part is already done i.e making up and running with one environment. Now we just need to create separate service account credentials by making a separate project from the same account on Google Cloud and make them accessible in **deployer. go **as we did for dev and production and you could add more environment either with an if-else pattern or just pass the dynamic variable to the environment name i.e ${environment}.tfvars and credentials/${environment}-cred.json.

Note -: If we don't want to create multiple Google Cloud Projects to handle multiple environments then we can use Terraform State to handle multiple environments with the same project.

func getTfVarFileName(env string) string {

if env == "dev" {

return "dev.tfvars"

}

if env == "production" {

return "prof.tfvars"

}

panic("Please select correct environment only dev & production available at the moment")

}

func getCredentialsFilePath(env string) string {

if env == "dev" {

return "credentials/dev-cred.json"

}

if env == "production" {

return "credentials/prod-cred.json"

}

panic("error on loading credentials")

}

This demo does not cover any DNS automation of adding a domain & verifying in Cloud Run. Since there is no encryption done for exposed credentials, please do not use this approach in Public Repositories. Only use this on Private Repositories.

If you want to encrypt the credentials, You could use Google Kms to encrypt with a key and decrypt with a key while using it to authenticate to Google Cloud.

Conclusion

This is just a basic idea of how to make CI/CD with minimal tools. With this approach, one can make CI/CD for normal application in a company, attach other google services in Terraform too like Cloud SQL, Redis, etc.

Special thanks and credits to Ujjwal Ojha for helping me understand & make CI/CD

Let me know your thoughts!

Source -: https://github.com/ujwaldhakal/cloud-run-cicd-boilerplate

Easily Manage Dot Files (Config Files)

ujwal dhakal — Tue, 13 Apr 2021 02:27:22 +0000

Whenever I migrated from an old laptop to a new laptop or re-installed the whole OS, I always ended up copying all the config files(Ide configuration, bash history, app profiles, etc) in a hard disk.

I either ended up copying all unnecessary configs(by zipping all) from the home folder or if I pick particular configs, I keep on missing things.

Even if I manage to zip all those things, storing them was another big challenge for me. Storing data comes with a cost as one would need to preserve it by storing locally or in any cloud. Updating the configs is even harder as I have to manually repeat all these steps.

So I started using Git to track my config files, so I created a Private Repo where I could push my all config files.

At first, I created a bash script with the name sync. sh inside directory dotfiles

sync.sh

#
#!/bin/bash
declare -a filesToSync=(".bashrc" ".bash_history" ".zshrc" ".zsh_history" ".gitignore_global" ".gitconfig")
## now loop through the above array
for i in "${filesToSync[@]}"
do
   cp ~/$i ~/dotfiles/$i
   # or do whatever with individual element of the array
done
declare -a foldersToSync=(".config/Terminator",".config/JetBrains") 
## now loop through the above array
for i in "${foldersToSync[@]}"
do
  cp -r ~/$i ~/dotfiles
   ## or do whatever with individual element of the array
done

So after running bash sync.sh the script would copy all my local config files and folders into the directory into the folder dotfiles.

Now all I need to do is run git add . git commit -m “message” git push -u origin master these commands to push to my Git Repository.

Then I again wanted to automate the above manual process on a weekly basis, so I created a file inside the same dotfiles directory with the name

cronscript.sh

#
#!/bin/bash
cd ~/dotfiles
bash syncfile.sh
git add .
git commit -m “weekly changes”
git push -u origin master -f

Finally, I created a weekly Cron job with crontab -e

0 0 * * 0 bash /home/ujwal/dotfiles/cronscript.sh

Conclusion

Every week my config files are getting synced automatically and I don't need to remember at all.

There are other great tools for managing dotfiles that have many more features than the above script like https://github.com/jbernard/dotfiles.
I simply made my own script as I could learn bash scripting side by side too.

7 Easiest Ways To Introduce Technical Debts

ujwal dhakal — Mon, 03 Aug 2020 15:59:09 +0000

Things that are left undone for making quality software due to various circumstances. Poor management, decisions making & process are major factor behind it.

It is just like a financial debt the longer you keep not paying your debts, worse and worse it gets.

So in this read, I will guide you how one can introduce “Technical Debt” effectively & efficiently

Here are 7 quickest ways to get the job done

1) Introduce multiple languages -:

Since most of the company these days follow microservices already. Introduce multiple languages in your microservices so that it would be difficult for the company to hire newcomers as well as for the existing member to collaborate.

2) Don’t follow any coding principles -:

I repeat please do not follow any coding principles or try to violate the principles like YAGNI, SOLID, KISS, DRY etc. After some time in your project, you won’t be able to extend new features easily. It would take many days to get the job done if you could manage to get the job done, be ready for more and more bugs.

3) Do not refactor & cover the test -:

Keep working on more features just don’t look back to refactor the code and do not write a single test for any functionalities. Eventually, you feel like your productivity has been decreased. This will help to introduce more bugs & take more time to release features.

4) Do not document a single thing -:

Whether is a complex logic you have written or a complex app you have built just don’t share a single word in any written format. Act like you are the single source of truth. Let your company & colleagues suffer to find the truth.

5) Do not monitor any projects -:

Let your projects grow wild into nature. Don’t put any logs & analytics into your application so with this you won’t actually know where to refactor & which features to work on next. If you are a company and planning to outsource new members just don’t analyze your team strength & capabilities. Let the new member do their part and let them leave without any handover.

6) Use multiple cloud services provider -:

Try to use many cloud service provider as you can. Try out new provider per project until you start feeling you have really made the worst decision. Your dependency will increase with multiple providers so that you would spend most of your time figuring out the things among providers.

7) Always rush -:

If a feature takes 3 weeks to build. Try to build it within 1.5weeks with all shortcuts, hack fix you know and don’t refactor later on. This way the complexity of code will increase and increase so that you will feel difficult to work with that project i.e (taking a long time to push new features, more time to fix bugs, bugs mating with bugs & more bugs)

Don’t take ownership of any work you do and don’t be responsible for any mistakes you made so that you won’t feel like there is a room for improvement. This way the fire can keep burning.

Conclusion

There are other indirect ways you could eventually introduce **Technical Debt **like demotivating your employees, mental burnout, lack of freedom, Micro-Management etc.

What are you doing for keeping your Mental Health green ?

ujwal dhakal — Sat, 25 Jul 2020 17:38:42 +0000

Fast Prototyping with Lighthouse Laravel

ujwal dhakal — Sat, 25 Jul 2020 17:14:42 +0000

Laravel is a full-fledged framework which is suitable for any kind of application from small, medium to large. And what so special about Laravel is the development process, they claim about rapid web development with it and there is no doubt.

What if I told, you can create an app a lot faster than before by using Lighthouse on Laravel. Lighthouse is a Graphql wrapper for Laravel.

I have used this on a side project DAANI API. DAANI is a crowdsourcing app build on Svelte & Laravel, Lighthouse.

Building on Graphql was easy than the normal REST approach. Here are some points why I felt that this could speed up the development process -:

Let's say if you want to create a record, just define a schema and action in the same line as this and it will create a model no need to create separate routes, controllers, requests for this.
```
type Mutation {
  createPost(title: String!): Post @create
}
```

and if you want to read the data this could be simple as

type Query {
  posts: [Post!]! @paginate
}

Note -: Mutation are for write part where (you would do update,create,delete)as Query are for read

Most of the CRUD actions are handled with default Directives provided by Lighthouse.

Most of the time we spend time documenting the Apis. With Lighthouse they provide default Playground for testing your API along with the documentation of yours schemas.

If you feel like you need a custom way around for your requirements. Extending is easy all you need to do is create a Resolver i.e (mutation or query) it acts as a controller like we used to do.

Conclusion

If you haven't worked with Graphql yet this could be a fun approach to know the Graphql mechanism. And if you have already tried it let me know your thoughts!

Happy Coding!

Daani Source Code

Deploy Sapper on Google Cloud Run

ujwal dhakal — Mon, 18 May 2020 06:33:21 +0000

Svelte is the next cool thing for frontend if you don't believe me just try it out and feel the experience of developing web applications with minimal efforts.

So I have tried Sapper which is built on top of Svelte with SSR (which is just like nuxt or next) support for my pet project. This blog post will be about how to deploy apps built with sapper on Google Cloud Run as I have faced issues while deploying.

This post assumes you are already familiar with Sapper, Google Cloud Run, Github Actions, and Docker.

There are two ways of deploying the Sapper apps

Exporting -: By running npm export on the root, it will generate a bunch of static files and now upload those to any web server, link domain and it will run.
Running Server -: By running npm run buildit will generate production build and then run npm run startwhich will start serving those build files you made. So we will be doing same thing on our Cloud Run and serve them. Here are some steps we will be doing -:

Dockerization -: As we will deploying docker container so we need to dockerize our app so create a file called Dockerfile in root.

    *# Use the official lightweight Node.js 12 image.*

    *# https://hub.docker.com/_/node*

    *FROM* node:12-slim

    *# Create and change to the app directory.*

    *WORKDIR* /usr/src/app

    *# Copy application dependency manifests to the container image.*

    *# A wildcard is used to ensure both package.json AND package-lock.json are copied.*

    *# Copying this separately prevents re-running npm install on every code change.*

    *COPY* / ./

    *# Install dependencies.*

    *RUN* npm install

    *# Compile to production

    *RUN* npm run build

    *EXPOSE* 8080

    *# Run the web service on container startup.*

    *CMD* [ "npm", "start" ]

It will set up an environment with node js pre-installed, set up your app, and serve with the desired port number.

Github Action & Cloud Run Setup -: Create a folder inside root with the name .github and inside that create workflows and then create a YML file name deploy.yml(You can use any name but you should strictly follow the directory convention) with configs and now the path and content should look like .github/workflows/deploy.yml

It will log in to your Google account, build the image, and deploy it to the cloud run. Three variables are used on Github Secrets

GCLOUD_AUTH -: This should be a 64baseEncoded string of your JSON credentials. You can use base64 path/to/jsonFile it to convert to JSON on Linux. Ref https://cloud.google.com/docs/authentication/getting-started

GCLOUD_PROJECT_ID- : Project id of your Google Account.

CLOUD_RUN_SERVICE_NAME -: Create a cloud with the same name you have added on Github Secrets.

Make sure you have added your Github repo on Cloud

On every push, it will build the image and deploy code to the Cloud Run.

Link for Github repo -: https://github.com/ujwaldhakal/sapper-on-cloud-run

Conclusion -:

In my opinion, I found out working with Svelte easy, comparing to React and Angular which I have worked with. Just give it a try for your next pet projects.

Keep Coding!

Why do we microservice?

ujwal dhakal — Mon, 17 Feb 2020 18:47:54 +0000

Well Microservice word itself explains micro + service which is the breaking
down of services into individual independent one. It's an architectural pattern
on designing the system and its flow.

But why do we need to microservice? Well let me explain with an example

Let's say someone wants to build an eCommerce application for a single country
with no shipping. Initially, he wants to launch eCommerce store with limited
100+ products only with, stripe & cash on delivery payment method. He wants to
build an eCommerce app so fast with less money & time so that he wants to know
whether this business idea is going to work or not.

Note that resources are limited Time, Money, Quality. If you focus on quality
you need more money and time. If you want to finish in less time with less
money, the quality will be less.

After 1 month of hard-working eCommerce, the app was ready where people could
buy listed products with limited payment gateway for a single country. The
developer has made an application keeping in mind that the site will only handle
1000 users per second or less than 1000 users since the owner wanted to build
his MVP so fast. Now the eCommerce seems booming, each and every people are
loving this idea and using in their daily life. Now more people using means more
traffic means your limited computing resource has to serve many people now. As
this business is booming now the owner wants to build further, he wants to make
it global with a variety of payment gateways, shipping, inventory management to
work on. As the traffic starts to increases-:

The site seems extremely slow people had to wait for more time to choose products.
Adding a new payment gateway, shipping method etc was taking so much time.
A bug in one feature was taking a whole system down which was reported by the customer.
Deploying was taking so much time than it used to.
The server was from the US region and people from Asia are facing some latency issues.
Since they were using PHP everywhere and they wanted to use languages like go, the node for concurrency, parallelism for more efficient computation. But it was difficult for them to implement a new stack.

Now he wants his tech team to solve these problems and tech team has one thing
in mind, an idea of restructuring them into microservices (Product listing
service, payment service, order processing service, inventory management
service, Automation testing service, etc) and after they have successfully
implemented microservices

Scaling site was easy for them they could rewrite site into the latest stack.
Adding a new payment gateway, shipping method, features was easy for them as code base was splitted it was easy for multiple developers to work autonomously.
Now a downtime of one service won't affect the downtime of others
Deploying was so much easier for them as they had used Kubernetes/ EKS and they could easily deploy/revert specific services they have worked on
Due to their flexibility, they were able to implement dedicated DevOps for multi-region network serve and they have been implementing Kubernetes and scaling their services according to traffic.
Now their frontend relies on on react js, whereas they have been using PHP for some for product listed & checkout. Where was order processing was done by Golang leveraging concurrency and they have been using cypress for UI Automation

Like everything comes off with tradeoff surely microservice is no different it
has its own tradeoffs like the specialized team to handle multiple services,
hard to trace / monitor, hard to maintain consistency, etc which I will describe
in a future post. So decide which one will you really need. Happy Coding!

I think this is non technical but lets share our work playlist?

ujwal dhakal — Thu, 07 Nov 2019 04:05:36 +0000

What does a good company culture really mean?

ujwal dhakal — Sun, 03 Nov 2019 09:37:31 +0000

DEV Community: ujwal dhakal

Application Resilience: 4 Ways to Build It

How to build a resilient system

1) Auto healing -

2) Monitoring -:

3) Testing

4) Incident Retros

Conclusion

How to use Protobuf with Go?

How to use Protobuf with Go?

Table Of Contents

Prerequisites

Protobuf

Bootstrapping Project

Creating Protobuf Messages

Publishing a Message

Consuming a Message

Conclusion

Manage Multiple Cron with Helm Flow Control

Creating a single CronJob:

Creating multiple Cronjob Commands:

Pass dynamic values to helm template:

Conclusion:

Build a simple automated deployment pipeline for Cloud Run (Step by step tutorial)

Intro

Why Cloud Run, Go and Terraform?

Cloud Run

Go

Terraform

Assumptions

Deployment tutorial steps

1. Dockerize application

2. Infrastructure setup with Terraform

3. Triggering Terraform with Go

4. Glue everything with Github Action and Bash file

Add More Environments

Conclusion

Easily Manage Dot Files (Config Files)

Conclusion

7 Easiest Ways To Introduce Technical Debts

Conclusion

What are you doing for keeping your Mental Health green ?

Fast Prototyping with Lighthouse Laravel

Conclusion

Deploy Sapper on Google Cloud Run

Why do we microservice?

I think this is non technical but lets share our work playlist?

What does a good company culture really mean?