DEV Community: Khalil Stemmler

⚡ Add a GraphQL Server to a RESTful Express.js API in 2 Minutes

Khalil Stemmler — Thu, 09 Jan 2020 18:47:04 +0000

⚡ Add a GraphQL Server to a RESTful Express.js API in 2 Minutes

You can get a lot done in 2 minutes, like microwaving popcorn, sending a text message, eating a cupcake, and hooking up a GraphQL server.

Yup. If you have an old Express.js RESTful API lying around or you're interested in incrementally adopting GraphQL, we only need 2 minutes to hook it up with a fresh new GraphQL Server.

Ready? Set. Go!

Let's say that your server looked something like the following.

import express from 'express';
import { apiRouter } from './router';

const app = express();
const port = process.env.PORT || 5000;

// Existing routes for our Express.js app
app.use('/api/v1', apiRouter);

app.listen(port, () => console.log(`[App]: Listening on port ${port}`))

At the root of your project, npm install apollo-server-express as a dependency.

npm install apollo-server-express --save

Go to where your Express app is defined and import ApolloServer and gql from apollo-server-express.

import { ApolloServer, gql } from 'apollo-server-express'

Next, create an instance of an ApolloServer with the simplest possible GraphQL type definitions and resolvers.

const server = new ApolloServer({
  typeDefs: gql`
    type Query {
      hello: String
    }
  `,
  resolvers: {
    Query: {
      hello: () => 'Hello world!',
    },
  }
})

Lastly, use ApolloServer's applyMiddleware method to pass in our Express.js server.

server.applyMiddleware({ app })

Boom. That's it!

Your code should look something like this.

import express from 'express';
import { v1Router } from './api/v1';
import { ApolloServer, gql } from 'apollo-server-express'

const app = express();
const port = process.env.PORT || 5000;

const server = new ApolloServer({
  typeDefs: gql`
    type Query {
      hello: String
    }
  `,
  resolvers: {
    Query: {
      hello: () => 'Hello world!',
    },
  }
})

server.applyMiddleware({ app })

app.use('/api/v1', v1Router);

app.listen(port, () => {
  console.log(`[App]: Listening on port ${port}`)
})

If you navigate to localhost:5000/graphql, you should be able to see your GraphQL schema in the GraphQL playground.

Note: If you want to change the URL that the GraphQL endpoint sits at from /graphql to something else, you can pass in a path option to server.applyMiddleware() with the URL you want, like path: '/specialUrl'. Check out the docs for full API usage.

How simple was that? Is your popcorn finished? 😉

Summary

Here's what we did.

Install apollo-server-express
Create a new ApolloServer
Connect your GraphQL Server with server.applyMiddleware

I personally really love the fact that Apollo Server is non-intrusive and can be tacked on any project as an alternative way to communicate between services and applications.

Where to go from here

If you're new to Apollo and GraphQL, a great way to learn is to actually build something in real life. For that reason, I highly recommend checking out the Apollo Fullstack Tutorial (you can also learn in TypeScript now 🔥).

I'm Khalil Stemmler, a Developer Advocate at Apollo GraphQL. I teach advanced TypeScript, GraphQL, and Node.js best practices for large-scale applications. Feel free to ping me on Twitter if you need help with anything Apollo, TypeScript, or architecture-related. Cheers 🤠

How to Learn Software Design and Architecture [Roadmap]

Khalil Stemmler — Sun, 29 Sep 2019 18:08:51 +0000

This article is a summary of what I'm writing about in my newest project, solidbook.io - The Handbook to Software Design and Architecture with TypeScript. Check it out it you like this post.

It's crazy to me to consider the fact that Facebook was once an empty text file on someone's computer.

Lol.

This past year, I've been going hard in software design and architecture, Domain-Driven Design, and writing a book on it, and I wanted to take a moment to try to piece it together into something useful I could share with the community.

Here's my roadmap for how to learn software design and architecture.

I've broken it down into two artifacts: the stack and the map.

The Stack

Similar to the OSI Model in networking, each layer builds on top of the foundation of the previous one.

The Map

While I think the stack is good to see the bigger picture of how everything works together, the map is a little bit more detailed (and inspired by the web developer roadmap) and as a result, I think it's more useful.

It's pretty huge, and Dev.to won't let me upload the entire thing, so click here to fork the repo, read my detailed write-up and see the entire image.

