A well-structured delivery pipeline ensures that software is shipped smoothly, reliably, and with confidence. Whether you’re working in a small team or a large enterprise, having a clear, repeatable process is critical for delivering high-quality software.

This article breaks down a delivery pipeline setup I implemented for a project, optimizing it for small teams. It includes staging best practices, automated deployments, package management, and a ticketing system that simplifies releases.

If you’re setting up a CI/CD workflow or refining your software deployment process, this guide is for you! 🚀

🎯 TL;DR

✔️ Always deploy to staging first before production.
✔️ Use nightly builds to test new features early.
✔️ Automate package publishing and CI/CD deployments.
✔️ Keep staging clients on staging APIs to prevent conflicts.
✔️ Use Jira statuses like “Ready for Deploy” to improve workflow.

1️⃣ The Importance of Staging

Why Staging?

Before any new feature or fix goes live, it must be tested in an environment that closely mimics production.

A staging environment serves as a sandbox for QAs and stakeholders to validate changes before they reach real users.

Golden Rule:

Never ship any new code to production if it has not yet been tested and approved for deployment!

But how should the testers access the changes if they exist only on the developer’s local system?

As the testers should act like end-users and not a part of the dev team, they should be able to access the final products in an environment that replicates the live version and includes all the latest changes that are ready to be tested. That is the staging environment.

So, the dev team should always deploy the latest finished changes to the staging environment and ask the QA to test them. Normally, the deployment might include some issues and bugs (which doesn’t mean that the dev shouldn’t test everything locally first), which the testers will notice and report.

When the testers and the PO approve the current state of the staging environment, the team prepares for a release on production.

Deployment to Staging

• Developers push their latest changes to staging.
• Testers (QA) validate everything as end-users would.
• Product Owners (POs) approve before release.
• If it’s good, it goes live!

2️⃣ Think of Your Product Like a Pizza 🍕

Your product is like a pizza — it’s made up of different slices (components), and they all need to come together seamlessly when deployed. In most cases it is like a 3-slice pizza in fact:

In this case, a deployment includes:

1️⃣ Packages (code libraries and dependencies)

2️⃣ The Server (backend APIs)

3️⃣ The Client (front-end applications)

Each of these components must be properly staged, tested, and released together for a smooth rollout.

3️⃣ Managing Packages Efficiently

Most modern development relies on package management to handle dependencies. Here’s how to keep it clean:

Staging Packages with Nightly Builds 🌙

When developing a new feature, testers should have access to pre-release versions. A nightly build ensures the latest changes are packaged daily.

📌 How to publish a nightly build:

npm publish --tag nightly

✅ Benefits:

• Allows early testing before an official release.
• Ensures integration issues are caught early.
• Automates packaging, reducing manual effort.

Production packages, on the other hand, should be versioned properly using semantic versioning (semver) for clarity.

4️⃣ Deployment Workflow: From Code to Production 🚀

Note: Remember to set the dependency packages in nightly builds to refer to their nightly versions.

The Server

• Runs in cloud or dedicated server, hosting the backend APIs.
• New code is deployed to staging first before production.
• The CI/CD pipeline automates deployment.

The Client

• Any changes in the front-end must be deployed in sync with the backend.
• If a client instance depends on a new API, it must be tested in staging first before being moved to production.

5️⃣ Streamlining Task Management with Jira 📋

As we want the testers to have something already deployed to Staging for them to start testing and avoid doing it locally, we need to have a new state on for the tickets called “Ready for deploy”.

It would mean the following: “The code was written and reviewed and is ready to be delivered to the testers”.

Old Ticket Flow:

To Do → In Progress → Code Review → Testing → Done

New & Improved Workflow:

✅ To Do → In Progress → Code Review → Ready for Deploy → Testing → Done

After the sprint is finished and all the Done tasks are approved, the PO will identify the features that are ready to be delivered to the customers. For this kind of work, we will have separate deployment tasks that would skip the 3d and 4th steps during realization.

💡 Why this change?

• Before, testers had to wait and guess when developers manually deployed the latest version to staging.
• Now, with “Ready for Deploy”, testers know when a feature is available in staging.
• This reduces bottlenecks and improves release efficiency.

🚀 Result: Faster deployments, happier testers, and smoother releases!

6️⃣ Final Steps to a Cleaner Pipeline

To fully optimize the delivery process, these improvements should be implemented:

• [Task Management] Add a “Ready for Deploy” status in Jira.
• [Automation] Improve CI/CD scripts to auto-publish nightly builds.
• [Versioning] Use semantic versioning for clarity in releases.
• [CI/CD Improvements] Automate deployment of server and client to both staging and production.
• [Environment Fix] Ensure all staging clients use staging APIs only.

🚀 By implementing these best practices, small teams can maintain a highly efficient delivery pipeline without unnecessary delays or confusion.

Conclusion: Why This Works for Small Teams 🏆

A structured delivery pipeline isn’t just for large teams — -it’s critical for small teams too!

By automating testing and deployments, keeping environments clearly separated, and simplifying task tracking, you can:

✅ Ship faster
✅ Catch bugs earlier
✅ Reduce deployment stress

If you’re setting up a CI/CD process for your team, start with these principles — -they will save you a ton of headaches in the long run!

💬 What challenges have you faced with setting up a delivery pipeline? Let’s discuss in the comments! 🚀

Building a Scalable Delivery Pipeline for Small Teams 🚀 was originally published in devgorilla on Medium, where people are continuing the conversation by highlighting and responding to this story.

Imagine you walk into your neighborhood library looking for a rare book on “The Secrets of JavaScript Sorcery.” You ask the librarian, but — oops! — your library doesn’t have it.

But don’t worry! Instead of sending you home empty-handed, the librarian calls up the central city library to check if they have it. If they do, you get your book. If not, the search continues up the chain… maybe to the National Library Archive. And if even they don’t have it? Sorry, no book for you.

This is exactly how JavaScript’s prototype chain works! 🚀

