SE Internship Log[4]
Tags: javascript, frontend, tools
Published: 2021-08-23 10:16:50

---
title: SE Internship Log[4]
published: true
description: Re-thinking performance, Next.js measuring performance, label-sync, and being proactive.
tags: javascript, frontend, tools
series: Software Engineering Internship Log
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/h5s0qk6vewwke0zey3ja.jpg
canonical_url: https://ruheni.dev/writing/se-internship-log-4/
---


Hello there internet stranger, 👋🏽

Welcome to the 5th edition of the Software Engineering(SE) Log.

This week was frustrating. I spent the week trying to debug a test that failed 1-3 times a day (a cron job that runs on an hourly basis). 

When does it fail? Anytime.

Why does it fail? The response data is 0 instead of 20(expectation).

Why is it 0? No freakin' clue. 🥲

Hopefully, the upcoming week will be better than the previous one.

Enough with the rant. This week, I learned a bunch of stuff – re-thinking performance, [Next.js measuring performance](https://nextjs.org/docs/advanced-features/measuring-performance), [label-sync](https://github.com/maticzav/label-sync), and being proactive.

## Technical Skills

### Re-thinking performance

This won't be about bloated JavaScript bundles or optimizing. I'm not an expert.

This week, I got a comment on a PR for a task I was working on that I was making an expensive API call – introspecting the user's database checking for any tables.

No big deal? Well, it is. This operation would happen every time a user opens a project.

This changed how I think about API requests from the frontend in terms of:
- Cost
- User experience.
- Compute required to make a task happen – on the API, and the user's resources which in this case is their database

Just because you can do something doesn't mean you should. Compute resources are finite. Evaluate the impact of the requests you make and how you can cut down on what isn't necessary.

### Next.js Measuring performance

Vercel provides analytics on application performance for different stacks – Next.js included.

Next.js can provide tooling that allows you to measure analytics and use your own custom analytics.

The metrics that Next.js allows you to track include:
- [Web Vitals](https://web.dev/vitals/) - these metrics measure and report the performance of your application to ensure you're delivering a great user experience. 

<!-- The link provides a great overview of what the metrics are, how to measure them, health of your application  -->
- [Custom Metrics](https://nextjs.org/docs/advanced-features/measuring-performance#custom-metrics) - this is specific to Next.js measuring the time taken for a page to hydrate and render:
  - `Next.js-hydration` - time take for a page to start and finish hydrating
  - `Next.js-route-change-to-render` - time taken for a page to render a page after navigating to the route
  - `Next.js-render` - time taken for a page to finish rendering after a route change

> 💡 Fun learning project idea - build your own/ custom tool to measure these analytics. The aim would be to learn how to store time-series data, average the data, and visualize the data. Chrome devtools and [Web.dev](https://web.dev/measure) doesn't measure custom Next.js metrics.
>You can see how well my site is performing 🤡
![ruheni.dev analytics](https://user-images.githubusercontent.com/33921841/130419796-0257f6c5-a2ea-4f58-943d-0f13d32599dc.png)

In your Next.js application, edit/ create `_app.js` in the `/pages` directory. Define the `reportWebVitals` function:

```js
export function reportWebVitals(metric) {
  switch (metric.name) {
    case 'FCP':
    // handle results - console.log or send to an API (same case for other metrics)
      break
    case 'LCP':
      break
    case 'CLS':
      break
    case 'FID':
      break
    case 'TTFB':
      break
    case 'Next.js-hydration':
      break
    case 'Next.js-route-change-to-render':
      break
    case 'Next.js-render':
      break
    default:
      break
  }
}
```

These analytics provide insights into how user experience is, parts of your application that are not doing too well, and tips on improving performance in your web application.

### 🧰  Label-sync

Label-sync is a handy tool that makes managing GitHub labels across multiple repositories delightful.

Why do you need it? You don't.

The default GitHub labels are okay. But, they could be better.

GitHub labels provide meta-data for a GitHub issue. This could be the context of a given problem, for example backend, frontend, bug, test, improvement, feature, whether an issue requires discussion, time, and the list goes on on what this could be

Label-sync allows you to define affected repositories, labels, themes, descriptions, group labels, etc.

It requires some configuration when starting. However, managing issues in your projects will be a delight.

_This is a personal opinion._

## Soft Skills 

### Being Proactive

Being proactive involves taking responsibility in your life. It involves anticipating problems, seeking solutions, and giving it your best shot.

The alternative to being proactive is reactive - responding to tasks/life as they stream. 

You are responsible for your growth, including your career.

Go out there, ace it and have a great week!

Till next week. ✌🏽