I hope it's useful.

Cheers!

The Moment I Fell In Love With Coding

Khalil Stemmler — Tue, 07 May 2019 15:46:10 +0000

My moment was in 2013, the second year of university. I had recently gotten into glitch art and I was determined to figure out how to create my own tool.
It wasn't until I learned about abstract data structures and how to implement a queue and a stack that it clicked in as how to build my tool.

During an all-nighter at @kirk_danuco's apartment, I finally figured it out.

I was so high on excitement that my body wasn't convinced I had just spent an entire 24 hours awake.

It was at that moment that I truly fell in love with coding.

I still use this tool to this day! You can download it from my GitHub and try it out yourself.

Value Objects - DDD w/ TypeScript

Khalil Stemmler — Sun, 07 Apr 2019 17:59:19 +0000

Originally posted @ khalilstemmler.com

In Domain-Driven Design, Value Objects are one of the two primitive concepts that help us to create rich and encapsulated domain models.

The two concepts are Entities and Value Objects.

Value Objects are best understood by understanding how it's different from an Entity. Their main difference is in how we determine identity between two Value Objects and how we determine identity between two Entities.

Entity Identity

We use an Entity to model a domain concept when we care about the model's identity and being able to distinguish that identity from other instances of the model.

The way that we determine that identity helps us determine whether it's an Entity or a Value Object.

A common example is modeling a user.

In this example, we'd say that a User is an Entity because the way that we determine the difference between two different instances of a User is through it's Unique Identifier.

The Unique Identifier we use here is either a randomly-generated UUID or an auto-incremented SQL id that becomes a Primary Key that we can use for lookup from some persistence technology.

Value Objects

With Value Objects, we establish identity through the structural equality of two instances.

Structural Equality

Structural equality means that two objects have the same content. This is different from referential equality / identity which means that the two objects are the same.

To identify two Value Objects from each other, we look at the actual contents of the objects and compare based on that.

For example, there might be a Name property on the User Entity.

How can we tell if two Names are the same?

It's pretty much like comparing two strings, right?

"Nick Cave" === "Nick Cave" // true

"Kim Gordon" === "Nick Cave" // false

This is easy.

Our User could look like this:


interface IUser {
  readonly name: string
}

class User extends Entity<IUser> {
  public readonly name: string;

  constructor (props: IUser) {
    super(props);
    this.name = props.name;
  }
}

This is OK, but it could be better. Lemme ask a question:

What if we wanted to limit the length of a user's name. Let's say that it can be no longer than 100 characters, and it must be at least 2 characters.

A naive approach would be to write some validation logic before we create an instance of this User, maybe in a service.

class CreateUserService {
  public static createUser (name: string) : User{
    if (name === undefined || name === null || name.length <= 2 || name.length > 100) {
      throw new Error('User must be greater than 2 chars and less than 100.')
    } else {
      return new User(name)
    }
  }
}

This isn't ideal. What if we wanted to handle Editing a user's name?

class EditUserService {
  public static editUserName (user: User, name: string) : void {
    if (name === undefined || name === null || name.length <= 2 || name.length > 100) {
      throw new Error('User must be greater than 2 chars and less than 100.')
    } else {
      user.name = name;
      // save
    }
  }
}

This isn't really the right place to be doing this.
We've just repeated the same validation logic.

This is actually how a lot of projects start to spin out of scope. We end up putting too much domain logic and validation into the services, and the models themselves don't accurately encapsulate the domain logic.

We call this an Anemic Domain Model.

We introduce value object classes to encapsulate where validation should occur and to satisfy the invariants (validation & domain rules) of our models.

Value Objects

We had this before, a basic class for our User entity.

interface IUser {
  readonly name: string
}

class User extends Entity<IUser> {
  public readonly name: string;

  constructor (props: IUser) {
    super(props);
    this.name = props.name;
  }
}

If we were to create a class for the name property, we could co-locate all of the validation logic for a name in that class itself.

We will also make the constuctor private, and using a static factory method to execute the preconditions that must be satisfied in order to create a valid name using the constructor.

interface IName {
  value: string
}

class Name extends ValueObject<IName> {
  private constuctor (props: IName) {
    super(props);
  }

  public static create (name: string) : Name {
    if (name === undefined || name === null || name.length <= 2 || name.length > 100) {
      throw new Error('User must be greater than 2 chars and less than 100.')
    } else {
      return new User(name)
    }
  }
}