📌 TL;DR

• Objects in JavaScript can inherit properties from other objects.
• When a property isn’t found in an object, JavaScript climbs up the prototype chain to check its prototype.
• Object.create() is like opening a new library branch connected to the central library.
• If a property isn’t found anywhere, JavaScript returns undefined.

🏛 Libraries = JavaScript Objects

In JavaScript, objects can borrow properties and methods from other objects, just like a library can request books from a bigger library system. Let’s break it down:

1️⃣ Local Library (Your Object)

Your library has its own collection — books it directly owns.

const localLibrary = {
  specialCollection: ["Ancient Maps", "Rare Manuscripts"]
};

console.log(localLibrary.specialCollection);  
// ["Ancient Maps", "Rare Manuscripts"]

2️⃣ Central Library (Prototype)

But what if your local library doesn’t have a specific book? It asks the Central Library, which has a much bigger collection.

const centralLibrary = {
  lendBook: function() {
    console.log("Here’s your book from the central archive!");
  }
};

3️⃣ Connecting Them (Prototype Chain)

Now, let’s link your local library to the central one using Object.create(). This way, whenever your local library doesn’t have something, it automatically looks in the central library!

const cityLibrary = Object.create(centralLibrary);
cityLibrary.specialCollection = ["Ancient Maps", "Rare Manuscripts"];

console.log(cityLibrary.specialCollection);  
// ["Ancient Maps", "Rare Manuscripts"]
cityLibrary.lendBook();  
// "Here's your book from the central archive!"

Even though lendBook wasn’t defined in cityLibrary, it still worked! That’s because JavaScript climbed up the prototype chain and found it in the centralLibrary.

🛤 The Search Path (Prototype Chain in Action)

Let’s add another library: a small-town library that borrows from the city library.

const smallTownLibrary = Object.create(cityLibrary);
console.log(smallTownLibrary.specialCollection);  
// ["Ancient Maps", "Rare Manuscripts"]

Boom! Even though smallTownLibrary doesn’t have a specialCollection directly, it inherits it from cityLibrary, which inherited it from itself.

And it can still borrow books from the central library:

smallTownLibrary.lendBook();  
// "Here’s your book from the central archive!"

🔗 JavaScript keeps searching up the chain until it finds what it needs — or gives up!

❌ What Happens If a Book Doesn’t Exist?

Let’s say you ask for a mystery book that no one owns:

console.log(smallTownLibrary.rareBook);  
// undefined

JavaScript checks:

1️⃣ smallTownLibrary → ❌ (Doesn’t have it)
2️⃣ cityLibrary → ❌ (Doesn’t have it either)
3️⃣ centralLibrary → ❌ (Nope!)
4️⃣ Object.prototype → ❌ (Last stop—if it's not here, it doesn’t exist)

Since no one has it, you get undefined.

📌 This is exactly how JavaScript searches for properties in objects.

💡 Want an easier way to visualize the Prototype Chain?
Here’s what our example looks like behind the scenes:

smallTownLibrary  --->  cityLibrary  --->  centralLibrary  --->  Object.prototype  --->  null

Every object in JavaScript follows this chain all the way up to Object.prototype, which is like the National Library Archive—the place where common methods like .toString() exist.

🎯 Final Thoughts

Next time you’re borrowing a book from a library, think about JavaScript’s prototype chain working in the same way. Your local branch (object) might not have a book (property), but it always knows where to look!

This is what makes JavaScript so powerful and flexible — objects can share behavior without copying everything manually.

Now that you’ve cracked the mystery of Prototypes, where should we go next? 🤔

💡 Thinking about writing an article on how new works in JavaScript? Let me know!

The Prototype Chain Explained with a Library System 📚 was originally published in devgorilla on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a developer and SRE who regularly works with distributed systems, I’ve often found myself struggling with the complexities of log management. The promise of powerful tools like Grafana Loki is enticing, but the learning curve associated with LogQL, Loki’s query language, has been a constant pain point.

That’s why I’m excited to share my experience with Explore Logs, a new open-source application from Grafana Labs that provides a much more user-friendly interface for browsing and analyzing logs.

Leveraging the Power of Grafana Explore

Explore Logs leverages the existing Explore functionality within Grafana, which was originally designed for querying metrics data. By extending Explore to work seamlessly with Loki, Grafana Labs has created a log management experience that feels natural and intuitive, even for those of us who aren’t LogQL experts.

Under the hood, Explore Logs is still utilizing Loki’s powerful log aggregation and query capabilities, but it abstracts away the complexity of LogQL through a series of intuitive UI components. This allows to focus on the task at hand, rather than having to remember the syntax and structure of a specialized query language.

Key Features That Make a Difference

The standout features of Explore Logs for me include:

Labels: Explore Logs automatically detects and surfaces the labels associated with log data, making it easy to filter and group logs by these key-value pairs. The visual representations of the log volumes for each label are particularly helpful in identifying the most relevant data.

Detected Fields: In addition to labels, Explore Logs also integrates Loki’s ability to automatically extract structured fields from log lines. These detected fields are displayed in a clear, grid-like view, and I can use them to further refine log exploration.

Pattern Matching: One of the more advanced features that I’ve found incredibly useful is Explore Logs’ pattern matching capabilities. The application can automatically identify common templates or structures across log lines and present them as “patterns.” I can then leverage these patterns to quickly filter out noise or focus on specific types of log entries, saving me valuable time.

Search: For those times when I need a more freeform text search, the simple search bar in Explore Logs has proven to be a game-changer. Being able to perform case-sensitive searches across rendered log lines is a feature I didn’t know I needed until I had it.

Open in Explore: If I ever find that I do need the full power of LogQL to accomplish a particular task, Explore Logs includes a seamless integration with Grafana’s Explore UI. I can easily transition to the more advanced interface while preserving current context, ensuring a smooth and efficient workflow.

Community Feedback and Concerns

While the announcement of Explore Logs has generated excitement, the Grafana community has also voiced some concerns and feedback based on their experiences with existing log management solutions.

Many users expressed a desire for a simpler, more text-file-like experience when viewing logs, rather than having to learn complex query languages like LogQL. As one user commented, “all I have ever wanted to do, when looking at logs, is see the log from one process, from beginning to end, as a text file.” The ability to easily download log files and analyze them locally using familiar tools was seen as an important missing feature.

Some users also found the setup and configuration of log aggregation tools like Loki to be overly complex and time-consuming, with confusing documentation. There were concerns about the performance and cost of hosted log management solutions, with one user describing Loki as “incredibly slow” compared to the expense.

Another common theme was the desire for Explore Logs to more closely emulate the simplicity and ease-of-use of traditional text-based log viewing, without sacrificing the advanced aggregation and analysis capabilities of modern log management platforms. As one user put it, “LogQL is nothing like SQL. Try aggregating and quickly you’ll be asking yourself wtf an instant query is and how is that different.”

Grafana will need to carefully balance the needs of users who prefer a more traditional log viewing experience with the powerful querying and analysis features required for managing complex, distributed systems. Addressing these community concerns will be crucial to ensuring Explore Logs is a successful addition to the Grafana ecosystem.

A More Accessible Log Management Experience

As someone who has struggled with log management in the past, I’m thrilled to see Grafana Labs taking steps to make the process more user-friendly and accessible. By combining the power of Grafana and Loki, Explore Logs delivers a log management experience that is tailored to the needs of developers, SREs, and other IT professionals like myself.

I encourage everyone in the Grafana community to try out Explore Logs and provide feedback to help shape its future development. With the public preview now available, there’s never been a better time to explore the possibilities of this exciting new tool.

Like to learn more?

Find more in-depth guides on my website.
Follow me on Twitter for updates in AI, DevOps, and tech.
Connect on LinkedIn to chat or collaborate!

Simplify Your Logs Management with Grafana’s New Explore Logs App was originally published in devgorilla on Medium, where people are continuing the conversation by highlighting and responding to this story.

When building applications on AWS, the Cloud Development Kit (CDK) simplifies the provisioning of resources and their dependencies. However, a common challenge developers face is dealing with cross-stack references. Cross-stack references occur when a resource in one stack (e.g., a S3 bucket in Stack1) is referenced by another stack (Stack2). While AWS CDK facilitates these references for ease of use, they can introduce deployment complexities, particularly when you wish to delete a resource that is being referenced across stacks. This guide will explain how to resolve such issues, focusing on a two-step deployment process to safely remove cross-stack references.

Understanding the Problem

Suppose you have two stacks, Stack1 and Stack2, where Stack1 includes an S3 bucket, and Stack2 references the bucket's name (bucket.bucketName). If you decide to remove the S3 bucket from Stack1, you might encounter an error similar to:

Export Stack1:ExportsOutputFnGetAtt-****** cannot be deleted as it is in use by Stack1

This error occurs because CloudFormation, which underlies CDK deployments, protects against the deletion of resources that are being referenced by other stacks. Directly removing the S3 bucket in Stack1 without addressing the reference in Stack2 would break Stack2, leading to potential application failures.

Solution: A Two-Step Deployment Process

To safely remove a cross-stack referenced resource, you need to follow a two-step deployment process. This approach ensures that the dependency is cleanly severed before the resource is deleted, avoiding deployment errors and application downtime.

Deployment 1: Break the Relationship

The first deployment focuses on eliminating the dependency between Stack2 and the S3 bucket in Stack1.

1. Update Stack2: Modify Stack2 so that it no longer references the S3 bucket's name. This might involve switching to a different storage resource (like another S3 bucket or a DynamoDB table) or removing the dependent component altogether.
2. Update Stack1: In the Stack1 class, call this.exportValue(this.bucket.bucketName);. This step ensures that the CloudFormation export for the bucket's name remains available even as you work to decouple the stacks. This is crucial for maintaining stability during the transition period.
3. Deploy: Deploy both stacks. This deployment will primarily change Stack2, but it's a good practice to deploy Stack1 as well to enforce the export.

Deployment 2: Remove the Resource

Once the reference from Stack2 to the S3 bucket in Stack1 is removed, you can safely delete the bucket.

1. Remove the Bucket: Delete the bucket resource from Stack1. Also, remove the exportValue() call you added in the first step.
2. Deploy: Deploy Stack1. This deployment removes the S3 bucket, completing the process.

Example

Here’s a brief example to illustrate the steps above:

Before Modification

• Stack1 contains:

const bucket = new s3.Bucket(this, 'MyBucket');

• Stack2 references Stack1's bucket:

const bucketName = s3.Bucket.fromBucketName(this, 'ImportedBucket', 'stack1-bucket-name');

Deployment 1: Break the Relationship

• Modify Stack2 to remove the reference to Stack1's bucket.
• In Stack1, add:

this.exportValue(this.bucket.bucketName);

Deployment 2: Remove the Resource

• Remove the S3 bucket from Stack1 and the exportValue() call.
• Deploy Stack1.

By following these steps, you can smoothly handle cross-stack reference issues in AWS CDK, ensuring that your deployments are error-free and your infrastructure is easily manageable.

Here is the link to official documentation: https://github.com/aws/aws-cdk/tree/main/packages/aws-cdk-lib/core#removing-automatic-cross-stack-references

Like to learn more?

Find more in-depth guides on my website.
Follow me on Twitter for updates in AI, DevOps, and tech.
Connect on LinkedIn to chat or collaborate!

Removing AWS CDK Cross-Stack Reference was originally published in devgorilla on Medium, where people are continuing the conversation by highlighting and responding to this story.

When working with AWS Cloud Development Kit (CDK), it’s common to encounter situations where resources from different stacks, possibly in different regions, need to reference each other. A typical error message you might come across is:

Error: Stack ‘Stack1’ cannot reference {Stack2/KmsKey/Resource[Arn]} 
in stack ‘Stack2’. Cross-stack references are only supported for stacks 
deployed to the same environment or between nested stacks and their parent stack. 
Set crossRegionReferences=true to enable cross-region references.

This article explains the issue and provides a straightforward solution to enable cross-region references between stacks in AWS CDK.

Understanding the Issue

By default, AWS CDK supports references (e.g., outputs, SSM parameters) only between stacks that are deployed within the same AWS region or between nested stacks and their parent stack. This limitation exists to prevent complexities and potential inconsistencies arising from managing resources across different geographic locations.

However, in a multi-region AWS architecture, you might need to reference resources across regions. For example, a KMS key created in one region might need to be accessed by resources in another region.

Solution: Enabling Cross-Region References

AWS CDK offers a property crossRegionReferences: true within the stack properties to overcome this limitation. By setting this property to true, you instruct CDK to allow resources in one stack to reference resources in another stack, even if they are in different regions.

How to Apply the Solution

To implement cross-region references, you need to modify the stack properties in your CDK code. Below is an example that demonstrates how to enable cross-region references for two stacks:

Define Stack 1 (Primary Stack):
This stack is deployed in the primary region and might contain resources that need to be accessed by another stack in a different region.

const stack1 = new Stack(app, 'Stack1', {
  env: { region: 'us-east-1' },
  // Other stack properties
});

Define Stack 2 (Secondary Stack)
This stack is deployed in a secondary region and needs to access resources from Stack 1.
To enable cross-region references, add crossRegionReferences: true in the stack properties:

const stack2 = new Stack(app, 'Stack2', {
  env: { region: 'eu-west-1' },
  crossRegionReferences: true, // Enable cross-region references
  // Other stack properties
});

By setting crossRegionReferences: true in the secondary stack, you enable it to reference resources from the primary stack, regardless of the region. This solution simplifies the management of multi-region architectures in AWS CDK.

For more detailed information and advanced configurations, refer to the AWS CDK documentation and community discussions, such as those on Stack Overflow.

Removing AWS CDK Cross-Stack Reference

Like to learn more?

Find more in-depth guides on my website.
Follow me on Twitter for updates in AI, DevOps, and tech.
Connect on LinkedIn to chat or collaborate!

Resolving Cross-Region Stack References in AWS CDK was originally published in devgorilla on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR: This article explains the difference between “localhost” and “127.0.0.1” and their significance in networking. “localhost” is a domain name for accessing local network services, while “127.0.0.1” and “::1” are loopback IP addresses for IPv4 and IPv6, respectively, used for device communication. The transition to IPv6, offering a larger address space, is crucial for modern networking. This understanding is key for developers and network professionals working in local and private networks.

Local networking and development environments often hinge on two pivotal concepts: “localhost” and “127.0.0.1”. Despite their frequent use, the nuanced differences between them are not always clear to users. This article aims to shed light on these fundamental elements, providing clarity and enhancing understanding for developers and network enthusiasts alike.

Localhost: A Friendly Name for Your Local Machine

At its core, “localhost” serves as a domain name, offering a user-friendly alias for the IP address of your local computer. It’s a standardized nod to the “local” nature of the access it provides, ensuring that developers can work on network applications without affecting external environments. This term allows for an intuitive reference point, simplifying access to a machine’s network services for development and testing purposes.

127.0.0.1: The Loopback Address Defined

On the other hand, “127.0.0.1” represents an IP address, specifically designated for loopback communication within a local machine. It’s part of a broader range reserved exclusively for loopback and internal testing functions. This address facilitates the testing and development of software by directing network traffic back to the local machine, ensuring that applications can be run and tested independently of external network interfaces.

How Domain Names Resolve to IP Addresses

Understanding how “localhost” translates to “127.0.0.1” involves a peek into the domain name system (DNS) resolution process. Normally, accessing a website by its domain name requires a query to DNS to find the corresponding IP address. However, “localhost” is an exception; its resolution to “127.0.0.1” or “::1” (for IPv6) bypasses the usual DNS lookup process. This translation is hardcoded into the system’s hosts file, eliminating the need for external resolution and ensuring seamless access to the local machine’s network services.

Localhost vs. 127.0.0.1: Practical Implications and Use Cases

While both “localhost” and “127.0.0.1” aim to facilitate local development and testing, their slight distinction lies in their handling and interpretation by the operating system and network software. “localhost” can resolve to either an IPv4 or IPv6 address, offering flexibility with the potential for nuanced behavior in different environments. “127.0.0.1”, being explicitly an IPv4 address, offers predictability and straightforwardness in its role as a loopback address.

The Significance of Ports in Local Development

The concept of network ports further complicates the interaction between software and network protocols. Ports serve as endpoints for communication, allowing multiple network applications to coexist on a single device. Understanding the default ports (80 for HTTP and 443 for HTTPS) and the need for explicit port specification in certain scenarios is crucial for efficient local development practices.

Beyond Local: Private IP Addresses and the World of Networking

The discussion of local addresses leads naturally into the broader topic of private IP addresses, such as those in the “192.168.x.x” range. These addresses facilitate communication within local area networks (LANs), allowing devices to interact seamlessly in a contained environment. The allocation of these addresses adheres to established standards, ensuring that local networks operate efficiently without external interference.

The Future: IPv6 and Expanding Address Spaces

As the digital world continues to evolve, the transition from IPv4 to IPv6 addresses becomes increasingly relevant. The expansive address space offered by IPv6 addresses the limitations of IPv4, promising a future where every device can have a unique address. This evolution underscores the ongoing development of network technologies and the importance of adapting to these changes.

Conclusion

The distinctions between “localhost” and “127.0.0.1” highlight the intricacies of network communication and development environments. By understanding these concepts and their practical applications, developers and network professionals can optimize their workflows and contribute to the robustness of digital infrastructure. As technology progresses, the principles of local networking remain fundamental, guiding the development of innovative solutions in an interconnected world.

Like to learn more?

Find more in-depth guides on my website.
Follow me on Twitter for updates in AI, DevOps, and tech.
Connect on LinkedIn to chat or collaborate!

Exploring Localhost and 127.0.0.1: What is the difference? was originally published in devgorilla on Medium, where people are continuing the conversation by highlighting and responding to this story.

GraphQL and REST are two popular API architectures for building web applications. Both have been widely used for building modern applications and have their own advantages and disadvantages. In this article, we will compare and contrast GraphQL and REST, explore the benefits of each, and provide code examples to illustrate the differences.

What is GraphQL? GraphQL is a query language for APIs that was developed by Facebook in 2012. It provides a more efficient and flexible alternative to traditional REST APIs by allowing clients to request exactly the data they need, reducing the risk of over-fetching or under-fetching data. GraphQL also includes a type system that defines the data that can be fetched and the operations that can be performed, making it easier for clients and servers to understand the API.

What is REST? REST, or Representational State Transfer, is an architectural style for building web services that was first described by Roy Fielding in 2000. REST APIs use HTTP methods (such as GET, POST, PUT, and DELETE) to perform operations on resources. REST APIs typically return all the data associated with a resource, which can result in over-fetching data.

Code Examples

Let’s look at a simple code example to see the difference between a GraphQL API and a REST API.

Here is an example of a simple GraphQL query to retrieve information about a user:

query {
  user(id: 1) {
    name
    email
  }
}

And here is an equivalent REST API call to retrieve the same information:

GET /users/1

As you can see, the GraphQL query allows you to specify exactly what data you want to retrieve, while the REST API call returns all the data associated with the user resource.

Benefits of GraphQL

1. Flexibility: GraphQL allows clients to request exactly the data they need, reducing the risk of over-fetching or under-fetching data. This makes it easier to optimize performance and reduce network overhead.
2. Efficient: GraphQL allows clients to fetch multiple resources in a single request, reducing the number of round trips to the server. This can greatly improve performance, especially for mobile devices with slow or unreliable network connections.
3. Type System: GraphQL includes a type system that defines the data that can be fetched and the operations that can be performed, making it easier for clients and servers to understand the API.
4. Versioning: GraphQL has a built-in versioning system through its schema, which allows for new fields and types to be added without breaking existing clients.

Benefits of REST

1. Simple: REST is a simple and well-established architecture that provides a straightforward way to build APIs.
2. Backwards Compatible: REST APIs are typically designed to be backwards compatible, which means that new versions of the API can be introduced without breaking existing clients.
3. Widely Adopted: REST is a widely adopted architecture and has a large community of developers and tools that support it.
4. Caching: REST APIs can be cached, reducing network overhead and improving performance.

N+1 Problem

The n+1 problem is a common issue in REST API design, where multiple API calls are required to retrieve related data. For example, to retrieve information about a user and their posts, you might need to make two separate API calls: one to retrieve the user information and another to retrieve the list of posts.

In GraphQL, related data can be retrieved in a single API call, avoiding the n+1 problem and improving performance. For example, the following GraphQL query retrieves information about a user and their posts:

query {
  user(id: 1) {
    name
    email
    posts {
      title
      body
    }
  }
}

Overfetching and Underfetching

Overfetching occurs when an API returns more data than a client needs, which can result in increased network overhead and slower performance. Underfetching occurs when an API does not return enough data for a client to complete its task, which can result in additional API calls and reduced performance.

In REST, overfetching and underfetching can be a common issue as the API often returns a fixed set of data for each resource. In GraphQL, the client has control over what data is retrieved, reducing the risk of overfetching or underfetching.

Backward Compatibility

Backward compatibility is an important aspect of API design, as it allows for new versions of the API to be introduced without breaking existing clients. REST APIs are typically designed to be backwards compatible, while GraphQL has a built-in versioning system through its schema. This allows for new fields and types to be added without breaking existing clients, making it easier to evolve the API over time.

Benefits of Schema and Type System

The schema and type system in GraphQL provide a clear and concise definition of the data that can be fetched and the operations that can be performed. This makes it easier for clients and servers to understand the API and reduces the risk of misunderstandings or errors. In addition, the type system helps to ensure that the data returned from the API is consistent and accurate.

In conclusion, GraphQL and REST are two popular API architectures that each have their own advantages and disadvantages. GraphQL provides a more efficient and flexible alternative to REST, while REST is a simple and well-established architecture that is widely adopted. Ultimately, the choice between GraphQL and REST will depend on the specific needs of the project and the preferences of the development team.

Like to learn?

Follow me on twitter where I post all about the latest and greatest AI, DevOps, VR/AR, Technology, and Science! Connect with me on LinkedIn too!

GraphQL vs REST was originally published in devgorilla on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, we’ll demonstrate how to set up a GraphQL endpoint with Serverless on AWS Lambda, using Python. We’ll also show how to deploy the endpoint using Continuous Integration and Deployment (CI/CD) pipelines with GitHub Actions.

Setting up the Apollo Server

To set up the Apollo Server, we’ll use the graphene-python library, which provides a simple way to create GraphQL APIs in Python. First, create a new directory for the project and navigate into it:

mkdir graphql-serverless
cd graphql-serverless

Next, create a new virtual environment and activate it:

python -m venv venv
source venv/bin/activate

Install the required dependencies by running the following command:

pip install graphene Flask

This installs the graphene and Flask libraries.

Next, create a new file named handler.py in the graphql-serverless directory with the following code:

import graphene
import flask
from flask import Flask
from flask_graphql import GraphQLView

class Query(graphene.ObjectType):
    hello = graphene.String(description='A simple greeting')

    def resolve_hello(self, info):
        return 'Hello, Serverless!'

app = Flask(__name__)
app.add_url_rule(
    '/graphql',
    view_func=GraphQLView.as_view(
        'graphql',
        schema=graphene.Schema(query=Query),
        graphiql=True
    )
)

def graphql_handler(event, context):
    return flask.Response(app(flask.request.environ, context.respond))

This sets up the Apollo Server with a single query named hello that returns the string 'Hello, Serverless!'.

Setting up the Serverless Function

Next, we’ll set up the Serverless function to host the Apollo Server. First, install the serverless framework by running the following command:

npm install -g serverless

Create a new Serverless service by running the following command:

serverless create --template aws-python3

This creates a new Serverless service with the required configuration files.

Replace the contents of serverless.yml with the following code:

service: graphql-serverless

framework:
  name: flask

provider:
  name: aws
  runtime: python3.8

functions:
  graphql:
    handler: handler.graphql_handler
    events:
      - http:
          path: graphql
          method: post

plugins:
  - serverless-flask-binary

This configures a single Serverless function named graphql that will be triggered by a HTTP POST request to the /graphql endpoint. It also includes the serverless-flask-binary plugin, which is required for Flask to work on AWS Lambda.

Deploying the Serverless

To deploy the Serverless endpoint, simply run the following command:

serverless deploy

This will compile the Serverless function and deploy it to AWS Lambda. Once the deployment is complete, the command will output the endpoint URL, which you can use to access the GraphQL API.

Setting up the CI/CD Pipeline

Finally, we’ll set up a CI/CD pipeline to automate the deployment process using GitHub Actions. First, create a new repository on GitHub for the project and push the code to it.

Next, navigate to the Actions tab in the repository and create a new workflow. Replace the contents of main.yml with the following code:

name: Deploy

on:
  push:
    branches:
      - main

env:
  AWS_REGION: us-west-2

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v2

    - name: Set up Python environment
      uses: actions/setup-python@v2
      with:
        python-version: 3.8

    - name: Install dependencies
      run: |
        python -m venv venv
        source venv/bin/activate
        pip install -r requirements.txt

    - name: Deploy to AWS Lambda
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ${{ env.AWS_REGION }}

    - name: Deploy with Serverless
      run: |
        npx serverless deploy --aws-profile default

This workflow is triggered whenever a push is made to the main branch. It sets up the Python environment, installs the required dependencies, and deploys the Serverless endpoint using the serverless framework.

You’ll also need to add your AWS credentials as secrets in the repository. To do this, navigate to the repository’s Settings tab, select Secrets, and add two new secrets named AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY with your AWS credentials.

With the CI/CD pipeline set up, every time you make changes to the code and push them to the main branch, the pipeline will automatically deploy the changes to AWS Lambda.

Conclusion

In this article, we demonstrated how to run a GraphQL endpoint with Serverless on AWS Lambda using Python. We covered the basics of setting up an Apollo Server, deploying it as a Serverless function, and automating the deployment process using a CI/CD pipeline with GitHub Actions.

The combination of GraphQL and Serverless provides a powerful platform for building and deploying modern web applications, allowing you to take advantage of the scalability and cost-effectiveness of AWS Lambda while keeping the development process simple and streamlined.

Running a GraphQL Endpoint with Serverless — Using Python was originally published in devgorilla on Medium, where people are continuing the conversation by highlighting and responding to this story.

GraphQL?

In case you are not familiar with it, GraphQL is a data query language created by Facebook. GraphQL allows the client to select ad-hoc data. This differentiates it from REST API’s that expose pre-set data structures.

What is GraphQL?

Serverless?

Serverless pattern encourages development focus on well-defined units of business logic, without premature optimization decisions related to how this logic is deployed or scaled.

What is Serverless?

Code

Setting up the Serverless Framework

Before we start, make sure you have Node.js and npm installed on your machine. You can check this by running the following commands:

node -v
npm -v

Next, install the Serverless Framework globally:

npm install -g serverless

Now that we have the Serverless Framework installed, let’s create a new Serverless project:

serverless create --template aws-nodejs --path graphql-serverless

This will create a new Serverless project using the AWS Node.js template in a directory named graphql-serverless.

Installing the Required Libraries

To run a GraphQL endpoint, we need to install the following libraries:

npm install apollo-server-lambda graphql

apollo-server-lambda is a library that makes it easy to run an Apollo GraphQL server on AWS Lambda. graphql is the library that provides the GraphQL implementation.

Writing the GraphQL Schema

The next step is to write the GraphQL schema. This schema defines the types and the operations that can be performed on these types.

Create a schema.js file in the graphql-serverless directory with the following code:

const { gql } = require("apollo-server-lambda");

const typeDefs = gql`
  type Query {
    hello: String
  }
`;

module.exports = typeDefs;

This is a simple schema that defines a single operation hello that returns a string.

Writing the GraphQL Resolvers

Next, we need to write the resolvers. Resolvers are the functions that implement the operations defined in the schema.

Create a resolvers.js file in the graphql-serverless directory with the following code:

const resolvers = {
  Query: {
    hello: (_, __, context) => {
      return "Hello, Serverless!";
    },
  },
};

module.exports = resolvers;

This resolver implements the hello operation from the schema and returns the string "Hello, Serverless!".

Setting up the Apollo Server

Finally, we need to set up the Apollo Server.

Create a handler.js file in the graphql-serverless directory with the following code:

const { ApolloServer } = require("apollo-server-lambda");
const typeDefs = require("./schema");
const resolvers = require("./resolvers");

const server = new ApolloServer({
  typeDefs,
  resolvers,
});

exports.graphqlHandler = server.createHandler();

This sets up the Apollo Server using the typeDefs and resolvers from the previous sections.

Configuring the Serverless Function

Now that we have the GraphQL endpoint set up, we need to configure the Serverless function to run it.

Update the serverless.yml file in the graphql-serverless directory with the following code:

service: graphql-serverless
provider:
  name: aws
  runtime: nodejs12.x

functions:
  graphql:
    handler: handler.graphqlHandler
    events:
      - http:
          path: graphql
          method: post

plugins:
 - serverless-apollo-middleware

This configures a single Serverless function named `graphql` that will be triggered by a HTTP POST request to the `/graphql` endpoint. It also includes the `serverless-apollo-middleware` plugin, which is required for the Apollo Server to work on AWS Lambda.

Deploying the Serverless Function

The final step is to deploy the Serverless function to AWS. Run the following command in the `graphql-serverless` directory:

serverless deploy

This will deploy the function to AWS and return the URL of the GraphQL endpoint.

Testing the GraphQL Endpoint

You can use a tool like Insomnia or Postman to test the GraphQL endpoint.

Create a new POST request to the URL of the GraphQL endpoint with the following query in the request body:

query {
  hello
}

Send the request and you should receive the following response:

{
  "data": {
    "hello": "Hello, Serverless!"
  }
}

Continuous Integration and Deployment (CI/CD) using GitHub Actions

To automate the deployment process, we can set up a CI/CD pipeline using GitHub Actions. GitHub Actions allows you to automate your workflow by creating custom actions that run whenever a specific event occurs in your GitHub repository.

Create a new file named .github/workflows/deploy.yml in your GitHub repository with the following code:

name: Deploy

on:
  push:
    branches:
      - main

env:
  AWS_REGION: us-east-1
  AWS_PROFILE: default

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ env.AWS_REGION }}

      - name: Deploy to AWS
        uses: anothrNick/serverless-action@v1
        with:
          command: deploy

