DEV Community: gaffleck

Developer Super Powers

gaffleck — Tue, 07 Feb 2023 01:09:54 +0000

Are you a software developer? Do you want to be a super hero? Read on....

Over my 20+ years in the industry I've had the privilege to work with many talented software developers. While every individual is unique and every job requires a different set of skills and capabilities to exceed. I've noticed some common traits that the people who absolute crush it have in common. Here they are:

Focus

Like make kinds of knowledge work, writing great software requires the ability to block our distractions (both external and internal) and focus deeply on a single task. Maybe of the rockstars that I've worked with have developed tangible rituals and queues that help them to redirect their mental energy towards a task. For example, putting on headphones, adjusting keyboard, closing other browser windows and writing down on paper the immediate task. In today's world of social media, smart phones and (formerly) open plan workspaces, focus is a rare commodity. Learn to focus your mental energy.

Humility

Ironically, the loudest and most boastful team members are rarely the ones doing the best work. Great developers are always learning and in order to learn, you must recognize the limitations of your own knowledge. Everyone and every experience can teach you something and a career the person who learns constantly will emerge victorious. Humble people are more likely to learn from their peers and build strong relationships. Stay Humble.

Communication

Knowledge work is rarely a solo-sport. In almost all cases, work happens in teams and the team can only work as well as the communication within it. The ability to communicate complex ideas simply, to listen well and ask thoughtful questions is critical to cohesive and capable teams. For the introverts among us, don't despair, 90% of this is about listening, questioning and communication in small groups or in writing over communication platforms and documentation systems. Listen, reflect, discuss.

Drive

Work ethic will beat out talent over the long run. The best developers I've worked with are driven innately to see the projects and products they work on succeed. This motivation is intrinsic, and comes from genuine interest and the reward that comes from seeing something that you built work the way it was designed. If you find yourself lacking this, reflect on why and make the necessary changes if you can. Maybe you're burned out, your goals are misaligned with your current role or maybe your motivation is misplaced.

Learning

The first 4 skills are pillars of the last, which is learning. Learning requires the humility to recognize the universe of things that you haven't mastered yet, the focus to study them deeply, the communication skills to accelerate your learning by benefiting from the knowledge of others and the dedication to do these things every day. At the end of the day, what makes a superstar is the ability to learn at a rate far above the average. This super power isn't obvious after 1 day on the job or even 1 year. But over time the person who learns the most will rise to the top.

A question I love to ask in interviews is: What is something that you're learning right now. Then an immediate follow up: tell me what you've done in the last 30 days to improve in that area?

Everyone has an answer to the first question, but the follow up is what separates the rock stars from the rest of us.

Getting your first Software Development Job

gaffleck — Mon, 30 Jan 2023 06:04:15 +0000

I've been asked in the past by recent grads or people trying to get into the tech industry how to get their first job as a developer. I've given them various versions of the following advice enough times that I thought I'd summarize it here for a wider audience. Here goes:

You already have it!

See the thing about being a developer that's different from almost all other jobs is that you can just do it any time, any where and with almost no materials required. If you're studying to be a dental hygienist or electrician or project manager or pretty much anything, you can't really do the thing you're training for until you've completed your training AND (crucially) found someone to hire you to work. Software development is different. You can do it right now, at home, with the same device you're using to read this article, for free. If you want to be a Software developer, start developing something right now.

Just start!

To help illustrate my point, here's a short rendition of my personal career trajectory. I started out studying Marine Biology. Then taught ESL. Then worked in non-profits in Mexico and Central America. Then became really interested in building online businesses to related to the travel industry. So while living in a small jungle community in Honduras, I decided to teach myself how to make websites. I chose PHP as my first programming language to learn (with CSS and HTML) using the Joomla framework. Living in a small town, which just received dialup internet and lacked running water, I wasn't exactly in tech-hub. But I dedicated the hours and spent many long days (and nights) wrestling with the concepts of a CMS, learning CSS (for IE6 no less) and figuring out how to make a really ugly website. Then an amazing thing happened. Word got out in the town I was living in that I knew how to make websites, and suddenly owner of the internet cafe I had been living at for the past 4 weeks asked me to make them a website. So I did! Then they referred me to others in the town who needed websites and soon I had a side hustle that was allowing me to learn and earn at the same time.