And then change the User class to require a IName instead of a string.

We'll also utilize a static factory method here as well.

interface IUser {
  readonly name: Name;
}

class User extends Entity<IUser> {
  public readonly name: Name;

  private constructor (props: IUser) {
    super(props);
    this.name = props.name;
  }

  public static create (props: IUser) {
    if (props.name === null || props.name === undefined) {
      throw new Error('Must provide a name for the user');
    } else {
      return new User(props);
    }
  }
}

Value Object class

Here's an example of a Value Object class.


import { shallowEqual } from "shallow-equal-object";

interface ValueObjectProps {
  [index: string]: any;
}

/**
 * @desc ValueObjects are objects that we determine their
 * equality through their structrual property.
 */

export abstract class ValueObject<T extends ValueObjectProps> {
  public readonly props: T;

  constructor (props: T) {
    this.props = Object.freeze(props);
  }

  public equals (vo?: ValueObject<T>) : boolean {
    if (vo === null || vo === undefined) {
      return false;
    }
    if (vo.props === undefined) {
      return false;
    }
    return shallowEqual(this.props, vo.props)
  }
}

Check out the equals method. Notice that we use shallowEquals in order to determine equality. This is one way to accomplish structural equality.

When it makes sense, subclasses of this Value Object base class can also be extended to include convenience methods like greaterThan(vo?: ValueObject<T>) or lessThan(vo?: ValueObject<T>). It wouldn't make sense in this example, but it might if we were talking about something like LoggingLevels or BusinessRatings.

In future articles, we'll talk about:

entity design
better error handling technique for object creation
moving anemic code out of services and into domain models
writing DTOs to create data contracts

This is part of the Domain-Driven Design with TypeScript series. If this was useful to you, let me know in the comments & subscribe to the newletter to get notified when new articles come out. Cheers!

Learn Enterprise TypeScript - Newsletter

When To Use TypeScript - A Detailed Guide Through Common Scenarios

Khalil Stemmler — Sat, 06 Apr 2019 20:11:16 +0000

Have you heard of that little programming language called TypeScript? You know, the one that Microsoft made? The one that's kinda blowing up?

Maybe you were like me, a true JavaScript purist. Why do I need TypeScript? I was doing just fine coding away with React and Node without types. Prop types and Joi validation have been treating me just nicely, thank you.

Maybe you caved and gave it a shot. Started playing with it. Maybe you hated it because it reminded you of Java. Maybe you got annoyed with how you couldn't be super productive right away.

These were some of my own initial sentiments when I first started with TypeScript.

I certainly didn't see the benefit... up until I started experiencing some really annoying stuff. Things like builds not failing when they should, buggy code and typos finding their way into production code somehow in addition to finding it increasingly challenging to express my designs in a really clean object-oriented way.

9 months later into using TypeScript, I've built new features in Angular apps for clients, I began compiling Univjobs's React / Redux front-end with TypeScript and ported all Univjobs' backend services to TypeScript from vanilla Node.js, refactoring mass amounts of code along the way.

In this article, we'll take a look at some of the most common scenarios and identify when it might be vital to use TypeScript, and when we could probably just do without it and stick to vanilla JS.

Why this discussion matters more than ever today

I've come to the very important conclusion that depending on your situation, context, project, skill level and other factors, that it's actually dangerous for your project to NOT be written using TypeScript today.

The front-end space, for one- is getting more and more complex. Certain features that were once considered bleeding-edge, are now very-much standard user exprience assumptions.

For example, it's almost always expected that your app is going to still work offline in some capacity; and when users ARE online, it's also usually expected that they're going to get real-time notifications without having to refresh the page.

These are some pretty steep (but definitely not unrealstic in 2019) demands.

Before we dive into different scenarios, we should actually talk about the three categories of really hard software problems to be solved.

3 Categories of Hard Software Problems

Generally speaking, there are 3. The first being building Performant System Problem, the second, the Embedded System Problem, and the third being the with Complex Domain Problem.

1. The Performant System Problem

Let's talk about Twitter.

Twitter is actually a really simple concept.

You sign up, you make tweets, you like other people's tweets and that's pretty much it.

If Twitter is that simple, why couldn't someone else do it?

It's apparent that the real challenge for Twitter is not actually so much as "what it does", but it's "how it's able to do what it does".

