{% messageCard title="Article note" %}
This is the first article in the Pimp My App series. The series explores various aspects of modernizing a legacy project. Each post will dive into a different part of the transformation journey.
{% br /%}
This article focuses on gaining a deep understanding of the project’s domain using a technique called Event Storming.
{% /messageCard %}

## The Tale of Tired Codebase

It started like so many software projects do — with urgency. A few years ago, the company decided to launch its own e-commerce platform. There wasn’t much time to plan, research or architect. The business team needed something up and running — fast. The goal was clear: **start selling as soon as possible**.

A small dev team got to work. They got the initial version running in record time. It did just enough to satisfy early users and gained traction. But then came the first request: *“Can we just add this small feature?”* And then another: *“We need this to go live by the end of the week”*. And another: *“Marketing needs this new flow — it’s top priority”*.

There was no time to step back and think about architecture or domain design. No one documented the business logic — it lived in scattered conversations, Slack messages and the minds of a few burned-out developers. Code was copy-pasted, patched and layered on top of itself like sediment. The checkout flow alone had been reworked half a dozen times, with remnants of each version still lurking in the codebase.

Today, the system still runs — barely. Everyone knows it’s risky to touch. Developers onboard onto the project with a deep sigh. No one is quite sure how one module relates to another. Every change feels like surgery without a diagnosis. When a bug shows up in production, it’s anyone’s guess what caused it or how to fix it safely. And when a stakeholder says, “Can we just add one more thing?” the engineering team winces.

{% twitterPost id="1603711968971558914" /%}

So here we are: a product that grew fast, delivered value, and now stands as a monument to years of unspoken decisions. The team knows something has to change. But where do you even start when you don’t understand the system you’ve built?

## Introducing Event Storming

This is exactly the kind of situation where Event Storming proves valuable — not as a tool for immediate rewriting or refactoring, but as a way to take the first and most crucial step: **understanding the system**.

Event Storming is a collaborative workshop technique designed to uncover how a business process actually works. Instead of starting with code or technical architecture, it starts with business events — things that happen in the domain: `OrderCreated`,  `PromoCodeApplied`, `OrderShipped`, etc.

In a session, people from different roles — developers, product owners, domain experts, customer support — all get in the same room (or virtual whiteboard) and map out the flow of events that make up the system’s behavior. No diagrams, no UML, no formal structure. Just sticky notes and conversations.

The result? A shared understanding of how things really work — not how we think they work, or how they were supposed to work but what’s **actually happening today**.

## Types of Event Storming Sessions

Event Storming isn’t a one-size-fits-all technique — it comes in different forms depending on how deep you need to go and what kind of problems you’re trying to solve. Generally, there are three main levels of Event Storming:
### Big Picture Event Storming
This level focuses on mapping out an entire business domain at a high level. It’s great for identifying bounded contexts, aligning business and tech and spotting organizational bottlenecks. You’re not interested in every little detail — the goal is understanding how the system behaves as a whole.

### Process-Level *(a.k.a. Design-Level)* Event Storming
This is where you zoom in on a specific business process — like “placing an order” or “processing a payment”. The focus is on how things happen step by step, and how information flows between parts of the system. It’s incredibly useful for uncovering domain rules or finding inconsistencies.

### Software Design-Level Event Storming
The most granular level, where the goal is to go from domain knowledge to actual implementation details. This level often leads directly into designing aggregates, defining commands, shaping APIs and even laying groundwork for different patterns like Event Sourcing or CQRS.

{% hr /%}

For our e-commerce case — where we have a system that technically works but is full of unknowns — the most practical place to start is the Process-Level Event Storming. It strikes a balance between high-level clarity and actionable insight. It helps teams make sense of one critical process at a time, identify where the complexity lives, and gradually rebuild understanding from the inside out.

In the rest of this article, we’ll focus on Process-Level Event Storming — what it looks like, how to run a session, and why it’s such a powerful tool for untangling messy systems like ours.

## Main Concepts and Recommendations for a Successful Session

**1. Start with Domain Events**

Always begin by identifying the events that occur in the business process — things that happen and are meaningful to the domain, like "Order Placed," "Payment Confirmed," or "Inventory Reserved." These are the backbone of the session.

**2. Use the Ubiquitous Language**

Stick to the language of the domain — not tech jargon. Everyone should be able to understand the terms being used. If two people use different words for the same thing, talk about it and pick one.

**3. Visualize Everything**

Use sticky notes (physical or digital) with distinct colors for different concepts {% link href="#the-color-coded-language-of-event-storming" ariaLabel="Part two of article series" %} (more on that in the next section){% /link %}.

**4. Collaborate — No Spectators**

Everyone in the room contributes. Developers, designers, product owners, and domain experts should all participate. Silence or dominance from one group usually leads to blind spots.

**5. Embrace Imperfection**

The goal is discovery, not perfection. It’s okay to be wrong, to make guesses, or to leave sticky notes that say “?” or “needs clarification.” You’re surfacing unknowns — that’s part of the process.

**6. Work Left to Right, Chronologically**

Events should be placed in the order they happen. This helps build a timeline of the process and reveals cause-effect relationships.

**7. Highlight Hotspots and Confusion**

If something causes debate, confusion, or disagreement — mark it. These are the valuable parts. They often hide complexity, misunderstanding, or poor design.

**8. No Laptops, No Distractions (for in-person)**

Focused attention is critical. If remote, use a tool like Miro, MURAL, or FigJam — and ask everyone to stay engaged.

