## *Innovative and Ever-Changing industry*

When I asked ChatGPT to describe the IT industry, the first point mentioned was *"Innovative and Ever-Changing"*. But what exactly lies behind this overused phrase? It’s often applied to the tools, technologies, and work methodologies shaping the industry. While that’s accurate, this statement can be expanded further.

What’s also innovative and ever-changing are the projects themselves and the overall nature of work in IT. A developer working on the same project for 10 years or more is almost unheard of. Compared to other industries, project rotations in IT are far more dynamic.

## Commit within the first week

The title of this post suggests that a new team member should be able to make their first contribution within a week of joining the team. Of course, a week is a general benchmark—some projects might set this timeline at two weeks, while others could aim for just two days. It all depends on the specific context of the project, such as the complexity of the domain, the maturity of the project, and its current state.

What’s crucial is that the timeline remains relatively short. Achieving this goal is only possible when various smaller aspects of the development process are well-optimized and standardized at a high level.


## Onboarding and Its Key Components

During the onboarding process, it’s not just the new team member who learns; the team and its leaders also gain valuable insights. Observing how the new person navigates the process can reveal areas where the team or project needs improvement. Breaking this process into smaller components is particularly useful.

### Documentation

First and foremost, documentation should exist—but more often than not, I’ve encountered the issue of outdated or incomplete docs. It’s also worth ensuring that a consistent notation, like {% link href="https://www.uml.org/" ariaLabel="UML org" %}UML{% /link %} or {% link href="https://c4model.com/" ariaLabel="C4 site" %}C4{% /link %}, is used so that every diagram is clear, unambiguous, and each component easily identifiable. Additionally, having deeper context on major project decisions in the form of {% link href="https://en.wikipedia.org/wiki/Request_for_Comments" ariaLabel="RFC wikipedia" %}RFCs (Request for Comments){% /link %} or {% link href="https://adr.github.io/" ariaLabel="ADR website" %} ADRs (Architecture Decision Records){% /link %} can be extremely helpful.

### Planning

A new team member should be able to pick up a small, straightforward ticket that allows them to explore the codebase. Regular refinement sessions, with the entire team present, are critical here. Every ticket should include all necessary information, such as clear acceptance criteria, sufficient context, and a detailed description of changes. If a new hire’s first ticket ends up being overly complex simply because there were no smaller tasks available, it might signal an issue with ticket scoping or inaccurate estimations.

### Implementation

I firmly believe every team strives to produce the highest-quality code. However, this goal is often hindered by shifting requirements, time pressure or other factors. A new team member can act as an informal auditor (within reason), bringing a fresh perspective to the existing codebase. They may identify areas where for instance design patterns are missing or where a solution requires refactoring. It’s equally important to understand why these issues exist—for instance, is the review process inadequate? Does the team lack domain or technical knowledge? If so, training may be necessary or other forms of filling up the knowledge gaps.

### Testing

It’s unreasonable to expect a new team member to fully test all the pathways their changes might impact. To safeguard against regression, the project should include a robust suite of various tests, such as:
* Unit tests
* Integration tests
* End-to-end (E2E) tests
* Smoke tests
* Performance tests

Metrics like test coverage should be monitored, and periodic stress testing should be considered if necessary. Theoretically stress tests may not always be critical for high-traffic services, this can be offset by having excellent observability in place.

### Deployment

Releasing changes should be as automated and safe as possible. My personal recommendation is to use proven patterns like {% link href="https://martinfowler.com/bliki/CanaryRelease.html" ariaLabel="canary release deep dive" %}canary releases{% /link%}, paired with automated mechanisms to prevent faulty changes from being deployed. Ideally, releases should initially target a limited group of users, and any negative deviations from the norm (e.g., increased error rates, higher latencies, or excessive RAM/CPU usage) should trigger an automatic rollback to the last stable version.

The ultimate goal is to ensure that the team can deploy changes to their services regularly, while new team members feel confident that even if their changes have issues, they won’t have catastrophic consequences for the team or the project.

## Onboarding as an source of SLOs

