S3 + CloudFront

Build your frontend and upload the static files to an S3 bucket. CloudFront is configured to distribute these assets globally, with support for SPA routing, custom error handling, and cache control. Builds can be versioned by directory (e.g. /v1.3.2/) and served by changing CloudFront origin settings or rewrites.

Pros:

• Low cost, scalable, and reliable.

• Global performance via CloudFront’s CDN.

• Easy rollbacks by switching directory paths or aliases.

• Full control over cache headers, security, and routing.

• Easily scriptable with CI tools.

Cons:

• Initial setup takes effort.

• Must handle deployments and cache invalidation yourself.

• No built-in CI/CD previews.

This approach is ideal for production-grade applications, especially in enterprise environments where performance, control, and cost optimization matter. It works well for static SPAs, marketing sites, or internal portals requiring strict cache policies, SPA routing, and versioning. Teams that prefer custom pipelines and infra-as-code love this model for its flexibility.

Amplify

Amplify Hosting is a fully managed CI/CD + hosting solution for frontend apps. Once your Git repository is connected, Amplify builds and deploys automatically on each commit. It includes global CDN, HTTPS, branch-based preview deployments, custom domain setup, and support for all major frontend frameworks. Amplify handles deployment infrastructure behind the scenes.

Pros:

• Very fast to get started.

• Built-in CI/CD with preview branches.

• Built-in HTTPS, SPA routing, and hosting via CDN.

• Good integration with other Amplify services.

Cons:

• Less control over infrastructure and caching behavior.

• Harder to integrate into custom versioning or rollback strategies.

• Preview builds and multiple branches can increase cost quickly.

Amplify is a great fit for startups, prototypes, MVPs, hackathons, or any project where speed, simplicity, and quick feedback matter. It’s excellent for smaller teams or solo developers who don’t want to manage infrastructure. It's also useful during early product development when CI/CD and preview environments offer high velocity.

ECS + EC2/Fargate

You package your frontend build into a Docker image (usually with NGINX to serve static files) and deploy it using ECS. With Fargate, AWS manages the compute; with EC2 launch type, you manage the servers. You define task definitions, services, and optionally use Application Load Balancers or CloudFront for distribution. You roll back by deploying an older Docker image or version-tagged container.

Pros:

• High control over web server behavior, headers, and routing logic.

• Suitable for containerized infrastructure alongside other services.

• Works well with CI/CD pipelines and infrastructure as code.

• Rollback is easy by re-deploying previous container versions.

Cons:

• Higher complexity — requires Docker knowledge and ECS familiarity.

• Not cost-efficient for purely static apps (more infra than needed).

• Slower to set up and deploy compared to Amplify or S3.

This approach is ideal for larger, containerized applications where frontend and backend are tightly integrated and deployed together. It's commonly used by teams with DevOps maturity, especially when using ECS for the backend and wanting unified infrastructure. It's a strong choice when advanced routing, custom headers, or NGINX tweaks are needed, but overkill for simple static SPAs.

EC2

This is a traditional approach where you provision one or more EC2 instances, configure an OS-level web server (like NGINX or Apache), and serve your built frontend app from the instance. You might set up an Elastic Load Balancer (ELB) or integrate with CloudFront for CDN support. Deployments typically involve copying build files via SSH or through automated CI/CD scripts.

Pros:

• Full control over the hosting environment (OS, web server config).

• Works well for legacy setups or when deep customization is needed.

• Easy to host multiple apps or custom backends on the same server.

Cons:

• High maintenance — must patch, scale, and monitor servers yourself.

• Slower deployments unless automation is set up.

• Can be costly and less efficient for static frontends.

Hosting SPAs on EC2 makes sense in legacy environments or when your team is already managing EC2 infrastructure and wants tight OS-level control. It’s also a fit for highly customized web servers or setups where containerization isn't yet adopted. However, for new projects, it’s generally recommended to prefer Fargate or static hosting models.

• Azure DevOps' Personal Access Tokens page shows error: TF400893: Unable to contact the server. Please check your network connection and try again.

• Visual Studio’s Connect to a Project dialog shows no repositories.

• Visual Studio’s authentication fails with error: We could not refresh the credentials for the account "..." The SSL connection could not be established, see inner exception.

• Visual Studio pops up the “Let’s get you signed in” dialog in a infinite loop.

• Visual Studio’s account icon does not show profile image.

• Cloning repository from the command line shows error:

    fatal: An error occured while sending the request.
    fatal: The underlying connection was closed: An unexpected error occured on a send.
    fatal: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
    fatal: An existing connection was forcibly closed by the remote host.
    fatal: Authentication failed for '...'
  

Solution

Long story short, this can be resolved by turning off the IPv6 adapter on your machine. If you are on Windows, follow these steps:

1. Go to the Control Panel → Network and Internet.

2. Select Network and Sharing Center → Change adapter settings.

3. Right click on your active adapter → Properties.

4. Uncheck Internet Protocol Version 6 (TCP/IPv6).

5. Click Ok.

If you are using another operating system, use this guide to disable IPv6.

If you prefer to keep using the IPv6, you can alternatively disable IPv6 specifically for dev.azure.com URL by editing the hosts file.

1. In the File Explorer, navigate to C:\\Windows\\System32\\drivers\\etc\\hosts.

2. Add a new line at the bottom of the file: 13.107.42.20 dev.azure.com

IPv4 and IPv6

IPv4 (Internet Protocol version 4) is the foundation of most internet traffic today. It uses 32-bit addresses, which allows for about 4.3 billion unique IP addresses — once thought to be more than enough. But as the internet grew, we quickly ran out of available IPv4 addresses. To solve this, IPv6 was developed. IPv6 uses 128-bit addresses, offering an enormous address space (3.4 × 10^38 possible addresses) and includes modern networking features like simplified routing and improved security.