**9. Timebox, but Don’t Rush**

Give yourself enough time — especially for the first session. Event Storming can feel chaotic at first, but the insights snowball quickly. Don’t rush to “finish”; aim to learn.

## The Art of Curiosity

I want to highlight that **curiosity** is one of the most powerful tools you can bring to an Event Storming session. Rather than simply documenting what’s already known, the goal is to uncover gaps, challenge assumptions, and surface hidden complexity within the domain. Asking “why?”, “what happens next?”, or “who decides that?” can reveal critical insights that might otherwise go unnoticed. For example for every event, ask:
* *What caused this?* → Leads to a Command.
* *What happens next?* → Leads to more Events or Policies.

In the next chapter each building block is provided with example guiding questions.

## The Color-Coded Language of Event Storming

One of the most powerful aspects of Event Storming is its use of colored sticky notes to represent different elements in a system. Each color has a distinct meaning, and together they bring order to complexity by mapping out the flow of events, decisions, actions, and data across a business process. More than just visual flair, this color system makes cause and effect instantly clear — turning messy domains into collaborative, navigable models.

Here are the most common sticky note colors and what they represent:

### 🟠 Domain Event (Orange)
**What it is**: Something that happened in the domain and is meaningful to the business.

**Why it matters**: Domain events are the backbone of the process. They describe outcomes and help trace the system's behavior over time. They also provide a shared language between tech and business.

**Guiding question**: What happened?

![events](/assets/event-storming/events.png)

### 🔵 Command (Blue)
**What it is**: An instruction to do something — often triggered by a user or system.

**Why it matters**: Commands initiate change. They precede domain events and usually represent user intentions or system actions. Every command should ideally lead to one or more events — unless it’s rejected.

**Guiding question**: What triggered the event?

![commands](/assets/event-storming/commands.png)

### 🟡 Aggregate / Consistency Boundary (Yellow)
**What it is**: A cluster of domain objects that are treated as a single unit for consistency and transactional integrity.

**Why it matters**: Aggregates define where decisions are made. They are responsible for handling commands and enforcing invariants. In practice, this is where domain logic lives.

**Guiding question**: Who/what decided how to handle the command?

![aggregates](/assets/event-storming/aggregates.png)

### 🟣 Policy (Purple)
**What it is**: A rule, condition, or automated reaction that kicks off a command when certain events occur.

**Why it matters**: Policies help capture business logic and automation. They often live in the background and can be hidden inside code or processes. Making them explicit helps identify where complexity lives.

**Guiding question**: What automatically happens next?

![policies](/assets/event-storming/policies.png)

### 🩷 External System / Actor (Pink)
**What it is**: Any external service, system, or actor that interacts with your domain but isn’t controlled by it.

**Why it matters**: These notes clarify integration points. Identifying external dependencies early helps manage risks, delays, and error handling in the system.

**Guiding question**: What external systems interact with our domain?

![3rd party systems](/assets/event-storming/systems.png)

### 🟢 Read Model / View / UI (Green)
**What it is**: A projection or view of data meant for display — often read-only.

**Why it matters**: These notes represent the queries or views that users interact with. They help model what information needs to be available and when — especially important in systems using CQRS.

**Guiding question**: What information do users need to see?

![views](/assets/event-storming/views.png)

{% messageCard type="tip" title="Helpful Tip" %}
The screenshots above are provided solely to illustrate examples of color usage. They were intentionally designed to clearly show how different sticky note colors are used. In a real Event Storming session, while you should start with identifying a few Domain Events to get the conversation started, you should avoid focusing exclusively on one type of element. Instead, aim to move from left to right, following the flow of data and decisions through the system, and explore the broader context collaboratively as the model evolves.
{% /messageCard %}

## To put this all together

Event Storming is not just a modeling technique — it’s a collaborative discovery tool that helps teams untangle complexity, bridge communication gaps, and rediscover the true shape of their systems. At its core, Event Storming is about understanding how things happen in a domain by mapping out domain events, commands, policies, and external interactions using simple, color-coded sticky notes. What sets it apart is its ability to bring technical and non-technical people into the same conversation, using shared language and visual clarity to uncover how a system really works — not how it was imagined or documented.

### Strengths

One of its greatest strengths lies in its speed and low barrier to entry. Unlike formal modeling methods, Event Storming doesn’t require specialized tools or upfront structure. It embraces exploration over precision, allowing teams to quickly surface misunderstandings, design flaws, and hidden complexity. It’s especially powerful in legacy systems, where documentation is missing and institutional knowledge has eroded. As shown in example of our e-commerce app, Event Storming makes it possible to reconstruct and clarify even the most chaotic flows, step by step.

### Challenges

However, Event Storming isn’t without trade-offs. Its unstructured nature can be overwhelming at first, especially for teams unfamiliar with domain-driven design or those lacking facilitation experience. Sessions can easily go off-track without clear goals or a strong facilitator. Additionally, while Event Storming excels at discovery and communication, it doesn’t provide direct implementation guidance — it needs to be paired with technical design work to turn insights into architecture.

### Summary

When used intentionally, Event Storming becomes a lightweight but high-impact practice for teams struggling with unclear business logic, risky changes, or a lack of domain insight. It’s not about drawing pretty diagrams — it’s about creating shared understanding, fostering better decisions, and ultimately building better software.

Confused by your app’s domain? Learn how to break down processes, map events, and uncover what really drives your system in the process of Event Storming session.

Pimp My App - Event Storming

## *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

Pimp My App - Event Storming

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