Twitter has the unique challenge of serving requests from approximately 500 million users every single day.

The hard problem that Twitter solves is actually a perfomance problem.

When the challenge is performance, whether we use a strictly typed language or not is less important.

2. The Embedded System Problem

An embedded system is a combination of computer hardware and software, with the purpose of enabling control over the mechanical or electrical aspects of a system.

Most systems we use today are built on a very complex layer of code that, if not initially written in, compiles down to C or C++ usually.

Coding in these languages is not for the faint of heart.

In C, there is no such thing as objects; and we as humans like objects because we can easily understand them. C is procedural and this makes the code that we have to write in this language more challenging to keep clean. These problems also require knowledge of the lower-level details.

C++ does make life a whole lot better because it has object orientation, but the challenge is still fundementally interacting with lower-level hardware details.

Because we don't really have that much of a choice on the languages we use for these problems, it's irrelevant to discuss TypeScript here.

3. The Complex Domain Problem

For some problems, that challenge is less about scaling in terms of handling more requests, but scaling in terms of the codebase's size.

Enterprise companies have complex real-life problems to be solved. In these companies, the biggest engineering challenges are usually:

Being able to logically (domains) separate parts of that monolith into smaller apps. And then, physically (microservices for bounded contexts) splitting them up so that teams can be assigned to maintain them
Handling integration and synchronization between these apps
Modeling the domain concepts and actually solving the problems of the domain
Creating a ubiquitous (all encompassing) language to be shared by developers and domain experts
Not getting lost in the mass amounts of code written and slowing down to the point where it becomes impossible to add new features without breaking existing ones

I've essentially described the types of problems that Domain Driven Design solves. For these types of projects, you wouldn't even think about not using a strictly-typed language like TypeScript.

Object-oriented JavaScript

For Complex Domain problems, if you don't choose TypeScript and instead, choose JavaScript, it will require some extra effort to be successful. Not only will you have to be extra comfortable with your object modeling abilities in vanilla JavaScript, but you'll also have to know how to utilize the 4 principles of object-oriented programming (encapsulation, abstraction, inheritance, and polymorphism).

This can be hard to do. JavaScript doesn't naturally come with concepts of interfaces and abstract classes.

"Interface Segregation" from the SOLID design principles isn't easily achievable with vanilla JavaScript

Using JavaScript alone would also require a certain level of discipline as a developer in order to keep the code clean, and this is vital once the codebase is sufficiently large. You're also left to ensure that your team shares the same discipline, experience and knowledge level on how to implement common design patterns in JavaScript. If not, you'll need to guide them.

In Domain-Driven projects like this, the strong benefit from using a strictly typed language is less about expressing what can be done, but more about using encapsulation and information hiding to reduce the surface area of bugs by limiting what domain objects are actually allowed to do.

We can live without this on the front-end, but it's a hard language requirement for the backend in my books. It's also the reason why I moved my Node.js backend services to TypeScript.

There's a reason why TypeScript is called "JavaScript that scales".

Out of all three categories of hard software problems, only the Complex Domain Problem is the one where TypeScript is an absolute necessity.

Besides this, there are other factors that might determine when it's best to use TypeScript for your JavaScript project.

Code size

Code size usually ties back to the Complex Domain Problem, where a large codebase means a complex domain, but that's not always the case.

When the amount of code a project has gets to a certain size, it becomes harder to keep track of everything that exists, and becomes easier to end up re-implementing something already coded.

Duplication is the enemy to well-designed and stable software.

This is especially heightened when new developers start coding on an already large codebase.

Visual Studio Code's autocompletion and Intellisense helps to navigate through huge projects. It works really well with TypeScript, but it's somewhat limited with JavaScript.

For projects that I know will stay simple and small, or if I know that it will be thrown away eventually, I would be less pressed to recommend TypeScript as a necessity.

Production software vs. pet projects

Production software is code that you care about, or code that you'll get in trouble for if it doesn't work. It's also code that you've written tests for. The general rule of thumb is that if you care about the code, you need to have unit tests for it.

If you don't care, don't have tests.

Pet projects are self-explanatory. Do whatever you like. You have no professional commitment to uphold any standards of craftsmanship whatsoever.

Go on and make things! Make small things, make big things.

