DEV Community: Jan Hoogeveen

Refactoring web applications

Jan Hoogeveen — Sat, 14 Dec 2019 12:44:33 +0000

Does this sound familiar?

You've started this great new project and have been hammering out new features at a great pace. Lately your velocity has dropped. It was only a minor decrease in the beginning, but it's becoming a severe slowdown now. Now you're at a point where you feel that you're having to defend yourself to stakeholders on why it's taking so long to deliver new features.

You're probably dealing with something that's called tech debt. Tech debt is the accumulation of technological decisions that favor short-term velocity over long-term maintenance. It's the result of making choices that made you look good at the start of the project by cutting corners, but it's slowly becoming a more serious problem now that your project has matured.

Just like financial debt in the real world, it's better to pay off your debt before it accumulates in even more debt.

When working in software development, paying off your (tech) debt is called refactoring. During refactoring, you take existing code and change it in such a way that results in more maintainable, readable code. One important condition is that the external behavior of the code stays the same. In the case of this example, that means our features still perform the same pieces of functionality as before.

Note: Some people might tell you that "refactoring is only for people who write bad code in the first place". Please, ignore those people! It's simply not true. There's plenty of reasons why tech debt is introduced in a project, and I'd argue the most important one is agile development.

While working agile, you're dealing with constantly evolving requirements. You're building working software, releasing it to the world and based on feedback from going to production you'll re-iterate again. This, by definition, makes it impossible to design a scaleable, maintainable solution from the start.

An encompassing overview, which you'd need to make all the right choices from the start, of the product will only be possibly by the time that a substantial amount of time and energy has already been invested in the project already. Only by the time that the product contains a decent amount of consumer facing features will you be able to fully understand the results of your initial choices.

Approaching the refactor

Refactoring can sound like a daunting task. It can involve changing critical parts of your application in an all-or-nothing approach. That's why you have to treat it just like any other enormous issue in an agile project. Consider "refactoring" as an epic and break it up in tons of smaller stories. The goal is for every story to reduce tech debt, piece by piece.

Accept refactoring as a recurring part of your sprint cycle.

Steps to refactoring

Create a list of annoyances/items that you want to solve. Involve the whole development team in these discussions. Do not let designers or product owners join these discussions. The idea is that developers can figure out on their own which parts of the codebase are blocking their progress the most. Let them own both the problem of tech debt, but more importantly the solution to these problems. Nothing is more empowering than knowing you can solve problems on your own.
When doing sprint refinement, go over the refactoring list and discuss in broad strokes how you want to solve this issue.
Deprecate methods or options. Use JSDoc to document which methods/classes you're deprecating and why. This helps with tools like IntelliSense. Also write down which alternative methods should be used instead, so developers will know what to do when confronted with the deprecation warning.
Ensure you have a solid set of tests written for your deprecated methods, so you know when refactoring everything still works.
Write a replacement method and apply it to at least one place of your codebase. When everything works as expected, refine the API. Take a step back. What annoyed you about the previous solution, and did you solve what you set out to do? If you're happy with the new API, write and/or port tests.
Replace all other instances of the deprecated message too. Update tests/mocks where needed.
Rinse and repeat.

Another way to get the message across is to use console.log to provide information to developers while they are in development mode. Take care not to ship this to production, as it can look unprofessional. For our React projects we've created a small utility hook called useDeprecationMessage that checks if you're running in development mode,

import { useEffect } from 'react'

function useDeprecationMessage(message, group = 'No group specified') {
  useEffect(() => {
    if (process.env.NODE_ENV === 'development') {
      console.groupCollapsed(`Deprecation warning: ${group}`)
      console.trace(message)
      console.groupEnd()
    }
  }, [message])
}

How to whitelist your Next.js serverless deployments on Now

Jan Hoogeveen — Fri, 22 Feb 2019 19:56:19 +0000

Originally published on janhoogeveen.eu

I like Next.js. It allows me to build rich data-driven web applications in React that are generated server-side. What I don't like is setting up servers and installing process managers to run node applications for my development and staging servers. To solve this, the clever people at Zeit have developed Now, a serverless platform where you can deploy your web applications with ease. I'd love to use it more, but right now I only see it being a valid choice for production environments.

One simple requirement from my side is that I want to shield my web applications from the public world while I'm still working on it. Unfortunately, that's something Now.sh is not facilitating.

The way Now handles security, is by prefixing your project name with a random unique identifier. For instance, if your project is named my-hidden-project, you can access your deployment on a url like http://my-hidden-project-**kdoe2jfh2**.now.sh

"The UID is derived from a large cryptographically random number encoded as 9 alphanumeric characters. However, if you want additional privacy, you can also replace the .now.sh suffix with any custom domain of your choice, making the URL 100% unguessable, so that not even the very existence of the deployment can be verified by third parties."

This sounds like security through obscurity to me. That's simply not good enough. I want to be 100% certain that I can deploy a web application and that it's only viewable by me or my team members, even if it has a predictable URL.

I've googled around but I could not find a solution to this problem. So, here's my hacky solution to this serious problem which I hope gets solved in a native way soon.

Checking for visitor IP address in your Now Lambdas

When running a Next.js project with a serverless target in the Next.js Builder (@now/next), it passes the request and response objects, or IncomingMessage and ServerResponse as the docs call them to your lambdas. It also passes these arguments to the getInitialProps method, which is always executed on the server before the server returns any DOM representation at all.

Here's a barebone example of disallowing everyone to visit your page.

Example:

const Page = props => {
  return <div>Welcome to next.js!</div>
}
Page.getInitialProps = async ({ req, res }) => {
  res.statusCode = 403
  res.end(`Not allowed`)
}

export default Page

Go ahead and try that out. It's not very useful yet, but it proves you can exit your render early and return a 403 response to the browser. From here, it's a matter of expanding on the example to your liking.

Here's an enhanced version that disallows everyone by default, and whitelists a few IP addresses.

const Page = props => {
  return <div>Welcome to next.js! Your IP address is: {props.ip}</div>
}
Page.getInitialProps = async ({ req, res }) => {
  // Disallow access by default
  let shouldDisallowAccess = true

  // Specify IP's that you want to whitelist. This could be an office/VPN IP address.
  const allowedIps = ['192.168.100.100', '192.168.100.101']

  // Read the request objects headers to find our who's trying to access this page
  var ip = req.headers['x-forwarded-for'] || req.connection.remoteAddress

  // This if statement is only valid if the app is deployed through Now. It gets ignored on other environments.
  if (process.env.NOW_REGION) {
    // Check if the visitors IP address is allowed
    if (!allowedIps.includes(ip)) {
      shouldDisallowAccess = false
    }
  }

  // Return the 403 status code
  if (shouldDisallowAccess) {
    res.statusCode = 403
    res.end(`Not allowed for ${ip}`)
    return
  }
  // This object gets injected into the Pages props, if you want to use them
  return { shouldDisallowAccess, ip }
}

export default Page

Alternative solutions

If you don't want to use lambdas, it should be possible to use the Next.js middleware and wrap it in your own server. I haven't tried it yet, but I imagine it would be easy to add basic authentication for disallowd IP addresses with this solution.
If you have control over your own custom domain, it should be possible to point it to Cloudflares DNS servers, and use their firewall to only allow access from specific IP addresses or even IP ranges. That way it should be possible to have a single source of truth of protection - for all projects under that domain - without having to call the getInitialProps method on every page. Of course you lose the benefits of letting Now manage your domain, but do you really need that for your development servers?