Furthermore having onboarding classified into smaller segments, the team can establish internal {% link href="https://www.ibm.com/topics/service-level-objective" ariaLabel="IBM SLO deep dive" %}Service Level Objectives (SLOs){% /link%} for each component. For instance, when discussing testing, an example SLO could be maintaining a test coverage level of 90% and having smoke tests and end-to-end (E2E) tests for critical application paths.

For deployments, the team might set an objective for rollback times to the last stable version (e.g., no longer than five minutes). Other examples include limiting the time a ticket spends in the review process to 24 or 36 hours.

These examples are just starting points. The key is for the team to identify which aspects are most critical to their workflow and create meaningful metrics that ensure these elements are consistently prioritized and well-maintained.

## Summary

First and foremost, it’s essential to understand that the speed of onboarding should be a natural outcome of a well-functioning team that excels in every aspect of the {% link href="https://aws.amazon.com/what-is/sdlc/" ariaLabel="AWS SDLC deep dive" %}Software Development Life Cycle (SDLC){% /link%}, rather than a direct goal. The objective isn’t to force someone through onboarding and achieve their first commit within the first week. Instead, it should happen organically.

Onboarding, in its various forms, is an inevitable process in any team. It’s crucial to embrace it, as the efficiency of this process can serve as an incredibly valuable indicator of the team’s and project’s overall health.

Efficient onboarding reflects a team's health. Learn how well-organized workflows support growth and project continuity.

First-Week Commit: Why Onboarding Counts

{% messageCard title="Article note" %}
This is Part 2 of a series on building a secure serverless GraphQL API. While it's not mandatory to read {% link href="/articles/building-secure-serverless-graphql-api-part-1" ariaLabel="Part one of article series" %}the part 1{% /link %}, doing so can help understand the context better. This article delves into security-related aspects, whereas {% link href="/articles/building-secure-serverless-graphql-api-part-1" ariaLabel="Part one of article series" %}the part 1{% /link %} addresses fundamental GraphQL concepts and the process of building one.
{% /messageCard %}

## Authentication 

Authentication is the process of verifying the identity of a user or system. By performing authentication we can add needed context to the requests. AWS AppSync supports several authentication types:
* `API_KEY`,
* `AWS_LAMBDA`,
* `AWS_IAM`,
* `OPENID_CONNECT`,
* `AMAZON_COGNITO_USER_POOLS`.

In case of this application `AMAZON_COGNITO_USER_POLLS` is chosen as the primary authentication type. {% link href="https://aws.amazon.com/cognito/" ariaLabel="Amazon Cognito product page" %}Amazon Cognito{% /link %} is a fully managed identity and user management service. It provides an option to create user pools which are a user directories. Let's start by creating a user pool in serverless framework. Config used for this user pool sets a policy for a password (minimum length of 8) and user attributes. 

```yaml
UserPool:
    Type: AWS::Cognito::UserPool
    Properties:
        AutoVerifiedAttributes:
            - email
        Policies:
            PasswordPolicy:
                MinimumLength: 8
                RequireLowercase: false
                RequireNumbers: false
                RequireUppercase: false
                RequireSymbols: false
        UsernameAttributes:
            - email
        Schema:
            - AttributeDataType: String
                Name: name
                Required: false
                Mutable: true
```

With this defined, the next step is linking it to the AppSync API.

```yaml
authentication:
  type: AMAZON_COGNITO_USER_POOLS
  config:
    userPoolId: !Ref UserPool
```

### Secondary authorizer

This app is an example of an online store. Some operations, like `placeOrder`, should only be done by admins or logged-in users, while others should only be available on the frontend. To handle this, feature of AppSync can be used that allows having multiple authorizers. In this case, an API key will be used to let the frontend connect to AppSync and run queries. It's a good idea to regularly rotate API keys, so a 1-month expiration time was set for this one.

```yaml
additionalAuthentications:
  - type: API_KEY
apiKeys:
  - name: WebClientApiKey
    expiresAfter: 1M
```

