DEV Community: Junior Felix

The Discourse Around React Server Components

Junior Felix — Thu, 14 Mar 2024 11:26:53 +0000

On December 21, 2020, an RFC was published in ReactJs that started the React Server Components discussion. This RFC was accompanied by a YouTube video that detailed an implementation that would allow ReactJs developers to ship zero bundle-sized components. The bundle size issue frequently arises when React applications face performance issues. Consequently, over the years, the react community has developed strategies such as tree shaking, minification, code-splitting and lazy loading to reduce bundle size.

Despite solving a significant problem, React Server Components have received mixed reactions from the ReactJs community. To get a clearer picture of this discourse, let us start with an understanding of React Server Components.

Understanding React Server Components

As the name suggests, RSCs are React Components that run exclusively on the server.

During ReactJs's early years, Client Side Rendering (CSR) was the norm. Consequently, when a browser visited a website built with ReactJs, it would receive an HTML file that resembled this:

<!DOCTYPE html>
<html>
  <body>
    <div id="root"></div>
    <script src="/static/js/bundle.js"></script>
  </body>
</html>

The bundle.js file would contain all the rendering logic and include all the ReactJs code that had been written. Upon receiving the bundle.js file, the browser would parse the JavaScript and show the intended content to the user.

The problem that came with this approach is that as the application grew in complexity, the bundle size also increased. Consequently, users are likely to experience longer loading times; which is a negative in user experience.

Let's take a closer look at an example of a React Server Component:

async function ItemsPage() {
  const data = await fetch("your-api-url/items/");

  return (
    <>
      <h1>Available Items</h1>
      {data.items.map((item) => (
        <article>
          <h1>{data.title}</h1>
          <p>{data.description}</p>
        </article>
      ))}
    </>
  );
}

export default Itemspage;

In this instance, the data fetching is carried out on the server and the corresponding HTML is generated. The browser receives an HTML document without the JavaScript that was used in its creation.

Additionally, since this component is on the server, it has direct access to the server's database and filesystem.

Apart from reduced bundle size, server components offer the following benefits:

Improved data fetching: By moving data fetching to the server, the amount of network requests the client has to make is reduced significantly. Moreover, fetching data in this manner reduces the need for loading states and data query libraries; which simplifies the developer experience.
Caching: As rendering occurs on the server, the resulting HTML and assets can be cached and reused when a similar request is received. This is significantly better than re-rendering on each request; resulting in better performance.
Improves First Contentful Paint(FCP) metric: Since HTML is generated on the server, the client does not have to download and parse JavaScript before rendering. Consequently, initial load time is shortened; thus resulting in a better user experience.

Community Adoption and Response

Currently, it is not advisable to use React Server Components with React only as a library in production. Instead, React meta-frameworks are highly recommended. Among those frameworks, NextJs has emerged as the top advocate for RSCs.

It is important to note that other alternatives such as Waku and Vite RSC Experiments implement RSCs. For a simple implementation, the simple rsc repository would suffice.

React Server Components in NextJs

Vercel went all in on RSCs in their NextJs 13 rollout. They developed the App Router that is built on RSCs which provides support for features such as parallel routes, intercepting routes, layouts, loading states and error handling. Additionally, Vercel strongly recommends using the app router when building applications with NextJs.

Community Response

As mentioned earlier, the React Server Components have received mixed reactions. On one hand, we have RSC adopters who are experiencing its intended benefits. For instance, the team behind dbt docs was able to reduce page load time from 4.5s to 220ms and memory storage from 350 MB to 16 MB, as detailed here.

On the other hand, there seems to be a lot of frustration in the ReactJs community. Some of the concerns voiced in this frustration include:

Added Complexity

sauce: https://x.com/MelkeyDev/status/1655620353601974274?s=20

For a significant number of ReactJs developers, server components introduce added complexity to the development of ReactJs applications. Before server components, the decision of whether a component should be server-side or client-side wasn't a factor to consider.

Limited Documentation

Currently, apart from the basic implementation of React Server Components and NextJs documentation, there is inadequate documentation around RSC. The Next.js documentation is well-written; however, it's confined in scope as it primarily caters to individuals utilizing Next.js. Therefore, changes brought by RSC are likely to leave library maintainers at a disadvantage. This is further elaborated in this blog post by Lenz Weber-Tronic, a co-maintainer of Redux Toolkit and TypeScript Apollo Client.

RSC Makes Library Maintenance Harder

Since React Server Components run exclusively on the server, libraries have to accommodate the server context during development. Moreover, development features such as React Context and hooks such as useState are not available; hence libraries are likely to experience errors when used with server components.

Conclusion

Despite React Server Components being touted as the future, it is important to note that they don't work for every ReactJs application. At the end of the day, the goal is to provide a better user/developer experience and RSC are just a tool to get there. Therefore, it would be wise to consider if they are a good fit for the application you are building before going all in.

Additional Resources

Here are some resources that helped me understand server components better:

Introduction

Repositories That Use RSC

This Week In React is a great resource that keeps readers up to date with what's happening in
the ReactJs developer community. Kindly consider subscribing!

Revisiting GraphQL in 2023