This action is triggered whenever a push is made to the main branch of the GitHub repository. It uses the anothrNick/serverless-action action to deploy the Serverless function to AWS.

Make sure to replace AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in the code above with the actual values from your AWS account. You can store these values as secrets in your GitHub repository.

Conclusion

In this article, we showed how to run a GraphQL endpoint with Serverless on AWS Lambda. We covered the basics of setting up an Apollo Server and deploying it as a Serverless function. We also showed how to automate the deployment process using GitHub Actions, allowing for a seamless CI/CD pipeline.

By using Serverless, you can take advantage of the scalability and cost-effectiveness of AWS Lambda while keeping the development process simple and streamlined. The combination of GraphQL and Serverless provides a powerful platform for building and deploying modern web applications.

With the code and steps outlined in this article, you should be able to get started with running a GraphQL endpoint with Serverless and continue building upon this foundation for your own projects.

Running a GraphQL endpoint with Serverless was originally published in devgorilla on Medium, where people are continuing the conversation by highlighting and responding to this story.

GraphQL is a query language for your API that was developed and open-sourced by Facebook in 2015. More about the “What is GraphQL”:

What is GraphQL?

The core building block of a GraphQL schema is the “type system”. A type system defines the types of data that can be queried and the fields that can be requested for each type. The GraphQL type system includes built-in scalar types (e.g. Int, String, Boolean), as well as custom types that can be defined by the developer.

