DEV Community: Krishna Pravin

Recommend VS Code extensions to your future teammates

Krishna Pravin — Sat, 28 Nov 2020 03:08:41 +0000

If you are using an awesome VS Code extension and you want to share it with your current team members and future ones, you can use this feature of VS Code.

Configuring recommended extensions

Open the command palette CMD + Shift + p
Type Configure Recommended Extensions
A new file called extensions.json will be created under .vscode/ in the root of the project.
Place the cursor within the recommendations array and press CMD + i.
Select the required extensions from the list of installed extensions and save the file.
Include this file in your source control tools(we use Git).

Installing recommended extensions

Once the configuration is done, everyone who opens your project will get a recommendation notification like this
From here the extensions are just a click away.
On clicking Install all recommended extensions will be installed.

For any reasons, if the notification doesn't show up we can manually open up Recommended Extensions settings

Open the command palette CMD + Shift + p
Type Show Recommended Extensions
All the extensions can be installed together or only required extensions can be installed

CMD + i is one of the default VSCode shortcuts to trigger suggestions/IntelliSense.

Keystrokes and mouse clicks can be made visible in VSCode by turning on the Screencast Mode from the command palette.

Feel free to comment your thoughts on this. Let me know if you find this useful, do share your tips and tricks for utilising VSCode to its fullest.

for loop vs .map() for making multiple API calls

Krishna Pravin — Thu, 14 May 2020 04:42:17 +0000

Promise / async-await is used for making API calls.

const response = await fetch(`https://jsonplaceholder.typicode.com/todos/1`)
const todo = await response.json()
console.log(todo)

Assuming I have a list of ids of todo items and I want the title of all them then I shall use the below snippet inside an async function

const todoIdList = [1, 2, 3, 4]
for (const id of todoIdList) {
  const response = await fetch(`https://jsonplaceholder.typicode.com/todos/${id}`)
  const todo = await response.json()
  console.log(todo.title)
}

This same can be written with any of these for, for...in, for...of loops.

Assuming each API request arbitrarily takes 100ms exactly, the total time taken for getting the details of four todo items will have to be greater than 400ms if we use any of the above-mentioned loops.

This execution time can be drastically reduced by using .map().

const todoIdList = [1, 2, 3, 4]
await Promise.all(
  todoIdList.map(async (id) => {
    const response = await fetch(`https://jsonplaceholder.typicode.com/todos/${id}`)
    const todo = await response.json()
    console.log(todo.title)
  })
)

Adding timers

const todoIdList = [1, 2, 3, 4]
console.time('for {}');
for (const id of todoIdList) {
  const response = await fetch(`https://jsonplaceholder.typicode.com/todos/${id}`)
  const todo = await response.json()
  console.log(todo.title)
}
console.timeEnd('for {}');

console.time('.map()');
await Promise.all(
  todoIdList.map(async (id) => {
    const response = await fetch(`https://jsonplaceholder.typicode.com/todos/${id}`)
    const todo = await response.json()
    console.log(todo.title)
  })
)
console.timeEnd('.map()');

The Reason

for loop

for loop goes to the next iteration only after the whole block's execution is completed. In the above scenario only after both the promises(await) gets resolved, for loop moves to the next iteration and makes the API call for the next todo item.

.map()

.map() moves on to the next item as soon as a promise is returned. It does not wait until the promise is resolved. In the above scenario, .map() does not wait until the response for todo items comes from the server. It makes all the API calls one by one and for each API call it makes, a respective promise is returned. Promise.all waits until all of these promises are resolved.

async/await is syntactic sugar for Promises

It will be more clear if the same code is written without async/await

const todoIdList = [1, 2, 3, 4]
console.time('.map()')
Promise.all(
  todoIdList.map(id => {
    return new Promise((resolve) => {
      fetch(`https://jsonplaceholder.typicode.com/todos/${id}`)
        .then(response => {
          return new Promise(() => {
            response.json()
              .then(todo => {
                console.log(todo.title)
                resolve()
              })
          })
        })
    })
  })
)
.then(() => {
  console.timeEnd('.map()');
})

It is not possible to mimic the respective code for for loop by replacing async/await with Promises because, the control which triggers the next iteration will have to written within the .then() block. This piece of code will have to be created within the JS engine.

All the snippets are working code, you can try it directly in the browser console.
Note:

snippets need to be enclosed within an async function except for the last one
use Axios or any other suitable library if fetch is not available.

Let me know if there is an even better and easy/short way of making API calls.

Also, do not forget to mention any mistakes I've made or tips, suggestions to improve this content.

How to edit files in a Heroku dyno and persist it

Krishna Pravin — Mon, 11 Nov 2019 16:08:13 +0000

If you edit files present in a Heroku dyno, the edited file comes back to its initial state after some time. This is because Heroku restarts the dynos randomly for keeping them in good health.

Heroku Deployment Process:

skip this if you are familiar