Junior Felix — Thu, 14 Mar 2024 11:23:25 +0000

I first interacted with GraphQL in late 2019 in the Saleor open source project. At the time, it had a lot of hype around it because it came from Meta(formerly Facebook), whose engineering team had open-sourced called ReactJs. I remember finding GraphQL fascinating because the principles that inspired seemed solid and it offered solutions to problems that using REST posed. Moreover, GraphQL was adopted by companies such as Airbnb and Github which gave it legitimacy as a viable alternative to REST.

In this article, I am going to explore the current state of GraphQL, considering its evolution since my first experience with it. To accomplish this, we are going to start with a brief introduction of GraphQL.

An Introduction of GraphQL

GraphQL is a query language for APIs that empowers clients to ask for exactly what they need from pre-existing data sources. According to Wikipedia, Meta (formerly Facebook) commenced development of GraphQL in 2012 and used it internally until it was released as open source in 2015. At the time, Meta encountered limitations of the REST and thus came up with GraphQL to address these shortcomings, as outlined here. Some of these bottlenecks are as follows:

Over-fetching/Under-fetching of Data

Let’s say you’re building a user profile page in your web application and you only need the username and email of the user. Using the REST approach, you would need to perform a GET request to the /user/<id> endpoint that would return a result that resembles the following:

{
    "id": "randomIdFffs",
    "username": "chaduser",
    "email": "gigachad@ayahoo.com",
    "createdAt": "2023-15-05 23:04:42",
    "address": {..},
    "verified": "false"
}

In this scenario, the client does not need the other fields apart from username and email; thus resulting in over-fetching. While this might not noticeably impact performance in a small application, it becomes problematic in a larger application. Over-fetching can lead to increased response times and unnecessary bandwidth consumption, negatively affecting the overall user experience. On the other hand, GraphQL clients can specify the exact data they need; thus avoiding the overfetching problem. Using the above scenario, we can structure our query to only fetch username as follows:

query{
    User(id: "randomIdFffs") {
        username
        email
    }
}

By performing the above query, you will retrieve only the "username" and "email" properties of the user.

Using the same analogy, let’s say we want to display a user’s posts on the user profile age, including the post titles and descriptions. The current API request (a GET request to /users/<id>) does not provide us with the additional information we need. To implement this feature, we would need to make another GET request, thus showcasing the under-fetching problem of using REST APIs. In contrast, GraphQL allows you to get all the data you need in one query. The above scenario can be executed as follows:

query {
  User(id: "") {
    username
    email
    posts {
      title
      description
    }
  }
}

Multiple Endpoints

When working with REST APIs, the use of multiple endpoints can be a pain in large-scale applications. Let’s say we are building a blog website and we need to display each of our posts in their own pages. To accomplish this, we may need three endpoints:

/posts/<id> to retrieve post content.
/users/<id> to retrieve author information.
/posts/<postId>/comments to retrieve post comments.

Using this approach would result in multiple round trips; just to retrieve a single blog post; thus showing the inefficiency that comes with the REST methodology. Moreover, additional client-side logic would be needed to ensure that the data is retrieved in the right sequence.

On the other hand, GraphQL facilitates the querying of multiple resources from a single endpoint; thus eliminating the drawbacks that come with multiple endpoints. Additionally, the need for multiple round trips to the server is eliminated since all this information can be retrieved with one request.

API Versioning

In REST APIs, it is common practice to version APIs whenever a breaking change is introduced. Consequently, we may end up having multiple versions of the same API; thus leading to more work since we need to maintain the aforementioned versions.

For instance, let’s say we are renaming the username property in our user entity to name. To ensure that our API consumers’ applications don’t break, we may introduce a new version such as /api/v1/users or /api/users?version=2 depending on our versioning strategy. In GraphQL, there’s more flexibility when it comes to introducing changes to APIs. Using the aforementioned analogy, we may choose to deprecate the field that we are changing instead of removing it completely while introducing the new field. By using this method, the API consumer can incrementally update their schema while maintaining backward compatibility. An example of this can be as follows:

type MyType {
  id: ID!
  oldField: String
    @deprecated(reason: "oldField is deprecated. Use newField instead.")
  newField: String
  deprecatedField: String @deprecated
}

Moreover, GraphQL has introspection abilities that allow a client to explore the schema as it is being updated.

Under-Documented APIs

In some cases, REST APIs lack consistent and adequate documentation; hence making it difficult for API consumers to effectively utilize the APIs. While tools like Spot can be utilized to document APIs, regularly updating the APIs can introduce additional overhead in terms of API maintenance.

On the other hand, GraphQL leverages its introspection capabilities to provide a well-defined schema with detailed field-level documentation. Moreover, GraphQL tools such as GraphiQL and GraphQL playground provide an interactive IDE where one can explore the schema, run queries, and view documentation on the fly.

The Current State of GraphQL

Evaluating the current state of a specific technology can be challenging as there is often a lack of consensus on the criteria to use. However, I shall take upon this challenge while exploring the following factors:

Developer surveys
Case Studies
VC Funding

Developer Surveys

To gauge the level of interest in GraphQL, I am going to depend on statistics from the following sources:

Postman’s State of the API Report

The annual State of the API report provides key information regarding the API development landscape; which includes GraphQL interest levels over the last few years. Under the category “Future technologies”, survey respondents were asked about the technologies they were most excited to use. From 2018 to 2022, GraphQL managed to be among the top 5 technologies mentioned with the following trajectory.

Based on the graph, it is evident that GraphQL peaked in interest in 2019, receiving a significant interest level of 36.9% from the survey respondents. It is also important to note that there has not been an extreme increase or decrease in its numbers over the years.

Under the category “Architectural style”, data from 2020 to 2022 was available and revealed the following:

GraphQL was also listed among the API specifications used by respondents in the survey's "Specifications" section, and the numbers were as follows:

The statistics on both API specifications and architectural styles indicate that GraphQL is being utilized in API development. However, it doesn't show a significant wave suggesting that it is completely overtaking the industry. At the same time, we do not see a sharp decline in its use that would suggest that GraphQL is “dying”.

The sources for all the above data are as follows:

State of JavaScript Surveys

Before we dive into the numbers, it is important to acknowledge the caveats that come with the State of JavaScript survey as compared to Postman’s State of the API survey. Firstly, it's important to note that the pool of respondents for this survey is limited to JavaScript developers, unlike Postman's surveys which typically gather responses from developers of various programming languages.

Furthermore, JavaScript developers are generally more likely to be familiar with GraphQL since it was originally developed by Meta, the same company that created ReactJS. Additionally, the State of JavaScript opted to remove GraphQL statistics from its survey in 2021 as it seemed out of place. Luckily, we still have numbers from 2016 to 2020. In the data layer section of these surveys, GraphQL statistics were as follows:

Source: The State of JavaScript

From these numbers, we can infer that GraphQL has been gradually gaining popularity over the years among JavaScript developers. This can be attributed from:

The declining number of respondents who’ve never heard of GraphQL; from 36.6% in 2016 to 2.3% in 2020.
The growing number of respondents who are interested in GraphQL (combining both those who’ve used it and those who wish to learn); from 50% in 2016 to 88.1%.
The declining number of respondents who would not use GraphQL; from 13.8% in 2016 to 6.8%.

Case Studies of GraphQL Adoption

Various industry leaders have publicly endorsed and documented their adoption journeys with GraphQL. Analyzing these experiences reveals comparable challenges to those encountered by Meta, as previously discussed in the introduction. To get a clearer picture, let’s explore two specific adoption journeys: Cousera’s and Paypal’s.

Coursera’s Adoption Journey

Before adopting GraphQL, Coursera implemented a “resource-based” approach in the development of the API infrastructure (meaning an API for courses, another one for instructors, grades, and so on). Consequently, the number of APIs grew over time which led to issues such as multiple server round trips, maintaining documentation, and performance issues.

Coursera’s Initial Implementation Process

Initially, the Coursera engineering team opted to add a GraphQL layer that integrates the pre-existing REST APIs. In this implementation, the core business logic did not live in GraphQL itself but in the underlying services. This approach can be better understood through the following diagram.

This implementation had the following key features:

It consisted of a single GraphQL layer that acted as a proxy between incoming requests and the underlying services.
Naptime and Sangria were used to generate a unified GraphQL schema.
Teams could retain ownership over their individual services.
It was easier to integrate pre-existing services into the GraphQL schema.
Changes could only be previewed in production.

The setup’s flexibility empowered Coursera’s engineering team to successfully realize their goal of enabling clients to define the structure of the data they want from the API. Furthermore, they managed to achieve this without a complete overhaul of their existing infrastructure.

Current State of GraphQL at Coursera

Since its first implementation of GraphQL, Coursera has been re-evaluating its GraphQL approach as challenges arise. Initially, they had adopted a data-first approach, prioritizing the client’s retrieval of necessary data from the API over the schema’s quality. Consequently, the schema grew to encompass over 7000 GraphQL types, increasing the likelihood of duplication within these types. Moreover, the inability to preview changes from underlying services prompted testing them in production, which is not an ideal practice.

To address these challenges, Coursera is actively moving towards a schema-first approach that will prioritize schema quality over its quantity. This strategic shift aims to fully leverage the benefits offered by GraphQL. More on this can be found here.

Paypal’s Adoption Journey

PayPal began its GraphQL adoption by overhauling their checkout application to use GraphQL, prompted by the limitations they encountered while using REST. These constraints include overfetching/underfetching of data, multiple round trips, and keeping up with new API versions, as indicated here. The issue of multiple round trips led to slower rendering times, subsequently causing user frustration and a decrease in checkout conversion rates.

PayPal’s Initial Implementation Process

Before embracing GraphQL, PayPal's checkout team investigated Bulk REST, a method that empowered clients to define the specific structure and volume of data they required. In this approach, the request would resemble this structure:

{
  "user": {
    "method": "get",
    "uri": "/api/user"
  },
  "createCheckout": {
    "method": "post",
    "uri": "/api/checkout/ec-1234",
    "params": { "total": "10.00", "currencyCode": "USD" }
  },
  "getCheckout": {
    "method": "get",
    "uri": "/api/checkout/ec-1234",
    "dependencies": ["createCheckout"]
  }
}