The type system consists of three main types: scalars, objects, and enums.

Scalars are the most basic type in GraphQL, and include built-in types such as Int, Float, String, Boolean, and ID. These types represent the most basic pieces of data that can be queried or manipulated in a GraphQL API.

Object types are used to represent complex data structures, and are composed of fields that are either scalars or other object types. For example, a Book object type might have fields for the title, author, and reviews.

Enums are used to represent a fixed set of possible values, such as a BookStatus enumeration with values of "AVAILABLE", "CHECKED_OUT", and "ON_HOLD".

In addition to these types, GraphQL also has several type modifiers that can be used to further describe the data:

• Non-Null: ensures that a field cannot be null.
• List: allows for a field to contain a list of items, such as an array of books.
• Input: used to define input types for mutations.

GraphQL also allows for the creation of custom scalar types to represent specific types of data that are not covered by the built-in scalars.

The GraphQL type system is also used to define relationships between different types of data. This can be achieved through the use of interfaces, unions, and fields.

Interfaces define a common set of fields that multiple types must implement. For example, a Node interface might have an id field that all types that implement it must also have.

Unions allow for multiple types to be returned from a single field. For example, a search field that returns either a Book or an Author type.

Finally, fields in GraphQL can also be used to describe relationships between types. For example, the author field in the Book type would be used to describe the relationship between a Book and its Author.