Learn while you go

After about a year, I moved back to Canada and applied to every entry level job that was remotely close to software development that I could find. Eventually someone gave me a role as a part-time web master for a gaming company on a 3 month, minimum wage contract. Unlike many other fresh-grads applying for their first role, I was able to show a portfolio of things I'd built for real companies and speak to the innumerable challenges I'd faced in getting to where'd I'd already achieved. I was already a talking like a grizzled veteran about sprites, shims and that f&*king rounded corners bug that I spend 2 days trying to fix. I spent the next 5 years studying at night and working during the day. I moved into progressively more senior roles. I'd definitely recommend the work and study in parallel approach as it allowed me to tailor my studies to the work I was doing during my day jobs. I took detours through iOS, Java, C#, DB systems, Project Management and PHP and was able to practice the things I was studying at my day job. I also managed to get most of my studies paid for by my employers which was a huge bonus!

Programmers write code

During this period of my life, I developed a few habits that I think really helped me. One of them was coding on the bus. I was working full time and taking 2 or 3 courses at night school, so my schedule would look like 9-5 (work) 6-9PM (lecture) 3 nights per week. I didn't have much time in the day to get homework done and I still wanted to have a life outside of this grind, so I needed to find time to do my homework and programming assignments. My solution to this, which I still use, is public transit. I would ride the bus about 3 hours per day (home->work, work->school, school->home). By bringing my laptop and headphones and diving right into it as soon as I sat down, I was able to get most of my homework done during my commutes leaving weekends open for non-digital pursuits. This habit helped me to prioritize the most important thing for each 1 hour block, to avoid procrastination and to block out distractions. You'd be surprised how much you can get done in a focused hour with a very clear stop up ahead (pun). So during this time of my career, I was probably spending 11 hours per day coding during the week and taking the weekends off. And I enjoyed it. The school assignments were fun and novel and the day jobs were more nuanced and filled with real world complexity that school work just can't teach.

Find the why

The reason why I got into technology in the first place was that it combined some of my interests:

Seeing small and medium businesses from the inside
Solving problems and learning
Building things
Working with smart people

I was fascinated with how complex systems are built and maintained, I loved the dopamine hit of seeing something new come to life and I loved seeing and working with business owners in the early stages of their journey.

I've been working in the field for nearly 20 years now and my roles have evolved over time, but I've never lost the passion and interest for using technology to solve real word business problems and to build cool things with smart people, that is what drives me.

Your first year as a Software Dev

So, if I were to give myself some advice on day 1, it would be this:

Find a project: solve a problem that you care about using technology, solve 1 problem deeply, don't just do 100 hello world tutorials
Develop a work habit that allows you to have at least 8 hours of focused time per work day on your project
Learn how to test and instrument your code in an many ways as you can
Ask for guidance from mentors in the field
Enlist others to help you in whatever way they can (do you have friends in the same position as you, sign them up as collaborators)
Try to find a customer who'll use what you're building (even if they can't or won't pay for it yet)
Work out loud: blog about it, tell your friends, go to conferences, meetups etc.

Do this for 1 year. Try to dedicate the best hours of your day to this project. By the end of 1 year, 1 of 3 things will have happened:

You'll have created a startup! Congrats!
Someone will have hired you to do this full time on salary. Congrats!
You'll have realized that you don't find the work as engaging as you thought. Congrats, it's not for everyone and you've failed fast as we say in the biz. On to your next adventure.

(If you find your Github profile looking like this, you might need to ask yourself if this is actually something you enjoy doing.)

If you've followed my advice for 1 year and haven't found a full time job yet, reach out to me. I might have a job for you.

Photo Credits

Photo of chicken bus by Javier Ortiz on Unsplash

Cover Photo by Guido Coppa on Unsplash