Despite being introduced in the late 1990s, IPv6 adoption has been slow — especially in enterprise environments. Many internal systems, corporate firewalls, VPNs, and even cloud-based tools are still built with IPv4 as the default. Microsoft services like Azure DevOps and Visual Studio, for example, still exhibit spotty or incomplete support for IPv6. In some cases, applications will attempt to use IPv6 first, but fail to connect or time out silently. Without proper fallback to IPv4, this results in broken authentication, clone failures, or unresponsive UIs.

Further reading

• Troubleshooting Azure DevOps by Anchorpoint.

• How To Disable IPv6 on Various Operating Systems?

• Stack Overflow answers for fatal connection error with Azure DevOps.

• Why is IPv6 not widely used in today’s Internet?

Acceptance Criteria

Before brainstorming solutions, let’s first set some ground rules:

• Client-Side: The page must be fully static and run entirely in the browser — no backend, no server-side logic. This ensures it’s easy to host anywhere and works in restrictive environments.

• Simple Deployment: There should be no build process or bundling step required. Just pure HTML, CSS, and vanilla JavaScript — drop the files into a server and it should just work.

• Maintainable: While the ideal setup would involve fetching the list of resources from an external API, the initial implementation can use a hardcoded array of URLs. This keeps the MVP simple and testable.

• Reporting: For each URL, the tool should clearly and accurate indicate whether it is accessible. The status must be visually obvious (e.g., ✅, ❌, ⏳).

• Secure: Any method used to check URLs must not interfere with the styling, behavior, or security of the page itself. This includes isolating loaded scripts or styles to avoid accidental side effects.

3 Possible Approaches

1. fetch()

The fetch() approach is a straightforward way to check if a URL is reachable, but its behavior depends on CORS settings. With standard fetch(), the browser requires the server to allow cross-origin requests via CORS headers; if not, the request will fail—even if the URL is actually reachable. To work around this, using fetch() with mode: 'no-cors' lets the request go through silently without needing CORS approval. While the response is opaque and doesn’t give detailed status codes, it still indicates whether the resource was blocked entirely or not. This makes the no-cors method a practical choice for checking basic reachability across different types of assets.

2. DOM Injection

The DOM injection approach works by dynamically adding <script>, <link>, or <img> elements to the page and watching for their onload or onerror events. If the resource loads successfully, it’s likely not blocked; if it fails, the browser will fire an error event, signaling that it might be blocked by a firewall or content filter. This method gives a more accurate picture of whether the resource can actually be fetched and used by the browser. It's especially useful for fonts, stylesheets, and JavaScript files, though care must be taken to avoid interfering with the existing page layout or behavior.

3. Using <iframe>

The <iframe> approach involves embedding an external URL inside a hidden or sandboxed iframe and observing whether it loads successfully. If the iframe triggers a load event, the resource is likely accessible; if not, it may be blocked. While this method can detect general reachability, it’s less precise for specific assets like fonts or scripts. It’s best used for checking full websites or dashboards rather than individual files. Additionally, many sites block iframe embedding using headers like X-Frame-Options, which can limit its effectiveness.

Implementation

To keep things lightweight and avoid CORS headaches, I chose to implement the diagnostics page using the fetch() API with mode: 'no-cors'. This approach doesn't give you access to the actual response content or status code, but it does let you know whether the browser was able to reach the resource at all—which is perfect for detecting firewall blocks. For each URL I want to check, I make a HEAD request in no-cors mode, and if the request completes without throwing an error, I consider that a success. While the response object is opaque and always returns ok: false, the real signal is whether the .catch() block is triggered. If it throws, the resource is most likely blocked; if it doesn't, the URL is accessible.

This approach lets the diagnostics tool focus purely on reachability, which is usually what matters when dealing with IT departments and URL whitelisting. I wrapped each check in a small promise and updated the UI with a status icon: a green check for success, a red “x” for failure, and a spinner while the check is in progress. Since the diagnostics page is entirely client-side, there are no privacy concerns, no server logs, and no CORS configuration required. It works from any browser and doesn’t require installation — just load the page and instantly see which URLs are blocked. This approach gave me the right balance of simplicity, reliability, and ease of deployment.

This is the heart of the logic, using fetch() in no-cors mode:

function checkUrlAccessibility(url) {
  return new Promise((resolve) => {
    fetch(url, {
      method: 'HEAD',
      mode: 'no-cors',
    })
      .then(() => resolve(true))
      .catch(() => resolve(false));
  });
}

Looping through an array of resources to check each one and update the UI accordingly:

const resources = [
  { name: 'Google Fonts', url: '...' },
  { name: 'Font Awesome', url: '...' },
  { name: 'Bootstrap', url: '...' }
];

resources.forEach(resource => {
  showLoadingIcon(resource.name);
  checkUrlAccessibility(resource.url).then(isAccessible => {
    updateStatusIcon(resource.name, isAccessible);
  });
});

Testing

To test whether the diagnostics page correctly detected blocked resources, there are a few simple options — such as using intentionally breaking URLs, using a browser extension, or modifying the hosts file to simulate a DNS failure. All of these approaches are easy ways to trigger errors without requiring a significant time to set up.

However, the best approach I found was to use the browser’s DevTools. By manually blocking specific domains in the Network tab, I could mimic a client's firewall filtering out resources. This allowed me to confirm that the diagnostics page correctly showed failures without needing to set up a real firewall or proxy. With everything working as expected, the tool was ready to hand off to client IT teams for real-world testing.

We recently implemented a data export feature that allows users to retrieve specific reports by selecting an option via radio buttons. To assess the feature's adoption and understand user preferences, we needed a way to track how often users initiate an export and which report types are being requested most frequently. After evaluating different solutions, we chose DataDog Real User Monitoring (RUM).