Schemas

A GraphQL schema is a blueprint for your API. It defines the types of data that can be queried, the fields that can be requested for each type, and the relationships between types. A GraphQL schema is defined using the GraphQL schema language, which is a simple language for describing the structure of a GraphQL API.

Here is an example of a simple GraphQL schema that defines a `Book` type with `title` and `author` fields:

type Book {
  title: String
  author: String
}

This schema defines a single type, “Book”, with two fields, “title” and “author”, both of which are of type “String”.

Built-in Scalar types

GraphQL has several built-in scalar types: Int, Float, String, Boolean, and ID. These types are used to define the fields of your types and can be used in the arguments of your queries and mutations.

Here is an example of a query that requests the “title” and “author” fields of a “Book” type:

query {
  book(id: 1) {
    title
    author
  }
}

In this example, the “book” field is of type “Book” and accepts an “id” argument, which is of type “ID”. The fields “title” and “author” are both of type “String”.

Type definitions

In GraphQL, you can define your own types using the “type” keyword. A type definition defines a new type and its fields.

Here is an example of a type definition for a “Person” type with “name” and “age” fields:

type Person {
  name: String
  age: Int
}

Type modifiers

GraphQL allows you to modify the type of a field with the following modifiers:

• ! denotes a non-nullable field. This means that the field must always return a value.
• [] denotes a list of the type. This means that the field will return an array of the specified type.