Maybe someday you'll experience the pain when your pet project turns into your main project which turns into production software, which is buggy because it didn't have tests or types 🙃 not like I've been there or anything...

Lack of Unit Tests

It's not always possible to have tests for everything, because, well- life.

In that case, I'd say that if you don't have Unit Tests, the next best thing you could have is compile-time checking with TypeScript. After that, if you're using React, the next best is thing is to use runtime checking with Prop types.

However, compile time checking is not a subsitute for having unit tests. The good thing is that unit tests can be written in any language- so the argument for TypeScript here is irrelevant. What's important is that tests are written and we are confident about our code.

Startups

Definitely use whatever helps you be most productive.

At this time, the language you choose matters a lot less.

The most important thing for you to do is to validate your product.

Choosing a language (Java, for example) or a tool (like Kubernetes) that you heard would help you scale in the future, while being totally unfamiliar with it and needing to spend time learning, may or may not be the best option in the case of a startup.

Depending on how early you are, the most important thing for you to do is to be productive.

In Paul Graham's famous article, The Python Paradox, his main point is that startup engineers should just use the technology that maximizes their productivity.

Overall, in this case, use whatever you're most comfortable with: types or no types. You can always refactor towards a better design once you know you've built something people actually want.

Working on Teams

Depending on the size of your team and the frameworks you're using, using TypeScript might be a make or break kind-of thing.

Large teams

When teams are sufficiently large (because the problems are sufficiently large), it's a good reason to use an opinionated framework, like Angular for the front-end, and TypeScript for the backend.

The reason why using an opinionated framework is benefitial is because you limit the number of possible ways for people to accomplish something. In Angular, there's pretty much one main way to add a Route Guard, use Dependency Injection, hook up Routing, Lazy-Loading and Reactive Forms.

The huge benefit here is that the API is well specified.

With TypeScript, we save massive amounts of time and make communication efficient.

The ability to quickly determine the required arguments and it's return type for any method, or the ability to explicitly describe program intent through public, private, and protected variables alone is incredibly useful.

Yes, some of this is possible with JavaScript, but it's hacky.

Communicating patterns & implementing design principles

Not only that, but design patterns, the solutions to commonly occuring problems in software, are more easily communicated through explicit strictly-typed languages.

Here's a JavaScript example of a common pattern. See if you can identify what it is.


class AudioDevice {
  constructor () {
    this.isPlaying = false;
    this.currentTrack = null;
  }

  play (track) {
    this.currentTrack = track;
    this.isPlaying = true;
    this.handlePlayCurrentAudioTrack();
  }

  handlePlayCurrentAudioTrack () {
    throw new Error(`Subclasss responsibility error`)
  }
}

class Boombox extends AudioDevice {
  constructor () {
    super()
  }

  handlePlayCurrentAudioTrack () {
    // Play through the boombox speakers
  }
}

class IPod extends AudioDevice {
  constructor () {
    super()
  }

  handlePlayCurrentAudioTrack () {
    // Ensure headphones are plugged in
    // Play through the ipod
  }
}

const AudioDeviceType = {
  Boombox: 'Boombox',
  IPod: 'Ipod'
}

const AudioDeviceFactory = {
  create: (deviceType) => {
    switch (deviceType) {
      case AudioDeviceType.Boombox:
        return new Boombox();
      case AudioDeviceType.IPod:
        return new IPod();
      default:
        return null;
    }
  } 
}

const boombox = AudioDeviceFactory
  .create(AudioDeviceType.Boombox);

const ipod = AudioDeviceFactory
  .create(AudioDeviceType.IPod);

If you guessed Abstract Factory Pattern, you're right. Depending on your familiarity with the pattern, it might not have been that obvious to you.

Let's look at it in TypeScript now. Look at how much more intent we can signify about AudioDevice in TypeScript.


abstract class AudioDevice {
  protected isPlaying: boolean = false;
  protected currentTrack: ITrack = null;

  constructor () {
  }

  play (track: ITrack) : void {
    this.currentTrack = track;
    this.isPlaying = true;
    this.handlePlayCurrentAudioTrack();
  }

  abstract handlePlayCurrentAudioTrack () : void;
}

Immediate improvements