When both authorizers are defined, the GraphQL schema can be updated to reflect those changes. By default, when multiple authorizers are specified and the schema doesn't use directives to specify which field, query, or mutation should be used by which authorizer, AppSync assumes that the default authorizer will be used for all of them. This means it is not possible to access any of them using secondary authorizers. So in case of queries `getProducts` and `getCategories` should be allowed to be executed by both logged-in and not logged-in users. `getOrders` should only be executed by logged-in users. That's why, under the query declaration, no schema directive is used, and the query defaults to the default authorizer.

```gql
type Query {
    getProducts: [Product!]
    @aws_api_key @aws_cognito_user_pools
    getCategories: [Category!]
    @aws_api_key @aws_cognito_user_pools
    getOrders: [Order!]
}
```

## Authorization

Authorization is the process of determining and granting permissions to a user or system to access specific resources or perform certain actions. It defines what an authenticated user is allowed to do within a system. In case of this application some mutations like `placeOrder` should be allowed to be executed by all logged-in users while others like `createProduct` only be a specified group of users, for example administrators. 

Authorization can be achieved by first creating a user group in Cognito User Pools and then specifying operations in the GraphQL schema that should only be invoked by members of this group by appending schema directives.


Let's start with creating user group
```yaml
AdminGroup:
Type: AWS::Cognito::UserPoolGroup
Properties:
    GroupName: Admins
    UserPoolId: !Ref UserPool
```

Let's update graphql schema, bear in mind that name of the group in schema must match name of the group specified in cognito configuration.

```gql
type Mutation {
    placeOrder(input: OrderInput!): Order!
    createProduct(input: ProductInput!): Product!
	@aws_cognito_user_pools(cognito_groups: ["Admins"])
    createCategory(input: CategoryInput!): Category!
    @aws_cognito_user_pools(cognito_groups: ["Admins"])
    startProcessingOrder(id: ID!): Order!
	@aws_cognito_user_pools(cognito_groups: ["Admins"])
    completeOrder(id: ID!): Order!
	@aws_cognito_user_pools(cognito_groups: ["Admins"])
}
```

## Applying least-privilege permissions to IAM roles

When creating set of permissions to roles to attached to lambdas or other resources, grant only the ones that are need to perform a task. This way even if something goes wrong there's a smaller chance that unwanted operations will be spread across more resources. 

Example of limited set of privileges attached to lambda:

```yaml
products:
  handler: src/functions/field/products/products.handler
  environment:
    PRODUCT_TABLE: !Ref ProductTable
  iamRoleStatements:
    - Effect: Allow
      Action:
        - dynamodb:GetItem
      Resource: !GetAtt ProductTable.Arn
```

Example of non limited set of privileges attached to lambda:

```yaml
products:
  handler: src/functions/field/products/products.handler
  environment:
    PRODUCT_TABLE: !Ref ProductTable
  iamRoleStatements:
    - Effect: Allow
      Action: "*"
      Resource: "*"
```

## Mitigating malicious operations

### Limiting query depth

GraphQL allows clients to request data in multiple ways, offering various entry points. This flexibility enables the creation of exceptionally large and nested queries, such as the following example where 

```gql
query NestedQueryExample {
  getProducts {
    categories {
      products {
        categories {
          products {
            categories {
              # And this goes on and on...
            }
          }
        }
      }
    }
  }
}
```

This can be easily fixed in AppSync by specifying `queryDepthLimit` property.

```yaml
queryDepthLimit: 3
```

### Rate limiting

API rate limiting is a technique used to control the number of requests a client can make to an API within a specific time frame. It helps prevent abuse, ensures fair usage, protects against DDoS attacks, and maintains the overall performance and reliability of the API. By setting limits, such as 1000 requests per hour, developers can manage traffic effectively and provide a better experience for all users.

This can be achieved by using {% link href="https://aws.amazon.com/waf/" ariaLabel="AWS WAF service page" %}AWS WAF{% /link %} service. AWS WAF (Web Application Firewall) is a security service provided by Amazon Web Services that helps protect web applications from common web exploits and attacks. It allows you to create custom security rules to block or allow specific traffic patterns, such as SQL injection, cross-site scripting (XSS) or enabling **rate limiting**.