Photo of a group of programmers by Hello I'm Nik on Unsplash

Graphql Federation with NestJS and Apollo

gaffleck — Sun, 22 Jan 2023 02:31:20 +0000

As your Graphql backend grows there may come a time when you want to split the service into smaller components or microservices. This can help keep your domains isolated and speed up deployments. The really cool feature of the graphql system is federation, which will allow you to deploy isloated graphql backends and integrate them for your front-end.

Let's look at an example:

Our Domains

Let's continue with our example form last week of the system for a university. Let's say we want to integrate a finance system to track the accounts payable for our students.

Here is our model for the account balance. We link the balance to the student via student ID and track a very simple amount of data.

type accountBalance{
  outstandingBalance: Int
  paymentDue: String
  StudentId: ID

}

Now, in order to implement the backend, we have 2 choices, we can integrate the payment system into our existing student backend or split them out into microservices. Since payments and class registrations aren't necessarily correlated, let's keep the separate.

The design will require us to deploy 3 services:

a registration service
an accounts payable service
a gateway service to provide a unified front-end

Let's start with the gateway and work backwards from there.

The API Gateway

Api gateways are a feature of Graphql which allow you to aggregate types across micro-services without muddying your domains. NestJS is a great platform for this. To start with let's add the student object to our balance type:

type accountBalance{
  outstandingBalance: Int
  paymentDue: String
  StudentId: ID
  Student: Student
}

Now we need to identify how to fetch a student on our Student type, back in our first Service:

type Student @key(fields:'id'){
//
}

now in our student resolver we need to define how to fetch a student when requested by id:

@ResolveReference()
  async resolveReference(
    reference: {
      __typename: string;
      id: string;
    },
    context: IGraphqlContext
  ) {
    const { id } = reference;
    const user = await context.loaders.studentBySelfLoader.load(id);
    return this.studentMapper.persistenceToGql(user);
  }

Now we've defined how to fetch a student when requested by any other service we just need to link the two services together via a gateway.

Now we need to define a federation service to aggregate our domains


import {
  ApolloFederationDriver,
  ApolloFederationDriverConfig,
} from '@nestjs/apollo';
import { Module } from '@nestjs/common';
import { GraphQLModule } from '@nestjs/graphql';
import { UsersResolver } from './users.resolver';

@Module({
  imports: [
    GraphQLModule.forRoot<ApolloFederationDriverConfig>({
      driver: ApolloFederationDriver,
      typePaths: ['**/*.graphql'],
    }),
  ],
  providers: [StudentsResolver, AccountResolver],
})
export class AppModule {}

Using Graphql Data Loaders with NestJS and Apollo

gaffleck — Thu, 12 Jan 2023 18:30:28 +0000

I'll continue my love affair with Graphql this week by digging into an issue that caused a lot of pain when we switched from Appsync serverless Graphql APIs to running them on Nest with Apollo (more on that later).

After switching to a graphql service that was hosted in a single managed process (AWS Lambda in our case), we started to see big performance degradation when doing nested queries. These bottlenecks existed all along, but didn't become apparent when Appsync was managing our compute directly via Lambdas, when we started managing the backend ourselves, we hit N+1 issues that caused queries to drop from 2 sec to 30 seconds overnight. Here's how we fixed it and how we measured the impact of our changes.

The N+1 Problem

Let's get our definitions straight before we dive in. N+1 problem is something that can happen in GraphQl when your schema relies on nested resolvers. Let's look at an example


type Student {
  id: ID!
  name: String!
  registrations: [Registration]
}

type Registration{
  id: ID!
  courseName: String
  teachers: [Teacher]
}

type Teacher {
  id: ID!
  name: String!
  department: Department
}

type Department{
 id: ID!
 name:String!
}



type query{
  getStudents: [Student]
}