We know the class is abstract right away. We needed to sniff around in the JavaScript example.
AudioDevice can be instantiated in the JavaScript example. This is bad, we intended AudioDevice to be an abstract class. And abstract classes shouldn't be able to be instantiated, they're only meant to be subclassed and implemented by concrete classes. This limitation is set in place correctly in the TypeScript example.
We've signaled the scope of the variables.
In this example, currentTrack refers to an interface. As per the Dependency Inversion design principle, we should always depend on abstractions, not concretions. This isn't possible in the JavaScript implementation.
We've also signaled that any subclasses of AudioDevice will need to implement the handlePlayCurrentAudioTrack themselves. In the JavaScript example, we exposed the possibility for someone to introduce runtime errors trying to execute the method from either the illegal abstract class or the non-complete concrete class implementation.

Takeaway: If you work on a large team and you need to minimize the potential ways someone could misuse your code, TypeScript is a good way to help fix that.

Smaller teams & coding styles

Smaller teams are a lot easier to manage coding styles and communication. Paired with linting tools, frequent discussions about how things will get done and pre-commit hooks, I think small teams can be really successful without TypeScript.

I think that success is an equation involving the size of the codebase and the size of the team.

As the codebase grows, the team might find that they need to rely on some help from the language itself to remember where things are and how they should be.

As the team grows, they might find they need more rules and restrictions to keep the style consistent and prevent duplicate code.

Frameworks

React & Angular

Much of what draws me and other developers to React is the ability to write code however you want and in an elegant/clever way.

It's true that React makes you a better JavaScript developer because it forces you to approach problems differently, it forces you to be aware of how this binding in JavaScript works and enables you to compose large components out of small ones.

React also allows you to have a bit of your own style. And because of the number of ways I can implement any given task, I will most often write vanilla React.js apps when:

the codebase is small
it's just me coding it

And I will compile it with TypeScript when:

more than 3 people are coding it, or
the codebase is expected to be very large

I will also optionally use Angular for the same reason I will compile React with TypeScript.

Conclusion

In conclusion, these are my personal opinions on when TypeScript is absolutely necessary and I welcome you to disagree with any of it.

This is what has worked for me in the past when deciding whether to use TypeScript. However, today- since I've seen the light, it's not much more effort for me to use TypeScript over vanilla JavaScript as I'm equally comfortable with both and would prefer the type safety.

My final points here are:

You can always gradually start using TypeScript

Start gradually by adding TypeScript and ts-node to your package.json and utilizing the allowjs: true, option in your tsconfig file.

This is how I migrated all of my Node.js apps over time to TypeScript.

Compile time errors are better than runtime ones

You can't argue with that. If catching bugs in production code is especially important to you, TypeScript will help you minimize a lot of these.

If you are in a position to learn it, learn it. It does wonders for your software design skills

Depending on where you are in your life and your career, you might not have the time to learn it. If you do have the time, I'd recommend you start learning it and start learning about SOLID design principles and software design patterns. This is the fastest way to level up as a Junior Developer in my honest opinion.

I hope this article was useful to you! Are you considering using TypeScript on your next project? Let me know if you agree/disagree in the comments.

Learn Advanced Node.js & TypeScript with Khalil

Essential software development patterns, principles, and tutorials with modern JavaScript and TypeScript.

9 Books For Junior Developers In 2019

Khalil Stemmler — Wed, 13 Mar 2019 12:54:39 +0000

Whether you’re a new developer or you’re fairly experienced as a programmer, you’ll come to realize that the amount of time you’ve worked at a job isn’t the best way to determine your skill and knowledge as a programmer (I know, tell that to the recruiters 🤫).

What you do in your spare time and how you choose to take learning into your own hands is what’s going to ultimately determine your success in this industry. That’s why it’s so important for us as developers to adopt a growth mindset.

There are some excellent ways to learn and improve as a developer. Some of those ways are pair-programming, online courses, meetups, work experience, building projects and finding a mentor.

One of my personal favourite ways to learn is to crack open a well-written book and try to absorb something from those who have distilled years of knowledge and insight into a permanent artifact.

Here are my personal recommendations that I think all developers (especially junior ones) should read at some point. These books are all highly regarded by professionals in our industry and have the potential to leave a profound impact on the quality of your work and your speed of development & learning. Some of them stray from the technical details and focus more on giving you practical rules about what it means to be a good developer; on the interpersonal and professional level.

1. Clean Code

by Robert C. Martin (Uncle Bob)