The response to the above request would resemble the following structure:

{
  "user": {
    "ack": "success",
    "data": {
      "name": "Mark Stuart",
      "hobbies": ["chess", "painting"]
    }
  },
  "createCheckout": {
    "ack": "success"
  },
  "getCheckout": {
    "ack": "success",
    "data": {
      "shippingAddress": "123 Main St, San Jose, CA 23434",
      "fundingOptions": ["Visa", "SVB"]
    }
  }
}

Although this approach enabled clients to specify the desired structure and size of the data, it also brought about the following issues:

Clients still needed to understand the API’s inner workings: While specifying the request, the clients had to be explicit with the method and URI needed. Consequently, more time was spent on configuring data fetching as opposed to actually building user interfaces. This led to an unfavorable developer experience for those focused on UI development.
Overfetching was still a problem: Even in this approach, entire resources were being fetched as opposed to specific fields that were needed.

Since Bulk REST failed to solve their problems, the team at PayPal opted for GraphQL. This choice brought about these benefits:

Performance Improvements: The clients’ ability to specify their required data in a single request effectively resolved the problem of multiple rounds.
Developer Productivity: Unlike Bulk REST, developers did not need to understand the inner workings of the API. Furthermore, GraphQL delivers the necessary data in JSON format, which is a more comprehensible concept.
Evolution: GraphQL enabled Paypal’s engineering team to know which fields are utilized by clients, thus simplifying the process of deprecating unused fields.

The Current State of GraphQL at PayPal

The adoption of GraphQL within PayPal has grown to the extent that it now serves as the default pattern for developing new UI applications. This progress culminated in the release of a public GraphQL API, providing concrete evidence of the substantial advantages derived from embracing GraphQL.

To reach this point, PayPal had to undertake the following actions to ensure the scalability of GraphQL:

Standardizing GraphQL API definitions internally: These guidelines indicated naming conventions, header standards, directive standards, and error handling strategies.
Enforcing Authorization with Special Directives in GraphQL Operations: In this directive, every operation, such as queries and mutations, is required to explicitly outline authorization prerequisites. Consequently, the security and privacy of sensitive data are maintained.
Providing Essential Tooling for GraphQL Implementation: As Paypal aimed to standardize GraphQL practices across the company, it became logical to implement common tools/libraries for common concerns. These shared aspects include logging, directives for data-classification, middleware for Apollo and playground, CLI, error classes, and Apollo graph variants.
Providing Adequate Support to Developers: This assistance was provided through resources designed to onboard teams onto GraphQL, template samples for both backend and frontend development, and dedicated Slack channels established to address questions related to GraphQL.

As indicated in this article, PayPal is moving towards implementing a “centralized graph” instead of every team maintaining its own graph. The purpose of this strategy is to uphold consistent GraphQL standards across engineering teams, as certain individual graphs were diverging from the established guidelines. Furthermore, this initiative aims to foster schema sharing within the organization.

VC Funding

Regarding venture capitalist funding, companies offering GraphQL tools and infrastructure have continued to successfully close funding rounds. Some of the highlights in recent years include:

Apollo GraphQL Raising $130 Million in Series D

Apollo GraphQL is a key figure in the GraphQL space; with the widespread use of their open-source tools that include GraphQL clients and servers. I have worked with React Apollo Client and Apollo Server in several projects. Based on my personal experience, these tools have greatly enhanced my developer experience and enhanced my comprehension of GraphQL.

On 17th August 2021, Apollo GraphQL declared the successful closure of its Series D funding round. This funding round was accompanied by the following objectives, as outlined in their announcement post:

Developing Open-Source Software: Aside from their current offerings, such as Apollo Client and Apollo Server, Apollo GraphQL is actively exploring new ideas in the GraphQL ecosystem. Additionally, Apollo GraphQL is aiming to invest in developer education around GraphQL.
Expand Apollo Federation to include more programming languages: A common challenge frequently encountered by large engineering teams that implement GraphQL is the management and organization of their numerous graphs. Consequently, industry leaders such as PayPal and Walmart are leaning towards federation architecture that combines multiple subgraphs into one supergraph. Apollo Federation aims to adopt this strategy while extending its support to additional programming languages, thereby rendering the process more accessible and manageable.

WunderGraph Raising $3 Million in Seed Funding to Build GitHub for APIs

WunderGraph is a framework that enables developers to compose multiple APIs into one interface. Additionally, it allows developers to create code pipelines that introspect the various APIs within the unified API structure, resulting in an optimized developer workflow.

On 26th April 2023, the team behind WunderGraph announced that they had raised $3M in seed funding for their “Github for APIs” project. The general idea of this endeavor is to treat APIs as dependencies; similar to how we handle npm packages for JavaScript, modules for Golang, and cargo for Rust. Currently, WunderGraph enables developers to combine APIs; and it holds promise in expanding its toolset and ecosystem to bring this vision to fruition.

Conclusion

Throughout our recap of GraphQL, the growth of GraphQL is evident. Moreover, its unique approach to data query and manipulation has not only withstood the test of time but has also grown to address the challenges faced by large engineering teams. Going into this deep dive, I had the following questions:

Is GraphQL Dying?

My answer is no. Factors such as substantial venture capital funding and the growing awareness of GraphQL as shown by the survey numbers refute this claim. However, it doesn't appear poised for the exponential growth it experienced during the peak of its popularity in 2019 and 2020.

Is GraphQL Going to Replace REST?

My answer is no. Although it addresses the shortcomings of REST, GraphQL has its own fair of challenges that have already been addressed in REST. Hence, there are scenarios where GraphQL may prove less advantageous when compared to REST.

At the end of the day, technology is very dynamic; making it even more intriguing to watch. Perhaps a future day will witness GraphQL replacing REST completely or GraphQL “dying”. When that day comes, I look forward to revisiting the topic in another article. Till next time!

Featured Photo by Kaleidico on Unsplash

Becoming an AWS Solutions Architect Associate

Junior Felix — Thu, 14 Mar 2024 10:30:31 +0000

It has been a while since I got certified as an AWS Solutions Architect - Associate level; thus, I wanted to share my journey through it all. I’m hoping that this article provides insight to anyone who plans on studying and eventually taking the exam.

Reasons for getting the certification

I’m a software developer(insert surprised Pikachu) who has done quite a bit of front-end work. I’ve been looking for an opportunity to improve my knowledge of the back-end side of things. Thus, I began looking at the available AWS Certifications I could study in the hopes that I would learn more things.

Choosing which certification to take

The AWS Certifications that I felt I could take were as follows:

AWS Certified Cloud Practitioner: This is a foundational level certificate that is aimed at individuals that have no prior experience with AWS. Even though I fit the bill for this certificate, I chose to skip it. From my perspective, just knowing what AWS services do wouldn’t help me improve my technical skills as a developer.
AWS Certified SysOps Administrator – Associate: This is an associate-level certificate that targets individuals who are in or aspire to be in a Systems Administrator role. Since being a sysadmin isn’t in my immediate plans, I chose not to take it. (Plus, it seems quite challenging. Not saying that the others are easy, but this one seemed to be quite something.)
AWS Certified Developer - Associate: This is an associate-level certificate that goes deeper into AWS services that revolve around software development such as Elastic Beanstalk, SQS, and SNS. I’ll admit it; the term “Developer” in the title was appealing. Instead, I chose its counterpart that had a more inviting name.
AWS Certified Solutions Architect - Associate: This is an associate-level certification that covers a wide range of AWS services that focus on the design of an application that runs on AWS. It equips one with the skills to design a solution on AWS that balances the key pillars of a well-architected solution: Operational Excellence, Security, Reliability, Performance, and Cost. It allows you to see all these beautiful moving parts of software and its underlying infrastructure work in harmony to serve the intended customer. It’s like being a conductor in an orchestra. (No, I take that back. It’s really not that cool). Plus, it has the word “Architect” in the title.

I eventually chose to go for the AWS Certified Solutions Architect - Associate.

💡 All these definitions are from my perspective. To get a clearer explanation of all these certifications, please visit the official AWS documentation here. (The badges are clickable on the page in case you get confused when you get there). Also, this article here gives a clearer definition of the certifications if you’re stuck on deciding which certificate to go for.

After deciding on which certification to take, I started gathering information on resources I could use to successfully get it.

Resources I Used

In the information-gathering phase, I was overwhelmed by the wealth of information that is present on the internet. However, I was lucky to find a community on Reddit called r/AWSCertifications that provided useful information as well as user testimonials on what they used to pass the certification. From the discussions in the subreddit, I narrowed my options to two courses:

Stephane Maarek’s Udemy SAA-C03 Course: As a complete beginner in AWS, this course gave me an adequate introduction; one that didn’t make me feel overwhelmed. Additionally, following through with the lectures while doing the hands-on exercises significantly helped in understanding the AWS ecosystem. Moreover, Stephane provides explanations on programming concepts such as CORS from a beginner’s perspective.
Tutorials Dojo Practice Exams for SAA-C03: After completing Stephane’s course, I began doing practice tests on Tutorials Dojo. Here, I was humbled by my test scores in the practice tests. Here’s a picture of the practice test I took:

While completing Stephane’s course made me feel like a had a good grasp of AWS, my lack of in-depth knowledge showed in the practice tests. After getting bad scores on my practice tests, I decided to highlight the areas where I scored poorly and revise these areas thoroughly before moving to the next practice. Thankfully, Tutorials Dojo gives detailed explanations of each question and answer after completing each practice test.

AWS Whitepapers: The available AWS whitepapers cover a huge range of issues surrounding the AWS ecosystem. For me, the Well-Architected Framework and Disaster Recovery proved very useful in understanding why certain actions are considered best practices.
AWS Architecture Centre:The AWS documentation not only offers whitepapers, but also provides architectural diagrams. You can refer to these diagrams to enhance your comprehension of AWS solutions. These diagrams illustrate how various AWS services can be integrated to build highly scalable and resilient applications.

I continued with my preparations until I felt confident enough to take the AWS Certification. In this phase, I would go over areas I found challenging and do practice tests to identify my weaknesses.