Initiating deployment:
- Heroku deployment can be triggered manually or it can be configured to get triggered automatically by connecting Heroku to GitHub.
During deployment:
- Heroku builds the application based on default settings or based on the configured build packs.
- At the end of this process, a slug will be created. A slug is nothing but the files that were generated during the build. A slug is similar to a docker image (not exactly).
The created slug is deployed in AWS EC2 instances, which is called as dynos by Heroku.
At random intervals, the slug is redeployed for maintaining the health of the dynos #ref

👆This is the reason why files edited in a dyno will be reset to its initial state.

👻

So, How can we make changes to the files in a Heroku dyno which does not reset to its previous version?

One straightforward solution is to make the changes in the source code and redeploy the application.

Yes, this is one way of achieving it.

But, You may wonder why there would be another scenario. One rare scenario is: You want to change a HTML file (urgent client requirement) that is already part of an application in the production environment, but your build process is getting timed out and you are not able to find the reason.

So, The other solution is:

By editing the previously generated slug and using the edited slug in the required application/environment.

Steps to edit the slug and deploy it:

(100% no build process is required)

Download Heroku CLI
- https://devcenter.heroku.com/articles/heroku-cli#download-and-install
Login to your Heroku account using the CLI
- $ heroku login
- This will take you to a browser to fill the login form.
List all the deployed applications
- $ heroku list --all
Get the unique slug identifier and version number
- $ heroku slugs -a your_application_name
- Use the name of the application which has the files you want to edit.
- You will get all the unique slug identifiers along with their version numbers that are generated and used by your application until now.
- This version number can be verified from the dashboard https://dashboard.heroku.com/apps/your_application_name/activity
- If you have too many deployments, store the list to a file
- $ heroku slugs -a your_application_name > slugsList.txt
Download the slug
- To download, you need an additional Heroku CLI plugin
- Install the additional plugin using heroku plugins:install heroku-slugs
- Then $ heroku slugs:download your_unique_slug_identifier -a your_application_name
- This will download and create a folder with the name of your application.
- The created folder will contain a directory called app which contains the generated source code and a slug.tar.gz file, which is the compressed version the source code.
Edit the required files present within the ./app directory.
Create new slug archive
- Heroku currently has limited tar-file compatibility. Please use GNU Tar (and not bsdtar) when creating slug archives. You can check your tar version with tar --version.
- While running the below command, you should be in the same directory level as that of ./app directory.
- $ tar czfv slug.tgz ./app
- slug.tgz is the name of the archive that will be created
- c - create, z - gzip format, v - show status, f - file name and location

Create a unique identifier for the new slug

$ curl -X POST \
-H 'Content-Type: application/json' \
-H 'Accept: application/vnd.heroku+json; version=3' \
-d '{"process_types":{"your_process_type":"your_command"}}' \
-n https://api.heroku.com/apps/your_application_name/slugs

If you don't know your process type(s) and the respective commands, then go to https://dashboard.heroku.com/apps/your_application_name/resources
For my application, I have two process types. So I will be sending this data in the API call
{"process_types":{"web": "bundle exec puma -p $PORT -C ./config/puma.rb", "worker": "bundle exec rake jobs:work"}}
-n flag tells curl to read the credentials for api.heroku.com from ~/.netrc and automatically sets the Authorization header.
-H flag sets the respective header
-d flag represents the data to be sent in HTTP POST request

You will get a response like this

{
  "blob":{
    "method": "put",
    "url": "https://s3-external-1.amazonaws.com/herokuslugs/heroku.com/v1/d969e0b3-9892-4567-7642-1aa1d1108bc3?AWSAccessKeyId=AKIAJWLOWWHPBWQOPJZQ&Signature=2oJJEtemTp7h0qTH2Q4B2nIUY9w%3D&Expires=1381273352"
  },
  "commit":null,
  "created_at":"2013-10-08T22:04:13Z",
  "id":"d969e0b3-9892-3113-7653-1aa1d1108bc3",
  "process_types":{
    "web":"node-v0.10.20-linux-x64/bin/node web.js"
  },
  "updated_at":"2013-10-08T22:04:13Z"
}

blob.url - AWS S3 URL for the new slug
id - Unique identifier for the new slug
Heroku docs reference

Upload the created slug archive to AWS S3

$ curl -X PUT \
-H "Content-Type:" \
--data-binary @slug.tgz \
"https://your_aws_s3_blob_url"

slug.tgz is the name of the archive file we have created.

Create a new release for your application which will use the new slug archive which we have created and uploaded to AWS S3

$ curl -X POST \
-H "Accept: application/vnd.heroku+json; version=3" \
-H "Content-Type: application/json" \
-d '{"slug":"your_unique_identifier_of_new_slug"}' \
-n https://api.heroku.com/apps/your_application_name/releases

You can verify the release status in the Heroku dashboard or using heroku releases --app your_application_name