After you overcome the basic challenges of development and get comfortable figuring out how to write code to solve problems, it’d be a good idea to take a read of this book. It turns out that making the code work the first time is actually the easy part. The hard part is making your code read well so that others are able to understand it and change it in the future.

Remember the last time you had to read code like this?

function calculateIt (a, b) {
 if (a.delta < b.element.x) {
   var x = b.element.x;
   return x - b.delta.x
 } else {
   var y = b.next.y;
   var h = b.element.y * 2;
   return y - h
 }
}

Who knows what it really does. Code like this might work… but the moment we need to change it, we have to hope the author of the code is still in the company- and pray that he’s somehow able to decipher what he wrote potentially years ago.

When careful attention isn’t taken to write code that’s readable and maintainable, we end up with pockets of code like this that everyone is afraid to touch, and if it ever breaks- we’re in trouble.

Uncle Bob’s “Clean Code” teaches you how to identify what clean code looks like compared to bad code, and it teaches you how to transform it into good code. A task like this sounds trivial to most, but you’d be surprised at how turning a just a few clean software design principles into habits can help you write much more professional and scalable code.

We’re software craftsmen, you know. Building a house is not much different than building an application in principle. We need to pay attention to the details or else it can all become very expensive to fix in the future if not done right first time.

2. The Clean Coder

by Robert C. Martin (Uncle Bob)

This book is not necessarily a technical book as it is a book for teaching you how to be a professional in this industry. Professionals are those who: when faced with challenges, uncertainty and pressure, will continue to treat creating software as a craft and will be unswerved to adhering to their professional values.

The Clean Coder is full of practical advice on estimation, refactoring, testing, dealing with conflict, schedules, avoiding burnout, and much more. Trusted advice from someone who has spent decades doing this stuff.

One of the best things it teaches is how to have integrity as a developer, when to say “No” and how to say it.

A book about professionalism.

3. Refactoring

by Martin Fowler

Martin Fowler is one of my favourite authors. The first reason is that he’s hilarious. His approach to writing software books is unmistakably “Fowler”. The other reason is that he's incredibly good at explaining complex topics, and doing so very simply- in a way that doesn’t fatigue you as a reader.

Refactoring is a book that the creator of Ruby on Rails once said that you should “read before you write another line of code”. Fowler guides you through refactoring a simple application, introducing you to a number of techniques that he’s accumulated and cataloged over his years of consulting.

Fowler shows you how to flip between coding and refactoring, how often you should be committing your code and when you should be writing your tests. Highly recommended. The latest version of this book was updated to present the examples in JavaScript, which was an added plus for me since it's my favourite language.

4. Design Patterns: Elements of Reusable Object-Oriented Software

by Erich Gamma, Richard Helm, Ralph Johnson, & John Vlissides

This is the seminal book on Design Patterns (and also the name of a damn good post-punk band). What are design patterns, you ask? Design Patterns are well-known solutions to commonly occurring problems in software development. If you’re familiar with the patterns, you’ll find that you’ll be able to greatly reduce the amount of time it takes you to put forth the solutions to those problems.
Having good awareness of design patterns also allows you to communicate your solutions effectively with other developers.

“Yeah, I just used a Facade overtop of whichever database Adapter gets loaded from the Strategy.”

“Ahh! Gotcha.”

Yeah, it’s an older book. But it’s still one of the best for reference. If you’d like something on this topic that’s a bit more recent and friendly, I’d also recommend the good “Head First Design Patterns: A Brain-Friendly Guide” by Eric Freeman.

5. Domain-Driven Design: Tackling Complexity in the Heart of Software

by Eric Evans

In order for large codebases to continue to scale, we need to logically split up code into different parts. The idea is to partition your code in a way such that it would be possible for separate teams to work on those parts of your system without affecting anyone else.

The underlying concept that enables moving your codebase in this direction is Domain-Driven Design. It’s an approach to software development where we model the problems that exist in the “problem domain” (the real world) to a number of solution domains.

DDD is incredibly important when a codebase gets sufficiently large. Large enterprise companies employ DDD in order to assign teams to parts of the company’s codebase.

Taken from Vladimir Khorikov's course on "Refactoring an Anemic Domain Model to a Rich One"

Eric Evan’s coined the term “Ubiquitous Language”, which is the term for building a common, all-encompassing language between the developers, the domain experts and any other users or actors in the domain. By using this Ubiquitous Language, it ensures that the most important domain concepts are well understood and get modeled in the software.