💡 Practice tests can be a trap, sometimes. There are cases of people passing practice tests and still failing the certification exam. This article here details how you can leverage practice tests to your benefit.

Taking the Test

For the certification examination, I opted to use a testing center near me. I did not want to worry about the technical stuff like setting up the OnVue testing software. Additionally, I was worried about scenarios like experiencing a power outage while taking the test or the neighbor's dog deciding to bark loudly on that particular day. True to my concerns, on the day I had scheduled my exam, my power went out.

Fortunately, I was able to do the certification exam at the testing center on time. The questions felt familiar to me because I had encountered similar situations in my practice tests. They weren't exact replicas of my practice tests, but the thought process required to arrive at an answer was similar.

After a couple of days, my results came in my mail. I managed a passing score of 772/1000.

My Takeaways From The Process

When I was starting this process, I hoped to learn more about back-end software development. At the end of the process, I realized I got more out of the process than I had anticipated. There are concepts I knew about that were reinforced by learning about how AWS implements them. Additionally, I was introduced to new concepts (to me) that I found fascinating. Here are some of the concepts I found intriguing.

Least Privilege Principle

Sauce: https://tenor.com/view/ziekenhuisbal-steward-guard-security-guard-guard-check-gif-15705678

In my personal experience, access has always been a key factor in security; whether on the internet or in real life. This was reiterated when I was studying the IAM (Identity and Access Management) section of AWS. With the least privilege principle, individuals are only given permission that they need to perform their duty. AWS provides enough tools that facilitate the implementation of this principle. Some of these tools/techniques include:

IAM Groups: In this method, instead of assigning permissions to an individual user, a group is created and has permissions assigned to it. Afterward, the users are assigned to the created groups. This allows the admin to monitor the privileges granted to many users from a central point; thus making oversight easier.
IAM Access Advisor: This tool shows services granted to a user and service last accessed information; which is critical when determining if a specific user needs certain permissions. Together with AWS Organizations and Service Control Policies, it can be used to enforce permission restrictions on AWS. More information can be found here.
AWS CloudTrail: This AWS service tracks all the activity on your AWS service. Through CloudTrail logs, an audit of everyone’s activities within an AWS account can be conducted. Furthermore, you can do a deep dive into these logs using advanced analysis tools; if the need arises.

Living on the Edge

Sauce: https://imgflip.com/i/7io09o

Recently, applications have continued to grow a global audience; which has prompted the need to cater to consumers around the world. Hence, we have the edge. Since AWS has multiple regions and availability zones around the globe, leveraging its infrastructure can be significantly beneficial to a global business. Some of the services that involve the edge include:

Amazon CloudFront: This is AWS’ global Content Delivery Network (CDN) that distributes videos, files, APIs, applications, and data to the intended consumers. In addition to content delivery, additional features such as geo-restriction, firewall setup, and DDoS protection measures can be implemented here. Additionally, using caching strategies can be deployed using CloudFront; hence making response time faster.
AWS Lambda@Edge: In conjunction with Amazon CloudFront, you can deploy functions that execute at the edge locations instead of a centralized location. This service can be beneficial in situations such as conducting A/B testing on your application. Additionally, you can modify headers and cookies before forwarding the request to the origin. For more information, see here.

There are significant contributions made in the edge space: varying from deploying functions at the edge to database edge databases by companies such as Vercel and Cloudflare. It will be interesting to see how computing at the edge develops in the future.

Managed Services

Sauce: https://media.giphy.com/media/BY8ORoRpnJDXeBNwxg/giphy.gif

In a managed service, users are only concerned with using the service and are not required to know the setup details. For instance, let’s say we want to use a database to use for a web application. We can decide to implement it in two ways:

Using Amazon Aurora: In this scenario, we won’t have to provision a server to host our database. Additionally, if auto-scaling is enabled, we are not required to monitor our database to ensure that it can handle the load it gets. Furthermore, we do not have to manually update Aurora when there’s a new update.
Using a PostgreSQL/MySQL Instance on a Live Server: In this instance, we have to provision resources and monitor our database to ensure that it appropriately handles its load. Moreover, we have to manually set up backups and deploy updates.

From a glance, it may seem like managed services are the better option; since they can significantly reduce the overhead that comes with the alternative. However, there are concerns, such as vendor lock-in, that eliminate the possibility of managed services being viewed as a silver bullet for all the problems that other frameworks provide.

Serverless Ecosystem

Sauce: https://imgflip.com/i/7insfr

Over the years, serverless architectures have gained traction. The idea of not having idle servers when there is no traffic was what sold me on going serverless. Moreover, the automatic scaling that comes with serverless is also advantageous when dealing with unexpected workloads. In the AWS ecosystem, these services help in creating a serverless solution:

AWS Lambda: This service enables a user to deploy functions regardless of the programming language used.
Amazon API Gateway: Using this service, RESTful APIs and WebSocket APIs can easily be deployed. By using the Amazon API Gateway to invoke AWS Lambda, our Lambda functions can be reached through HTTP endpoints, which leads to a completely serverless configuration.
Amazon DynamoDB: This is a NoSQL, serverless database that auto-scales based on demand.