Here is an example of a type definition that includes type modifiers:

type Query {
  books: [Book!]!
  person(id: ID!): Person!
}

In this example, the “books” field is a non-nullable list of non-nullable “Book” types, and the “person” field is a non-nullable “Person” type that takes a non-nullable “id” argument of type “ID”.

Input arguments

In GraphQL, you can pass arguments to your fields to specify additional information about the data you are requesting. These are called input arguments. Input arguments are defined using the “input” keyword.

Here is an example of a query that uses an input argument to filter a list of books by their author:

query {
  books(filter: { author: "George Orwell" }) {
    title
  }
}

In this example, the “books” field accepts an input argument called “filter” of type “BookFilterInput”. The “BookFilterInput” type is defined as:

input BookFilterInput {
  author: String
}

Input types

Input types are similar to regular types, but they are used specifically for input arguments. They are defined using the “input” keyword.

Here is an example of an input type for a “CreateBook” mutation:

input CreateBookInput {
  title: String!
  author: String!
}

In this example, the “CreateBookInput” type has two fields, “title” and “author”, both of which are non-nullable strings.

Custom Scalars

In addition to the built-in scalar types, GraphQL allows you to define your own custom scalar types. Custom scalar types can be used to represent more specific types of data, such as a date or a URL.

Here is an example of a custom scalar type called “Date”:

scalar Date

To use this custom scalar type, you need to specify a custom scalar resolver. Scalar resolvers are functions that define how to parse and serialize custom scalars.

Interfaces

Interfaces in GraphQL allow you to define a set of fields that multiple types can implement. This allows you to specify that certain types have a certain set of fields without having to repeat the fields on each type.

Here is an example of an interface called “Node” that defines a “id” field:

interface Node {
  id: ID!
}

You can then have multiple types implement this interface:

type Book implements Node {
  id: ID!
  title: String
  author: String
}

type Person implements Node {
  id: ID!
  name: String
  age: Int
}

In this example, both “Book” and “Person” types implement the “Node” interface and have a non-nullable “id” field of type “ID”.

Unions

Unions in GraphQL allow you to represent multiple types as a single type. This allows you to return multiple types in the same field.

Here is an example of a union type called “SearchResult” that can represent either a “Book” or a “Person”:

union SearchResult = Book | Person

You can then use this union type in a query:

query {
  search(query: "George Orwell") {
    ... on Book {
      title
    }
    ... on Person {
      name
    }
  }
}

In this example, the “search” field returns a “SearchResult” union type that can be either a “Book” or a “Person” type. To access the fields of the specific type, the query uses the “…” syntax to specify the type.

Enums

Enums in GraphQL allow you to define a set of predefined values for a field. This allows you to specify that a field can only have certain values.

Here is an example of an enum type called “BookGenre”:

enum BookGenre {
  SCI_FI
  FANTASY
  ROMANCE
  MYSTERY
}

You can then use this enum type in a type definition:

type Book {
  title: String
  author: String
  genre: BookGenre
}

In this example, the “genre” field of the “Book” type can only have the predefined values of “SCI_FI”, “FANTASY”, “ROMANCE”, and “MYSTERY”.

Queries

Queries are used to retrieve data from a GraphQL server. They are similar to GET requests in REST APIs. A query consists of a set of fields that you want to retrieve, along with any arguments and nested fields.

Here is an example of a query that retrieves the title and author of a book:

query {
  book(id: 1) {
    title
    author
  }
}

This query asks for the “book” field with an “id” argument of 1, and then requests the “title” and “author” fields of the returned “book” object.

The power of GraphQL lies in its ability to retrieve multiple resources in a single query. For example, you can retrieve information about a book and its author in a single request:

query {
  book(id: 1) {
    title
    author {
      name
      bio
    }
  }
}

This query retrieves the title of the book, along with the name and bio of the book’s author. This is a powerful feature that can reduce the number of requests needed to retrieve the data needed for a specific use case.

Mutations

Mutations are used to create, update, or delete data on a GraphQL server. They are similar to POST, PUT, and DELETE requests in REST APIs. A mutation consists of a set of fields that you want to modify, along with any arguments and nested fields.

Here is an example of a mutation that creates a new book:

mutation {
  createBook(input: {
    title: "The Hobbit"
    author: "J.R.R. Tolkien"
    genre: FANTASY
  }) {
    title
    author
    genre
  }
}

This mutation calls the “createBook” field with an “input” argument that contains the fields for the new book. The mutation then returns the title, author, and genre of the newly created book.

Subscriptions

Subscriptions are used to receive real-time updates from a GraphQL server. They are similar to WebSocket connections in REST APIs. A subscription consists of a set of fields that you want to subscribe to, along with any arguments and nested fields.

Here is an example of a subscription that listens for updates on a book:

subscription {
  bookUpdates(id: 1) {
    title
    author
    genre
  }
}

This subscription calls the “bookUpdates” field with an “id” argument of 1, and then requests the title, author, and genre fields of the returned book object. The server will then push any updates on the book with the specified id to the client.

Short Comparison with REST API

REST APIs are based on the HTTP protocol, and use different endpoints for different resources. A client must send multiple requests to different endpoints to retrieve all the data needed for a specific use case. This can lead to over-fetching or under-fetching of data and can make the client code more complex.

On the other hand, GraphQL allows you to retrieve multiple resources in a single request, with the ability to specify exactly what data is needed. This can reduce the number of requests needed to retrieve the data needed for a specific use case, leading to more efficient and user-friendly data-driven applications.

In REST API, for example, if you want to retrieve the details of a book, its author and its reviews, you would have to make multiple requests to different endpoints like:

GET /books/1
GET /authors/2
GET /reviews?bookId=1

In contrast, in GraphQL, you can retrieve all the same information in a single request:

query {
  book(id: 1) {
    title
    author {
      name
      bio
    }
    reviews {
      text
      rating
    }
  }
}

This not only reduces the number of requests needed but also makes the client code simpler as all the data needed is available in a single response.

Another advantage of GraphQL over REST is that it allows for more flexibility in the shape of the returned data. In REST, the shape of the returned data is determined by the endpoint being called, whereas in GraphQL, the shape of the returned data is determined by the client’s request. This allows the client to retrieve only the data it needs, and not have to filter through unnecessary data.

In summary, GraphQL provides a more efficient and flexible way of retrieving data, allowing for more user-friendly data-driven applications. It allows the client to specify exactly what data is needed, reducing the number of requests needed and making the client code simpler.

GraphQL Basics was originally published in devgorilla on Medium, where people are continuing the conversation by highlighting and responding to this story.