So in this simple example we have a query to get a list of students, but for each student, we can also fetch the classes they are in, and for each class the professor(s) and which department they are in. Works fine with a small number of students, but let's assume we're doing this for a university with 1000s of students. Without optimization, a single query for 100 students, could trigger 1000s of additional calls to resolvers to fetch Teachers and and Departments and many of those Teacher and Department calls would be duplicates, so the query would be expensive and poorly optimized.

Enter Data loaders

Using a data loader pattern in this case would allow you to defer the loading of nested objects until the later in the query and only fetch unique ids as a single batched request which could improve performance in this case many fold.

Using NestJS as our platform (which uses Apollo under the hood) we can wire them up like so.

First: Define a data loader object for your type

// teacher data loader

@Injectable()
export class TeacherDataLoader {
  constructor(private readonly teacherRepository: TeacherRepository) {}

  public createLoaderBySelf(): DataLoader<string, TeacherModel> {
    return new DataLoader<string, TeacherModel>(
      async (ids: readonly string[]) => {
        const result = await this.teacherRepository.getByIdsDataloader(ids);

        const result = mapTeachers(ids, result);

        return result;
      }
    );
  }
}

export const mapTeachers = (
  ids: readonly string[],
  teachers: TeacherModel[]
): TeacherModel[] => {
  const result = ids.map((id) => teachers.find((x) => x.id === id) || null);
  return result;
};

What this loader is doing is accepting a list of ids, fetching all the teachers in a single call to our repository and then mapping them by id back to our resolver.

Next:Add it to your graphql context

It can be accessed in the Nest resolver like this:


export class GraphqlContext {
  constructor(
    private readonly teacherDataLoader: TeacherDataLoader){}

async getContext(props: GetContextProps): Promise<IGraphqlContext> {
    const context: IGraphqlContext = {}

  context.teacherDataLoader = teacherDataLoader;
 }
}

Then: Use it in a resolver

And in the file responsible for resolving Students you refer to your loader which is available in the graphql context

@Resolver('Teacher')
export class TeacherResolver {
  constructor() {}



  @ResolveReference()
  async resolveReference(
    reference: {
      __typename: string;
      id: string;
    },
    context: IGraphqlContext
  ) {
    const { id } = reference;
    const teacher = await context.teacherDataLoader.createLoaderBySelf.load(id);
    return teacher;
  }
}

This example is using schema first development from NestJS. Here is the docs on the nest homepage. Happy coding!

Partial Success Graphql in Batch Operations

gaffleck — Thu, 05 Jan 2023 23:59:26 +0000

I really like Graphql. Since adopting it at Produce8, we've really enjoyed how it decouples backend and front-end concerns and allows for high re-use.

We recently hit a challenge and I wasn't able to find a lot of good samples online, so I thought I'd share what we did.

The Scenario

We have a batch operation (say add a tag to a photo), and each request has it's own validation implemented on the service (ie. ensure that you have update permissions on that specific photo record). So a batch of 10 addTag mutations might succeed for 9 and fail on 1. This didn't feel like an 'error' scenario, and the front-end will require the ID of the failed record to show a contextual error message to the end user. So here's how we handled it.

The Solution

First we implement our mutation API

type Mutation{
batchUpdatePhoto(input: BatchPhotoupdateInput!): [BatchPhotoupdateResponse!]!
}

input BatchPhotoupdateInput {
  pairs: [PhotoTagPairInput!]!
}

input PhotoTagPairInput {
  photoId: ID!
  tagId: ID!
}

This allows a user to send a set of photos to be tagged. Each will be processed individually by the resolver on the serverside and list of responses will be returned.

Partial Success

Now for the tricky bit, we want to return the same number of responses as input pairs received and inform the user which failed to be parsed, so we need to do a union of a success message and the specific errors that could be returned.

union BatchPhotoupdateResponse = NotAuthorizedToUpdatePhotoError | Photo 

type NotAuthorizedToUpdatePhotoError implements CoreServiceError {
  code: String!
  message: String!
  photoId: ID!

}

interface CoreServiceError {
  code: String!
  message: String!
}

By doing a union between the success and error response, we're able to return a single array of results to the client which can be both a success and error case.

Happy Coding!