There are more AWS services under the serverless umbrella; you can find them here.

What’s Next?

Currently, I don’t intend on taking another associate-level AWS certification exam; despite it being an attractive option. Instead, I would like to apply the foundational knowledge I have acquired on building resilient systems and explore open-source alternatives to AWS's proprietary tools. I also hope to gain more experience in designing solutions on AWS. I also plan to take the System Design Roadmap.

Thank you for taking the time to read this to the end! If you are planning to take the SAA-C03 examination I wish you the best of luck.

💡 This article provides a detailed analysis of the value of certifications in the tech industry.

Featured Image Credit: Mehmet Ali Peker onUnsplash

Next.js 14: Skeptical Observations

Junior Felix — Thu, 14 Mar 2024 10:21:24 +0000

A few releases ago, I'd wholeheartedly recommend Next.js to both friends and foes whenever a React frameworks discussion arose. With this latest release, my enthusiasm has waned. Next.js has taken a more "futuristic" persona, moving at a blazingly fast pace, and it feels like a significant portion of its community is being left behind. In this article, I will narrow my focus on the release of Next.js 14, and my concerns related to it.

Next.js 14 Release Notes

The cliff notes from this release are:

No new APIs.
Performance improvements for Turbopack.
Server Actions are stable now.
Partial Prerendering can be previewed now.

💡 The official release blog post provides a more in-depth explanation. Click here to read, but kindly come back! I'm not done yet.

My Concerns with this Release

The Canary vs. Production Conundrum

With certain decisions, Next.js blurs the line between experimental and stable features. Some of these decisions include:

Turbopack's premature promotion: It is concerning that despite Turbopack not passing all the tests for both App router and Pages router, it is prominently featured in the official release notes as a significant improvement. Moreover, these margins of improvement are boldly highlighted despite its unstable nature. It is worth noting that Turbopack is not the default bundler when running the next dev command, further contributing to this ambiguity.
Server actions confusion: Recently, the React team shared a post on X announcing the availability of server actions in React Canary, as shown here. From the replies, you can tell that the developer community is confused if server actions are a feature of Next.js or React. Additionally, the presence of server actions in React Canary implies their instability within React, even though they may be considered stable in the context of Next.js. The lingering ambiguity adds to the complexity of the situation.

Reevaluating the Major Release Label

Despite Next.js 14 being a major release, it lacks the substantial changes that are typically associated with major releases. The nature of the updates included in this release is more aligned with what I'd expect from a minor release. It's worth noting that Next.js has a relatively high frequency of version releases, especially when we consider that version 1 was initially released in October 2016.

Introducing Partial Prerendering

The Next.js 14's accompanying blog post acknowledges the complexities introduced in prior releases. However, in the next paragraph, Next.js 14 introduces partial prerendering, which adds further complexity. While it does not introduce new APIs, it is probably a new concept to many which does not make it any easier digest. Additionally, the release does not provide a lot of details on it; and promises to do so in a future minor update.

Conclusion

Contrary to the skepticism I've expressed in this article, I'm still bullish on Next.js. I recognize their willingness to push the React community forward, but at the same time, I'm not sure if this is the way to get us there. Maybe, this is similar to the pushback React faced when it was first introduced to the JavaScript community. However, I am no wizard with a pondering orb to make those conclusions.

Integrating Bun: A Developer’s Journey

Junior Felix — Thu, 14 Mar 2024 01:26:45 +0000

I have often thought of the JavaScript ecosystem as a free market; where multiple solutions to the same problem can co-exist. In this dynamic environment, new tools can emerge and gain prominence by addressing the specific needs of developers. Recently, Bun has been the cause of “buzz” in the JavaScript “marketplace” with the release of Bun 1.0.

Bun is a new JavaScript runtime and toolset that aims to fulfill the needs of the modern JavaScript ecosystem. Bun’s selling points include:

Speed: Bun extends the JavaScript Core engine, which prioritizes speed and powers Safari(the browser). In contrast, Node.js and Deno use the V8 engine that powers Chromium.
Better Tooling: Aside from being a runtime, Bun also serves as a bundler, package manager and test runner.
Node.js Compatibility: Bun is a drop-in replacement for Node.js; meaning you can run Node.js projects with Bun without significantly changing your code.

As a JavaScript/TypeScript developer, I found Bun's pitch to be quite compelling. Therefore, I set off on a journey to personally evaluate the noteworthy benefits it promises.

Getting Started

Before picking tools/libraries for my development workflow, I ask myself these three questions:

Does it prevent me from shooting myself in the foot?
This question mainly focuses on questioning a tool's or library's reliability and safety. It's about choosing a tool or library that has enough safeguards to protect against unintended consequences or potential missteps.
Does it get in my way when I'm rolling out new features?
This question assesses a tool's adaptability and user-friendliness. If a tool is a roadblock during feature development, it may not be the right fit.
Will it cost me more to use?
In addition to assessing the financial aspect, I consider the tool's resource demands. This involves memory usage, computational power, time consumed and other software or hardware resources it may require.

With these considerations in mind, I started the process of integrating Bun into my Node.js/Express API.