Example of enabling WAF:

```yaml
waf:
  enabled: true
  rules:
    - throttle # limit to 100 requests per 5 minutes period
```

More advanced configuration can also be passed:

```yaml
waf:
  enabled: true
  rules:
    - throttle:
        limit: 200
        priority: 10
        aggregateKeyType: FORWARDED_IP
        forwardedIPConfig:
          headerName: 'X-Forwarded-For'
          fallbackBehavior: 'MATCH'
```

## Disabling schema introspection

Disabling schema introspection in a production environment is a security best practice often implemented to protect sensitive information about the application's GraphQL schema. Schema introspection allows clients to query the schema itself, revealing details such as data types, field names, and relationships. While useful in development for debugging and client-side tooling, exposing this information in production can potentially aid attackers in understanding the structure and vulnerabilities of the API. By disabling schema introspection, developers reduce the attack surface and mitigate the risk of unauthorized access or exploitation of the GraphQL API.

This can be achieved by specifying `introspection` property.

```yaml
introspection: false
```

## Observability and monitoring

On the aws docs {% link href="https://aws.amazon.com/compare/the-difference-between-monitoring-and-observability/" ariaLabel="AWS docs on observability and monitoring" %} GraphQL documentation site{% /link %}, such a definition is mentioned:

> Monitoring is the process of collecting data and generating reports on different metrics that define system health. Observability is a more investigative approach. It looks closely at distributed system component interactions and data collected by monitoring to find the root cause of issues. It includes activities like trace path analysis, a process that follows the path of a request through the system to identify integration failures. Monitoring collects data on individual components, and observability looks at the distributed system as a whole.

Following this definition let's look at 

### Observability

One of the services that enables to have a observability in a system is an {% link href="https://aws.amazon.com/xray/" ariaLabel="AWS X-Ray service page" %}AWS X-Ray{% /link %}. AWS X-Ray is a service that helps developers analyze and debug applications. It provides an end-to-end view of requests as they travel through different components of an application, helping to identify performance bottlenecks, errors, and dependencies across services. 

In order to enable X-Ray in AppSync `xrayEnabled` property must be specified. 

```yaml
xrayEnabled: true
```

When X-Ray we can introspect each trace from aws console.

![X-Ray trace](/assets/building-secure-serverless-graphql-api-part-2/x-ray.png)

### Monitoring

Individual components such as Lambda can be monitored with the help of {% link href="https://aws.amazon.com/cloudwatch/" ariaLabel="AWS CloudWatch service page" %}AWS CloudWatch{% /link %}.

![CloudWatch logs](/assets/building-secure-serverless-graphql-api-part-2/cloudwatch.png)


## Conclusions

Security is a far more complex subject then what was described here. With that being said guidelines described in this article are a nice starting point in making the apps that you build production ready.

{% link href="https://github.com/piotrek12101999/building-secure-serverless-graphql-api-part-2" ariaLabel="Link to github to full code repository" %}As always here's the link to the full code repository{% /link %}.

Discover the process of creating a secure serverless GraphQL API leveraging AWS Lambda, AWS AppSync, Amazon Cognito, AWS WAF, AWS X-Ray and DynamoDB. Implement BFF pattern with the power of GraphQL.

Part 2: Building secure serverless GraphQL API

Part 1: Building secure serverless GraphQL API

Idempotency is often overlooked in API design, yet crucial for reliability. Design and build asynchronous API that ensures robust performance and resilient operations.

Designing idempotent serverless systems

Learn how to create serverless RESTful API using API Gateway, AWS Lambda and DynamoDB. Build scalable, performant solutions in the cloud with this step-by-step guide.

Check out the latest articles

First-Week Commit: Why Onboarding Counts

Part 2: Building secure serverless GraphQL API

Part 1: Building secure serverless GraphQL API

Designing idempotent serverless systems

Building Serverless REST API with Lambda and TypeScript