What is DataDog?

Datadog is an observability platform that supports every phase of software development on any stack. The platform consists of many products that help you build, test, monitor, debug, optimize, and secure your software. These products can be used individually or combined into a customized solution.

What is DataDog RUM?

DataDog Real User Monitoring (RUM) provides deep insight into your application’s frontend performance. Monitor real user data to optimize your web experience and provide exceptional user experiences. Correlate synthetic tests, backend metrics, traces, and logs in a single place to identify and troubleshoot performance issues across the stack.

With the Datadog RUM Browser SDK, you can also:

• Monitor your application’s pageviews and performance to investigate performance issues.

• Gain complete, end-to-end visibility into resources and requests (such as images, CSS files, JavaScript assets, and font files).

• Automatically collect and monitor any interesting events with all relevant context, and manually collect errors that aren’t automatically tracked.

• Track user interactions that were performed during a user journey so you can get insight into user behavior while meeting privacy requirements.

• Surface user pain points with frustration signals.

• Pinpoint the cause of an error down to the line of code to resolve it.

Cost

DataDog RUM pricing is based on session volume, meaning you pay for each user session that interacts with your application. A session typically starts when a user loads a page and ends after 15 minutes of inactivity. Basic RUM starts at $1.50 per 1,000 sessions. RUM with Session Replay starts at $1.80 per 1,000 sessions.

Alternative solution

If your company will not pay for DataDog RUM, Log Management (Log Collection) can serve as a viable alternative for tracking user interactions and frontend performance. While RUM is built for real user monitoring, logs can be structured to capture similar data points with added flexibility.

The main 3 difference from RUM and Log Management are:

1. Log Management does not monitor user interactions. It is a backend-driven logging system; therefore, requires an API request from the frontend.

2. Log Management requires more configurations as its intended use is wide and provides more control.

3. Log Management will likely be cheaper, although this varies on the number of logs compared to the number of sessions.

Implementation

All of the code snippets below use the Aurelia framework, so depending on a library/framework you’re using, the implementation can vary minorly.

1. Install the npm package

To use the DataDog Browser SDK, install the following npm package: npm i @datadog/browser-rum. At the time of this writing, the latest package version is 6.4.0 with a bundle size of 59.5 kB (gzip) .

2. Add a new application in the DataDog dashboard

In Datadog, navigate to the Digital Experience > Add an Application page and select the JavaScript (JS) application type.

3. Create a new service in the frontend

The readonly rumConfig object should be copied and pasted from the DataDog dashboard.

import { datadogRum } from '@datadog/browser-rum';
import appSettings from '../../config/appsettings.json';
import packageInfo from '../../package.json';

export class MonitoringService {
  /** Application configurations */
  readonly rumConfig = {
    applicationId: '{{APPLICATOIN_ID}}',
    clientToken: '{{CLIENT_TOKEN}}',
    site: 'datadoghq.com',
    service: '{{SERVICE}}',
    env: appSettings .environment,
    version: packageInfo.version,
    sessionSampleRate: 100,
    sessionReplaySampleRate: 20,
    defaultPrivacyLevel: 'mask-user-input',
  } as RumInitConfiguration;

  constructor() {}

  /**
   * Initializes RUM browser SDK
   */
  initialize(): void {
    datadogRum.init(this.rumConfig);
  }
}

It is valuable here that the environment and the version is dynamic. For our case, I retrieved the environment from client side app settings, and the versioning number from the package.json file.

4. Initialize DataDog RUM SDK on site load

Wherever the root page load logic lives, for us is in the activate method of app.ts , inject the newly created service, then call the initialize() method:

constructor(
  @inject(MonitoringService) private monitoringService: MonitoringService,
) {}

/**
 * Activate lifecycle hook
 */
async activate(): Promise<void> {
  this.monitoringService.initialize();
}

5. Add a method for logging a custom action

Now that we’ve initialized the RUM SDK, all of the built-in features can be viewed in the dashboard. To fulfill the requirement however, we can add a new method in the MonitoringService class:

/**
 * Logs a custom user interaction action
 * @param actionName Unique action name
 * @param additionalInfo Additional data to include in the metric
 */
logCustomMetric(actionName: ActionName, additionalInfo: object): void {
  datadogRum.addAction(actionName, {
    timestamp: new Date().toISOString(),
    ...additionalInfo,
  });
}

Using an enum for the metricName here is key in order to prevent duplicate names from being used.

/**
 * List of action names used for DataDog RUM's custom metrics
 */
export enum ActionName {
    DownloadAssessment = 'download_assessment',
}

6. Call method from the component file

Finally, we are complete with the service implementation. We are able to call the logCustomMetric() method from anywhere in the application to track any user interaction. Here is an example of a component TypeScript file, triggering a button press to download an assessment deliverable:

constructor(
  @inject(MonitoringService) private monitoringService: MonitoringService,
) {}

/**
 * Downloads PDF deliverable of the assessment
 */
downloadAssessment(): void {
  this.canDownloadAssessment = false;
  this.monitoringService.logCustomMetric(
    MetricName.DownloadAssessment,
    {
      pageName: 'PerformReview',
      fileType: 'PDF',
    },
  );

  this.pdfService
    .downloadPdf(this.assessmentId)
      .then((file) => {
        if (file) {
          this.fileService.downloadFile(file.fileDownloadName, file.contentType, file.fileContents);
        }
      })
      .finally(() => (this.canDownloadAssessment = true));
}

Result

View the dashboard!

Security concerns

Storing applicationId and clientToken in JavaScript feels like a security vulnerability considering a user can easily retrieve it using Developer Tools. However, these values are intended to be stored in the browser’s JavaScript, similar to Google Analytics tool.