Initial Setup

My local development environment had the following key features/components:

Application Stack: Node.js/Express application
Language: TypeScript
Database: PostgreSQL
Deployment Tool: Docker
Process flow:
- Code is written in TypeScript(".ts")
- Transpilation from TypeScript to JavaScript
- Node.js/Express server serving the application
- PostgreSQL for data storage
- Docker containers for running both the API and the Database.

The main benefit of this setup was the ability to operate the application in a self-contained environment, offering enhanced portability and isolation. Additionally, with this setup, I could start up my application in two commands; docker compose build and docker compose up. Moreover, the "it only works on my machine" issue is dealt with.

The Integration Process

In the reconfigured setup, I wanted Bun to serve the following roles:

As a Runtime: Bun is capable of executing TypeScript without requiring a transpilation step; thus simplifying the development. Moreover, Bun allows you to run your application in watch mode without installing another package.
As a Package manager: Bun would replace npm in executing scripts in my project. Since Bun's main selling point is speed, I'd reap the intended benefits.

Installation

First, I had to install Bun locally. To accomplish this, I run the following command on my Ubuntu computer:

curl -fsSL https://bun.sh/install | bash

Afterward, I ran bun install in my project's root directory. This action generated a bun.lockb file. This is a binary file that serves a similar role as yarn.lock and package-lock.json. The key distinction from the previously mentioned lock files lies in its binary format, which enables bun.lockb to store more data and load swiftly, resulting in enhanced performance.

Streamlining Dependencies

Since Bun executes TypeScript out-of-the-box, we can remove the npm packages we added to support TypeScript. These packages include:

@types/node: Provides types for node.js runtime
ts-node: Provides a TypeScript execution engine and REPL for Node.
nodemon: Provides hot reloading by automatically restarting Node.Js upon file changes.

I removed all these packages by running:

bun remove @types/node ts-node nodemon

Afterwards, I added the package bun/types using the command:

bun add bun-types

I also edited the tsconfig.json file to include bun-types in the global scope as follows:

{
  "compilerOptions": {
    "types": ["bun-types"]
  }
}

Updating the "dev" script

Before running the application, I added the following script in my project's package.json:

{
  "scripts": {
    "dev": "bun --watch run ./src/index.ts"
  }
}

Updating the Dockerfile

Initially, this was my Dockerfile.dev:

FROM node:14-alpine

WORKDIR /app

COPY . .

RUN npm install

CMD ["npm", "run", "dev"]

I updated it to this:

FROM oven/bun:1 as dev
WORKDIR /usr/src/app

COPY package.json bun.lockb ./

RUN bun install

COPY . .

CMD ["bun", "run", "dev"]

My docker-compose.yml file remained as follows:

version: "3.8"
services:
  db:
    image: postgres:15.2-bullseye
    restart: always
    environment:
      POSTGRES_DB: bookclub
      POSTGRES_USER: master
      POSTGRES_PASSWORD: root
    ports:
      - 5432:5432
    volumes:
      - bookclub-postgres-data:/var/lib/postgres/data

  api:
    build:
      context: .
      dockerfile: Dockerfile.dev
    depends_on:
      - db
    volumes:
      - .:/app
    env_file:
      - ./env/.env.development
    ports:
      - 4000:4000
    restart: always

volumes:
  bookclub-postgres-data:

By following these steps, I successfully configured Bun as the runtime and package manager for my Node.Js/Express application. I got a running application at http://localhost:4000 after running the docker compose build and docker compose up commands.

Impact on Workflow

After switching to Bun, my setup became faster and used less space. Running both setups in GIthub Codespaces yielded the following results:

Running docker compose build on the Node.Js setup finished in 69.2s as shown below:

Running docker compose build on the Bun setup finished in 26.4s as shown below:

The docker image sizes also differ for both setups. The results were as follows:

For the Node.Js setup:

For the Bun setup:

Caveats

Bun is still relatively new

Since this is version 1, users will occasionally run into unlikely bugs. I experienced this issue myself during my initial installation of Bun. When I ran bun run index.ts, there were no logs or feedback on my terminal. Fortunately, a fix was released shortly after my encounter, and I was able to get rolling.

Challenges in Cloud Provider Integration

Due to Bun being relatively new, cloud providers have not rushed to provide supporting infrastructure for it. Consequently, there are cases where Node.Js outperforms Bun due to the optimizations these providers have implemented for Node.Js. The following articles outline this issue in the context of AWS lambda; where performance is very important:

Bun has backward compatibility issues

When Bun 1.0 was released, libraries such as Pino and Fastify had problems working with Bun because Bun did not support all Node.js APIs, as indicated here. This resulted in the lead maintainer of Fastify giving this response on Twitter to clarify this issue. Again, Bun is relatively new and these issues are expected as they iron them out.

Conclusion

Bun feels like a true challenger to Node.js, the default runtime for people who want to run JavaScript or TypeScript on the server. While there are many unknowns with Bun, especially regarding the success of its all-in-one approach, it's been a while since I've felt this excited about a new JavaScript runtime. As a participant in the JavaScript marketplace, I'm always rooting for alternate solutions to the problems we face as developers.