The book is a little more technical and challenging than the others, but if you get familiar with these concepts, you’ll be very well off in understanding how today’s largest companies keep their codebases manageable and scalable.

6. Soft Skills: The Software Developer's Life Manual

by John Sonmez

We should strive to stay well-balanced as a software developer. Unfortunately, being well-balanced is not a trait that most people affiliate with software developers. The truth is, it’s incredibly important to invest in your learning, health and overall well-being as a developer.

Soft skills is about the important stuff that matters outside of actually coding, like productivity, career goals and personal finance. Sonmez also goes into investing, how he retired at 33, fitness hacking tips and maintaining relationships- things rarely addressed in the programming community.

It’s written in such a way that you can jump into the book at whichever chapter you think is most relevant to you today.

7. Clean Architecture

by Robert C. Martin (Uncle Bob)

What? Uncle Bob writes good books, ok?

In school, there’s a lot of focus on algorithms and less focus on software design principles. I think it’s kind of unfortunate because in reality, you don’t encounter that many algorithm challenges too often. Instead, it’s more common that you’ll be faced with the challenge of structuring your code in a way that’s modular, flexible, readable and will allow you to add new features quickly when requirements change.

Clean Architecture is about the essential software design principles and patterns that you’ll be able to use in order to face these challenges.

Some of the best takeaways from this book are the cost of dependencies, stable vs. non-stable code and the SOLID principles: a way to write code so that it’s more understandable, flexible and maintainable.

Other aspects of this book that were incredibly useful were concepts of “screaming architecture” and “packaging by component” which are opinions on how to organize your modules so that it practically screams to the reader exactly what the project is all about.

This book goes well hand-in-hand with Domain-Driven Design, which is enabled through the use of a “Layered Architecture” or as Uncle Bob calls it, “The Clean Architecture” (also known as Ports and Adapters). A great book for anyone who wants to up their architecture chops and learn how to effectively design a system at a high level, and do the dance of dependencies at the detail level.

8. The Effective Engineer

by Edmond Lau

Time is our single most valuable asset in life, and we should aim to be more efficient with it. It’s easy to get bogged down and spend a lot of time fixing bugs and wasting effort. Doing repeated work. Bleh. The Effective Engineer is all about getting more done in less time and removing repeated work.

We can mitigate wasted time and effort on repetitive tasks through a framework called “leverage”.

Leverage helps you identify the activities that you can do that produce the most disproportionate results- per unit of time invested. It’s a framework that can apply to anything, whether that be how you learn, how you code, how you debug... anything!

9. The Pragmatic Programmer

by Andrew Hunt & David Thomas

Praised for being easy to follow and understand, The Pragmatic Programmer is a book that should be on the desktop of developers of all levels. Andrew and David are programmers that not only spent many years doing what they do, but paying attention to what they were doing as they were doing it- and then trying to determine if they could do that better.

What came out of their years of introspection was this book, which introduces a number of essential programmer philosophies to follow throughout your career, like “programmers should have a "do it once, or automate" philosophy”.

It includes simple yet detailed advice that you should carry with you in the back of your mind before you write another line of code or start a new project.

Final words

Books really are some of the best tools to improve your knowledge and skills as a new programmer or Junior Developer. Books tend to have a really high return on investment; did you know you can make a lot of money programming? 😉

These are just a few of the best books out there right now in 2019! None of them are really new, but that’s because programming has maintained the same general philosophies and best practices for years. As a prof I once had used to say, “you can make a lot of money in this industry, you just have to read the damn manual”.

Have you read any of these books? What did you think? Any books not on this list that you think newer developers would really benefit from reading? Let us know in the comments!

Additional Resources

Here’s a list of some really excellent articles that cover some of the topics from these books. If you don’t quite have the time to invest in fully blown books right now, familiarizing yourself with these concepts might assist you in your journey to become a better developer!

Refactoring.guru

SOLID Design Principles

DRY (Don’t Repeat Yourself)

NodeJS and Good Practices

Implementing the SOLID and the onion architecture in Node.js

Better Software Design with Clean Architecture

The Clean Architecture

Keep growing, and have fun while you’re at it!

If you’re a Canadian student or recent-grad looking for entry-level developer opportunities or co-ops/internships, you should check out our platform, Univjobs. We only post jobs specifically for students and recent grads.