The following reasons are why it is safe to keep the strings in the client side:

1. The applicationId and clientToken are used to identify which account or project the data belongs to, not to authenticate users or provide access to private systems.

2. These tokens only allow data to be sent to the monitoring service. Even if someone extracts them from the browser, all they can do is send fake analytics data—they can’t steal or view any sensitive information from your system.

3. DataDog RUM has built-in protections against spam or misuse, such as:

   • Rate limiting (to prevent excessive requests).

   • Domain whitelisting (so data is only accepted from approved websites).

   • Filtering and validation (to detect and ignore invalid or manipulated data

Ad Blockers and VPNs

From my testing, using the uBlock Origin browser extension (with over 39 million users) led to a DataDog SDK initialization failure. Ad blockers and VPNs can interfere with RUM tracking by:

• Blocking requests to DataDog’s RUM endpoints (e.g., datadoghq.com).

• Preventing the RUM SDK from initializing in the browser.

• Hiding or altering IP addresses, reducing geolocation accuracy.

The necessity for implementing a work around here is subjective. We need to know how important this monitoring tool is, how many users are affected, and how difficult it is to implement a work around. If desired however, a few potential solutions can be considered:

1. If the RUM SDK fails to initialize, use a custom logging solution as a backup. For example, an API request to log the error message from the server.

2. Implement a script to check if RUM has successfully initialized. If it fails, log the failure internally or notify users with a non-intrusive message suggesting they whitelist the site.

Additional readings

Many of the content in this writing is a direct quote or summaries from the following resources:

• DataDog - Getting Started Documentation.

• DataDog Docs - RUM Browser Monitoring.

• DataDog Docs - Send RUM Custom Actions.

• YouTube - Introduction to RUM & Session Replay.

• YouTube - Real User Monitoring by DataDog.

Team work

The following highlights essential practices for building effective teamwork and collaboration.

• Create healthy conflict.

  • Azure DevOps comments per pull request review metric.

  • Jira comments per story.

• Promote innovation.

  • Contribute to lunch & learn opportunities.

  • Bi-weekly professional develompent time.

• Mentorship.

  • Meet with full-stack developer bi-weekly to teach frontend topics.

  • Meet with QA engineer bi-weekly to teach TypeScript and web concepts.

• Provide substantial feedback to the broader organization.

  • Push accessibility across all products.

  • Set automated frontend coding standard checks.

• Drive collaboration to decision making.

  • Leads design/architecture discussions.

  • Effectively create design diagrams: Excalidraw, markmap.

  • Hold and lead brainstorming sessions using the silent meeting approach.

  • Learn to create accurate and detailed sequence diagrams.

• Actively look for and address tech debt.

  • Jira metrics on tech debt stories created.

  • Jira metrics on tech debt stories completed.

• Become exceptional at problem diagnostics.

  • Debug distributed systems.

  • Automatically detect perform degradation.

  • Altering pipeline library/steps.

• Evangelize.

  • Document learnings into blogs.

  • Join hackathons/D3 events.

  • Attend local meet ups.

Learning

In order to grow as a full-stack developer, learning new technologies and gaining deeper understanding of technologies that I currently use will be key.

• Database Management.

  • RDBMS - Introduction to Relational Databases.

  • PGSQL - Learn PostgreSQL Tutorial.

  • Liquibase - Liquibase University.

  • DataGrip - DataGrip Overview.

  • DataDog - DataDog 101.

  • TSQL - TSQL Tutorial.

  • Other topics.

    • How to Profile SQL Queries for Better Performance.

    • Introduction to Profiling and Optimizing SQL Queries for Software Engineers.

    • Clustered vs non-clustered indexes.

• Object Oriented Programming.

  • SOLID - SOLID Principles: Introducing Software Architecture & Design.

  • LINQ - Learn C#: Lists and LINQ.

  • Design Patterns - Refactoring Guru.

  • CQRS - Clarified CQRS.

• Frontend.

  • React.

    • Meta - React Basics.

    • Meta - Advanced React.

    • Roadmap.sh - React.

  • Web accessibility.

    • Web Accessibility.

    • Meta - HTML and CSS in depth.

    • A11ycasts with Rob Dodson.

• Other topics.

  • Authentication - Introduction to Web Authentication.

  • JWT - What are JSON Web Tokens?

  • Character Encodings - Must Know About Unicode and Character Sets.

  • Time and Time Zones - Date and Time Fundamentals.

  • Storybook - A Beginner’s Guide to Storybook 7 with React.

  • Networking Concepts - Networking for DevOps – a Complete Guide.

  • Docker - Complete Docker Course.

  • Pen Testing - The Basics of Penetration Testing.

  • Documentation - Technical Writing.

Session Storage

Session storage is a browser storage only accessible through client-side JavaScript in which the data stored is automatically deleted when the user closes the browser tab or window.

Differences

• Expiration: On tab close

• Storage capacity: 5MB

• Accessibility: Current tab

Code example

sessionStorage.setItem("firstName", "John");
sessionStorage.setItem("lastName", "Doe");
sessionStorage.getItem("firstName"); // John
localStorage.removeItem("firstName");

Local Storage

Local storage is a browser storage only accessible through client-side JavaScript in which the data persists in the browser’s memory upon page refresh or window/tab close.

Differences

• Expiration: Never

• Storage capacity: 10MB

• Accessibility: Any window or tab with same origin

Code example

localStroage.setItem("firstName", "John");
localStroage.setItem("lastName", "Doe");
localStorage.getItem("firstName") // John
sessionStorage.removeItem("firstName");

Cookies

Cookies are another form of browser storage only accessible by the server and not by the client-side JavaScript. The data stored in cookies are persistent upon page refresh or window/tab close, until the expired date passes.

Differences

• Expiration: Manually set

• Storage capacity: 4KB

• Accessibility: Any window or tab with same origin

Code example

document.cookie = "firstName=John; expires=${new Date(2025, 0, 1).toUTCString()}"; // 01-01-2025
document.cookie = "lastName=Doe; expires=${new Date(9999, 0, 1).toUTCString()}"; // Never expires
document.cookie // firstName=John; lastName=Doe
document.cookie = "firstName=; expires=Thu, 01 Jan 1970 00:00:00 GMT"

The package can be installed and ran using the following commands:

npm install depcheck -g
yarn global add depcheck

depcheck

Or you can use npx (a package runner):

npx depcheck

One thing to note: be careful removing packages within the devDependencies list. Although the packages in this list is not installed with the --production flag, it is typically used for packages that are only needed for local development and testing.

Imagine having to go through each lint error and manually resolve them because the pull request pipeline failed with the message: ESLint found too many warnings. When you could’ve simply installed a few extensions in VSCode to automatically format the code changes to follow the specific coding standards that has been set.

From my research, there is no good linting or prettier plugins for formatting on save within Visual Studio. So for now, my solution is to recommend developers to open frontend files from VSCode - and there is a setting that helps us achieve this.

Once you open your repository in Visual Studio, locate file types you would like to always open with VSCode from the Solution Explorer. For my project, I selected 3 different file types: TypeScript (.ts), HTML (.html), and SCSS (.scss). For each file, right click and open the Open With... menu. From here, Add the VSCode executable, which is typically stored within the following path: C:\\Users\\{USER}\\AppData\\Local\\Programs\\Microsoft VS Code. Then use Set as Default button to open these file types in VSCode going forward.

This then takes in an object with property recommendations as a list of strings. Each string is the Extension ID which can be found by going to the “Extensions” tab, clicking on the settings icon, then “Copy Extension ID”.

{
    "recommendations": [
        "dbaeumer.vscode-eslint",
        "esbenp.prettier-vscode",
        "ecmel.vscode-html-css",
        "sibiraj-s.vscode-scss-formatter",
        "formulahendry.auto-rename-tag",
        "kamikillerto.vscode-colorize",
        "deque-systems.vscode-axe-linter",
        "streetsidesoftware.code-spell-checker",
        "aaron-bond.better-comments",
        "vincaslt.highlight-matching-tag",
        "oderwat.indent-rainbow",
        "christian-kohler.path-intellisense",
        "YoavBls.pretty-ts-errors"
    ]
}

Now, if any developers open the repository without all of the recommended repositories, a prompt automatically opens with the following action steps:

First, a leap from a junior developer to a senior developer makes up a long list of technical skills to differentiate yourself.

• Spend time learning security vulnerabilities and how to prevent them.

• Write readable, maintainable, and scalable code.

• Become a fire fighter. When urgent bugs are reported, remediate them efficiently.

• Deeply review code and provide useful feedback.

• Become proficient in researching new technologies and developing POCs (proof of concept).

• Come up with creative and clever solutions that can be used company wide.

• Create or refine coding standards and style guides.

• Understand different types of testing methods.

• Place testing rules and group testing meetings to production bugs.

• Learn how to run mob sessions and pair programming meetings effectively and efficiently.

• Have a strong understanding of the software architecture and the release process used by your team.

• Always know the pros and cons of the method/technology that your project is using. Never say, “That’s how it’s always been.”

• Contribute to the company wiki pages and write new documentations as needed.

• Be up to date on the latest technology news and trends. Subscribing to newsletters is a great way to achieve this.

• Mentor junior developers to provide them with resources and opportunities to improve. Learn to delegate your coding tasks.

• Communicate with stakeholders (keep in mind the technical limitations). Learn to estimate and avoid over-promising.

On top of these technical skills, you should also improve your personal skills.

• Become reliable, reachable, and consistent. Stay true to your word. Respond to messages in a timely manner.

• Be precise in your speech. Avoid misunderstanding between your teammates.

• Learn how to lead a meeting. Make sure that all opinions are heard.

• Learn how to share your opinion. Be open to receiving feedback.

• Learn to work in a fast-pace environment without distractions.

• Encourage others to do their best and provide support when they are struggling.

• Be optimistic and positive in meetings and try to add a smile.

Lastly, create a brag document to provide a comprehensive list of your contributions to show your manager when asking for a promotion. Best of luck!

Your request rate is too high. The AWS SDKs for DynamoDB automatically retry requests that receive this exception. Your request is eventually successful, unless your retry queue is too large to finish. Reduce the frequency of requests using Error retries and exponential backoff.

The cause for this issue was our autosave feature. On every user input (text input, radio buttons, checkboxes) change, we were triggering an API request to save the changes. Since our users were familiar with the user interface and clicked through the site quickly, we never caught this error during development and QA testing.

My solution, as always, was to look for how other products approach it. Looking at Hashnode, they have an autosave feature where the user changes text of the draft blog, and there’s a few second wait before the save is triggered. This way, save request isn’t on each keydown event, and instead is using a debounce mechanism to save when user stops typing.

To achieve this, I decided to create a new dependency injectable class: autosave service.

Definition of done

• An abstract service to allow different data type implementations.

• Autosave service should be dependency injectable by any component.

• Component can request a piece of data to save to the database on next timer tick.

• Component should have the ability to save immediately (ignoring the debounce mechanism).

• When the save request errors out, data should not be saved again until a new change is made.

• Status of the save should be visible to the component for user feedback.

• Frequency of the tick should be configurable.

Implementation

Let’s start by creating a status enum indicating when a request has been received, saving request but have not received response from API, save complete. This will be a public property that can be accessed by the component to display in the user interface.

export enum SaveStatus {
    UNSAVED = 'Unsaved changes',
    SAVING = 'Saving',
    SAVED = 'Changes saved',
    NULL = 'No changes'
}

As mentioned in the requirements, I wanted the class to be an abstract class meaning multiple services can be implemented with different kinds of data.

export abstract class AutosaveService<T> {
    /** Request object to save on the next trigger */
    protected dataToSave: T = null;
}

Using generics, the base class will take in a type that indicates the instances of the data that will be sent to the API.

To allow the child components to listen to the status change and display in the UI, we can use the [BehaviorSubject](<https://rxjs.dev/api/index/class/BehaviorSubject>) from RxJS.

/** Current status of the save */
protected status = new BehaviorSubject<SaveStatus>(SaveStatus.NULL);

/** Current status of the save */
status$ = this.status.asObservable();

In the same way, tracking errors will be important to prevent multiple requests of the same value.

/** Indicates error happened on last API call */
protected error = new BehaviorSubject<boolean>(false);

/** Indicates error happened on last API call */
error$ = this.error.asObservable();

Now, on to the fun part. We’ll need a way to start a timer when a request is first sent. When the timer goes off, an API request should be sent to save the data. The timer observable from RxJS is a perfect usecase for this.

It is important to note here that we account for when another request has been sent prior to the first timer completing. In this case, we will restart the timer and update the data object.

/** Observable for timer ticks */
private timer$: Observable<number>;

/** Subscription listening to latest timer */
private timerSubscription: Subscription;

/** Frequency of the timer tick in milliseconds */
private readonly tickFrequency = 5000;

constructor() {}

/** Calls API to save data */
abstract saveData(): Promise<void>;

/**
 * Requests service to save data on the next tick
 * @param request Data to save
 */
requestSave(request: T): void {
    this.timerSubscription?.unsubscribe();

    this.timer$ = timer(this.tickFrequency);
    this.dataToSave = request;
    this.error.next(false);
    this.status.next(SaveStatus.UNSAVED);

    this.listenToTimer();
}

/**
 * Triggers save on timer tick
 */
private listenToTimer(): void {
    this.timerSubscription = this.timer$.pipe(first()).subscribe(() => {
        const triggerSave = this.dataToSave && !this.error.getValue() && this.status.getValue() === SaveStatus.UNSAVED;
        if (triggerSave) {
            this.saveData();
        }
    });
}

Let’s add the ability to save immediately ignoring the timer. This will be useful when the user wants to manually save recent changes or when the user navigates away from the page before the changes are saved.

/**
 * Saves data at the moment of the request
 * @param request Data to save
 */
saveNow(request: T): Promise<void> {
    this.status.next(SaveStatus.UNSAVED);
    this.dataToSave = request;
    this.error.next(false);

    return this.saveData();
}

We also need an ability to clear the request after saving changes. This will be an easy way to clear the previous request after a successful save.

/**
 * Empties save request
 */
clearRequest(): void {
    this.status.next(SaveStatus.SAVED);
    this.dataToSave = null;
    this.error.next(false);
}

Boom! The abstract class is now complete!

To start using the autosave feature, create a brand new class with data type you wish to save. Then the saveData() method should be implemented to perform the API request.

export class AutosavePersonService extends AutosaveService<Person> {
    constructor(private apiService: ApiService) {
        super();
    }

    /**
     * Calls API to save person's data
     */
    saveData(): Promise<void> {
        return new Promise((resolve, reject) => {
            this.status.next(SaveStatus.SAVING);
            this.apiService
                .save(this.dataToSave)
                .then(() => {
                    this.clearRequest();
                    resolve();
                })
                .catch(() => {
                    this.status.next(SaveStatus.UNSAVED);
                    this.error.next(true);
                    reject();
                });
        });
    }
}

We are now ready to inject this class into any component you desire and autosave user input changes. Here is what that might look like:

@Component({
    selector: 'app-root',
    templateUrl: './app.component.html',
    styleUrls: ['./app.component.scss'],
})
export class AppComponent {
    /** Data on the person */
    person: Person;

    /** Status of the autosave request */  
    status = this.autosavePersonService.status$;

    constructor(private autosavePersonService: AutosavePersonService) {}

    /**
     * Fires save request to autosave service
     */
    savePerson() : void {
        this.autosavePersonService.requestSave(this.person);
    }

    /**
     * Immediately saves changes on person object
     */
    savePersonNow(): void {
        this.autosavePersonService.saveNow(this.person);
    }
}

Demo

I’ve created a CodeSandbox project with the entire code from this writing.

Resources

• TypeScript Generics

• RxJS Behavior Subject and tutorial

• RxJS Observable

• RxJS timer and tutorial

Problem

As full-stack developers tend to be backend developers with minimal frontend experience, our frontend project was barely functional.

One of the issues I found was that when running an instance locally, our builds were not failing on any TypeScript errors seen in the code editor.

For example, imagine a simply method that adds 2 numbers. As addition is a mathematical operation, both of the arguments are expecting a number type.

add(num1: number, num2: number): number {
    return num1 + num2;
}

add(1, 2);     // This is valid.
add('a', 'b'); // This is not valid.

With the above implementation, add('a', 'b'); should fail at compile time as string were passed in as parameters. However, in our codebase, the build completes without any errors or warnings, and the bug will only found at runtime.

This is a major problem as type checking is the whole point of using TypeScript. God only knows how many errors we have been ignoring. Our codebase is essentially all using JavaScript at this point.

Solution

With the almighty Google search, I found a commonly used npm package known as [fork-ts-checker-webpack-plugin](<https://www.npmjs.com/package/fork-ts-checker-webpack-plugin>). ****This is a webpack plugin which adds TypeScript’s type checking process then outputs the results in the command line.

To implement this plugin, first install the package: npm i fork-ts-checker-webpack-plugin.

Then, navigate to the project’s webpack.config.js file. Within the file, you will need to add an import line at the top, as well as an instance of the class to the plugins array:

const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');

module.exports = {
  plugins: [new ForkTsCheckerWebpackPlugin()],
  ...
};

Keep in mind that the ts-loader package is required for this plugin to work. Loader should look like the following:

module.exports = {
  context: __dirname,
  entry: './src/index.ts',
  resolve: {
    extensions: [".ts", ".tsx", ".js"],
  },
  module: {
    rules: [
      {
        test: /\\.tsx?$/,
        loader: 'ts-loader',
      }
    ]
  },
};

Voila! Now the terminal will display each and every TypeScript error! As a result, I was able to catch over 120 type errors in our codebase which I spent rest of the day resolving 😄

Thanks to this Stack Overflow thread for discussing this issue.

My local environment stopped working. The command to run and build an Aurelia project, a frontend web framework built by the original creator of Angular, mysteriously failed with the following error message:

error: Error: spawn EINVAL
  at ChildProcess.spawn (node:internal/child_process:421:11)
  at spawn (node:child_process:761:9)
  ...

The almighty Google search

Since none of the typical solutions like reinstalling dependencies or reverting back the recent changes worked, I searched on the internet for a solution.

Eventually, I came across a discussion forum from an open-source project called Node-RED. Node-RED is a low-code development tool for visual programming. The project maintainers had come across the same error message and they found that the recent security release from Node.js was the root cause.

Node.js codebase included a method in which “a malicious command line argument can inject arbitrary commands and achieve code execution even if the shell option is not enabled.” This impacted all Windows users in active release lines of 18.x, 20.x, and 21.x.

Since I am on Windows 11 using their latest 21.7.3, this was likely the issue. Node-RED maintainers were able to resolve this issue quickly by adding an option property of shell: true to the spawn() constructor argument.

The CLI repository

Looking at the Aurelia's CLI project on GitHub, I found a line referencing the exact spawn method without the shell option set.

However, the Aurelia develompent team has since moved to completely rewrite the project (Aurelia v2) so the repository has not been updated in 6 months.

Solutions (in order from worst to best)

Stop using Windows

This is not an option since I work for an organization with 99% of developers using Windows. However, good news is that our servers are all Linux; therefore, this error is only thrown during local development.

Downgrade Node.js

Downgrading the Node.js version to the latest LTS release will solve the problem for now. However, this is a temporary solution as more developers will run into this issue upon a Node.js update.

Additionally, since no one has yet reported this issue on their GitHub issues page, I opened a new thread explaining the issue I was having as well as the solution.

Contribute to the open-source project

Within a few hours of writing a thorough explanation of my findings, the maintainer of the project commented on the issue asking for me to create a pull request.

Up to this point, I’ve never contributed or even attempted to contribute to an open-source project. This was also an CLI project which I don’t have experience working on. Not only that, the project has over 400 stars and 5,000 weekly downloads on npm.

Despite the hesitation, my manager encouraged me to attempt making the change. He thought that it would be a great experience for me.

With a few minor roadblocks, I manged to push the code change and the package was released to npm a few days later. Installing the new version on my machine, our project started working again.

Throughout this journey, I learned how to think about open-source contribution. Within the developer community, it is commonly understood that contributing to open-source is how you can get a good job. However, I think we might have it backwards.

Contributing to open source doesn’t make you a good developer. Good developers contribute to open-source.

Managing Node.js versions properly

To this day, I'm not sure how my machine automatically updated the Node.js version but my speculation is Chocolatey, an optionally installed package manager upon installation of Node.js. However, my big take away is that I now have an approach to managing the versions intentionally:

• Decide on an LTS release to use everywhere (local and servers).

• Match your machine’s version with the production server.

• Subscribe to the Node.js blog and manually install any new releases to test your local environment. After confirming, downgrade to the LTS version. If the latest version fails one of your tools, search the repository online (typically on GitHub) and report the issue if there isn't one already.

• Manage these versions using nvm.

Grid is a new CSS layout module created to support a two-dimensional layout system.

How to use it

Define Container

To start using CSS Grid, create a div element within the HTML, then define that element to be a grid container within the CSS. This sets the elements inside of the container to be the child elements directly affected by the grid settings. Keep in mind that default configurations have already been set at this point.

<div class="container">
    <div>Box 1</div>
    <div>Box 2</div>
    <div>Box 3</div>
</div>

.container {
    display: grid;
}

Define Templates

Next, define columns and/or row templates. Columns lay the elements horizontally, and rows lay the elements vertically. These values are space-separated and represent the track (width, length) size of the child elements.

.container {
    grid-template-columns: none; /** Default */
    grid-template-rows: none; /** Default */

    grid-template-columns: auto 150px;
    grid-template-rows: auto min-content;
    grid-template-rows: auto 150px;
    grid-template-rows: 1fr 1fr;
    grid-template-rows: repeat(2, 1fr);
}

Here are examples of defining a template for columns.

These are some of the most commonly used size properties:

• fr unit represents a fraction of the available space in the grid container

• auto sets the size based on the content that is inside them

• {number}px defines a static size of the element

• repeat() notation can be used to repeat all of a section of the track listing

Here are example use cases for row templates.

Gaps

Now that you have the basic layouts, consider configuring gaps next. Gaps can be set at the row or column level, and they define the spaces between the child elements. The default value for both is 0.

.container {
    column-gap: 10px;
    row-gap: 10px;
}

Consider the following examples. The first example has 3 elements laid out horizontally (grid-template-columns). Notice that there are 10 pixels of space between the 1st and the 2nd element, as well as the 2nd and the 3rd element. These gaps are added between all of the child elements. In the second example, the elements are laid out vertically (grid-template-rows) and the gaps are set to 10 pixels by rows, as the vertical spaces between the 2 elements indicate.

Justifications

A couple more to go. Configuring justifications. This setting allows you to set the horizontal location of the child elements. Let's look at a common use case.

.container {
    justify-content: center;
}

As you can see below, the child element with 50 pixels width is set in the center of the container not taking any extra space.

Alignment

Almost done. Lastly, you can also configure alignments. This is very similar to justifications with a few differences. Alignments allow the vertical location of the child elements to be set. Let's try a common use case once again: center.

.container {
    align-items: center;
}

In the final example below, you can see that the height of the element is set at 50 pixels and the container is set to 200 pixels. Because of the align-items property, the child is centered in the container.

Explore

Now that you've learned the basics, try them out in your projects! As you test them locally, you can use Chrome DevTools to inspect and CSS Grid! Here is a guide to doing just that! Consider checking out some of the links below as well. Thanks for reading!

Learn more about Grid

• CSS Tricks - A Complete Guide to CSS Grid

• Mozilla - CSS Grid

Flexbox is a CSS layout module that provides an efficient way to dynamically layout, align and distribute space among items in a container.

How to use it

Define Container

To start using flexbox, create a div element within the HTML, then define that element to be a flex container within the CSS. This sets the elements inside of the container to be child elements affected by the flexbox settings. Keep in mind that default configurations have already been set at this point.

<div class="container">
    <div>Box 1</div>
    <div>Box 2</div>
    <div>Box 3</div>
</div>

.container {
    display: flex;
}

Direction

Next, configure the direction that you want the child elements to be layout: row or column.

.container {
    flex-direction: row; /** Default */
    flex-direction: column;
}

Here is an example of the 2 directions. Row (set by default) lays out the element horizontally, whereas column sets the element vertically.

Wrapping

Next up, configuring wrapping. By default, the child elements will all try to fit into one line. Changing this setting allows you to control what happens to the child elements in case of overflow.

.container {
    flex-wrap: nowrap; /** Default */
    flex-wrap: wrap;
}

Take a look at the examples below. No wrap (set by default) is squeezing all of the elements to be on the same line, whereas the wrap setting pushes them onto the next line.

Gaps

Now that you have understood the basic layouts, consider configuring gaps. Gaps can be set at the row or column level, and they define the spaces between the child elements. The default value for both is 0.

.container {
    column-gap: 10px;
    row-gap: 10px;
}

Consider the following examples. The first example has 3 elements laid out horizontally (flex-direction: row) and there are 10 pixels of spaces between the 1st and 2nd element, and 2nd and 3rd element. In the second example, the elements are laid out vertically (flex-direction: column) and the gaps are set to 10 pixels by rows, as the vertical spaces between each element indicate.

Justifications

A couple more to go. Configuring justifications. This setting allows you to set the horizontal location of the child elements. Let's look at 2 common use cases: center and space-between.

.container {
    justify-content: center;
    justify-content: space-between;
}

In the top example from the image below, you will see 1 element inside of a flexbox centered horizontally. This can also be achieved when more than one element exists within the container. In the bottom example, there are 2 elements spaced apart, hence the keyword space-between: one on the left, and the second on the right.

Alignment

Almost done. Lastly, you can also configure alignments. This is very similar to justifications with a few differences. Alignments allow the vertical location of the child elements to be set. Let's try using 2 commonly used keywords: center and stretch.

.container {
    align-items: center;
    align-items: stretch;
}

The first example is using the center keyword. As you can see, while the height of the container is set at 200 pixels, the element is laid out in the center of the vertical axis. In the second example, there are 2 elements in one row, but the height of both elements is "stretched" to fix the 200-pixel height of the container.

Explore

Now that you've learned the basics, try them out in your projects! As you test them locally, you can use Chrome DevTools to inspect and CSS Flexbox. Here is a guide to doing just that! Consider checking out some of the links below as well.

Learn more about Flexbox

• CSS Tricks - A Complete Guide to Flexbox

• Mozilla - CSS Flex

Before the review

Prior to diving in the code changes, gather information about the pull request:

• Read the pull request description. Hopefully the author has included the user story with its purpose and requirements, a list of code changes, and screenshots (if applicable).

• Brainstorm and assemble a list of potential bugs or security risks that could get introduced.

• Determine the depth in which you should review the code.

• Be aware of any relevant documentation that should be updated.

• Check your mindset. You are reviewing only for the good of the codebase and the team, not to show off your knowledge or start an unnecessary argument.

During the review

Now that you have all of the background information, dive into the content of the pull request:

• Validate that the author is targeting the correct branch (this will depend on how your team handles release branches).

• Review all changes to ensure that the code change fills the user story requirements. (This step should be completed prior to providing any feedback.)

• Be respectful and professional in your feedback. Remember it’s feedback, not criticism.

• Consider the overall quality of the code: readability, maintainability, and scalability.

• Identify any performance or security concerns.

• Ensure that the code change adheres to the project’s coding standards and best practices.

• Make sure that the new code is following the style guide set by the organization or team.

• For suggestions that does not require a change, add a resolved comment to make the author aware.

• If the pull request is large and/or complex, pull the branch and test locally.

• If further explanation/discussion is needed, ask the author to set up a meeting.

After the review

After the initial round of feedbacks, you will need to work with the author to complete the request:

• Consider pair programming if a large or major change is required.

• Be open to feedbacks, conflicting opinions, or questions/concerns from the author and be willing to make adjustments.

• Resolve conflicting opinions quickly that could prevent the pull request from completing.

• Review the updated code to ensure that the suggested changes have been implemented.