
# Securely Managing API Keys - Next.js vs. Angular

<time>January 17, 2025</time>

![Image ...](/images/posts/api-keys/api-keys.jpg)

When building modern web applications, securely managing sensitive information like API keys is a critical concern. This question recently came up while I was working on a project integrating OpenAI's API, where protecting the API key was crucial to prevent unauthorized usage and potential cost implications. Whether you're using React, Next.js, or Angular, the handling of API keys requires thoughtful implementation to prevent them from being exposed to the client-side or intercepted by malicious actors. This article shows the different approaches for each technology, highlighting how to keep your keys secure.

## Next.js API Key Management

Next.js, a React framework, provides built-in server-side capabilities that simplify secure API key handling. You can use API keys safely in three main ways:

### 1. API Routes

The **/api/route.ts** files run exclusively on the server, making them perfect for secure API key usage:

```typescript
export default async function handler(req, res) {
  const apiKey = process.env.API_KEY;
  const response = await fetch("https://example.com/api", {
    headers: { Authorization: `Bearer ${apiKey}` },
  });

  const data = await response.json();
  res.status(200).json(data);
}
```

### 2. Server-Side Props

```typescript
export async function getServerSideProps() {
  const apiKey = process.env.API_KEY;
  const data = await fetchSecureData(apiKey);

  return {
    props: { data },
  };
}
```

### 3. Static Props (Build-time)

```typescript
export async function getStaticProps() {
  const apiKey = process.env.API_KEY;
  const data = await fetchSecureData(apiKey);

  return {
    props: { data },
  };
}
```

## Angular API Key Management

Angular now offers two approaches to API key security, depending on whether you're using Server-Side Rendering (SSR) or not.

### With Angular Universal (SSR)

Angular Universal allows you to handle API keys securely on the server side, similar to Next.js:

```typescript
// server.ts
app.get("/api/data", (req, res) => {
  const apiKey = process.env.API_KEY;
  // Make secure API calls here
});

// component.ts
@Injectable()
export class DataService {
  constructor(private http: HttpClient) {}

  getData() {
    return this.http.get("/api/data");
  }
}
```

### Without SSR

For client-side only applications, you'll need to implement one of these approaches:

1. **Backend Proxy (Recommended)**:
   Create a dedicated backend service to handle sensitive API calls:

```typescript
// proxy.service.ts
@Injectable()
export class ProxyService {
  constructor(private http: HttpClient) {}

  getData() {
    return this.http.get("/api/proxy-endpoint");
  }
}
```

2. **Environment Configuration (Public Keys Only)**:
   Only use environment files for public keys that are safe to expose:

```typescript
// environment.ts
export const environment = {
  production: false,
  publicApiKey: "your-public-key",
};
```

## Security Best Practices

1. **Environment Variables**:

   - Store API keys in .env files
   - Never commit .env files to version control
   - Use .env.example for documentation
   - Configure environment variables in your hosting platform

2. **HTTPS and Access Control**:

   - Always use HTTPS for data transmission
   - Restrict API key usage by domain/IP where possible
   - Implement proper CORS policies

3. **Framework-Specific Considerations**:

   - Next.js: Only prefix environment variables with NEXT_PUBLIC\_ if they're meant to be public
   - Angular: Keep sensitive environment variables in server-side code only

4. **Deployment**:
   - Use hosting platforms' secret management systems (Vercel, AWS, Azure, etc.)
   - Regularly rotate API keys
   - Monitor API usage for suspicious patterns

## Conclusion

Both Next.js and Angular provide robust ways to handle API keys securely. Next.js offers built-in server-side capabilities that make secure implementation straightforward, while Angular with Universal now provides similar server-side security features. For client-side only Angular applications, using a backend proxy remains the most secure approach.

Remember to regularly audit your security practices and keep your dependencies updated to maintain strong application security.

## Useful links

Next.js:

Environment Variables: [https://nextjs.org/docs/app/building-your-application/configuring/environment-variables](https://nextjs.org/docs/app/building-your-application/configuring/environment-variables)</br>
API Routes Security: [https://nextjs.org/docs/app/building-your-application/routing/route-handlers#request-helpers](https://nextjs.org/docs/app/building-your-application/routing/route-handlers#request-helpers)

Angular:

Security best practices: [https://angular.dev/best-practices/security](https://angular.dev/best-practices/security)</br>
Server-side rendering: [https://angular.dev/guide/ssr](https://angular.dev/guide/ssr)


Securely Managing API Keys - Next.js vs. Angular


# Modal Routing in Next.js with Pages Router

<time>November 1, 2023</time>

![Image ...](/images/posts/modal-routing/modal-routing.jpg)

## Introduction

In this article, we'll dive into implementing Modal Routing in an already existent project with Next.js 12 and pages router. For those using Next.js 13 and the App Router, you can find relevant information at [Next.js Documentation](https://nextjs.org/docs/app/building-your-application/routing/parallel-routes).

The concept behind Modal Routing is to open links in a modal dialog instead of redirecting users to a separate page. However, we still want to ensure the URL remains SEO-friendly. This means that whether the user types the URL directly in the browser's address bar or arrives via external links, the specific page behaves as expected. Additionally, if the user refreshes the modal, it should take them directly to the specific detail page.

## Diagram

<iframe style="border:none" width="100%" height="550" src="https://whimsical.com/embed/DdqKEifXETV8PK5KNN8bsp"></iframe>

Here's an overview to improve your comprehension of the different components and their interactions in this example. Detailed explanations for each component will be provided in the following sections.

### AllProjects:

- The "AllProjects" component serves as a gallery, responsible for displaying a collection of projects.

### ProjectItem:

- The "ProjectItem" component is used within the "AllProjects" component. It contains the "Link" for each specific project.
- The "Link" is used to navigate to individual project details or open them in a modal.
- It has parameters such as href, as, and shallow to control how the navigation and URL presentation work.

### ProjectContent:

- The "ProjectContent" component is responsible for displaying the detailed content of a selected project. It is designed to show the specifics of a project, such as its title, description, and other relevant information.

### Modal:

- The "Modal" component is an essential part of the setup, serving as a parent for the "ProjectContent" component.
- It controls the visibility and behavior of the modal dialog, allowing users to view project details without leaving the current page. It ensures a seamless user experience when interacting with project content.

## Detailed explanations with code

## Pages

### Index (pages/projects/index.js)

Receives data for all projects with getStaticProps and passes it as props to AllProjects component.

```jsx
const Projects = (props) => {
  const { projects } = props;
  const router = useRouter();

  return (
    <>
      <AllProjects projects={projects} />
      <Modal
        isOpen={!!router.query.slug}
        onRequestClose={() =>
          router.push('/projects', null, { shallow: true })
        }>
        <ProjectContent
          project={projects.find(
            (project) => project.slug === router.query.slug
          )}
          pathname={router.query.slug}
        />
      </Modal>
    </>
  );
};

//export const getStaticProps = (context) => {...};
```

The central element of the Modal component resides within the projects index page, where it functions as the parent to the ProjectContent component. Within this context, two crucial parameters are associated with the Modal component:

1. **isOpen** is set to 'true' when a Link is clicked and **router.query.slug** is defined. The '!!' double negation operator makes sure that any value is converted to a boolean.
2. **onRequestClose** uses 'router.push' to close the modal and change the URL to '/projects'. **shallow** prevents full page reloads and is useful for modal dialogs to maintain the current page position when navigating.

```jsx

 <Modal
  isOpen={!!router.query.slug}
  onRequestClose={() =>
    router.push('/projects', null, { shallow: true })
  }>

```

To ensure that we can access the specific project data on the index page, which is typically retrieved in the slug page, we employ a method of comparison. This comparison involves matching the project's slug with the router query defined by the Link and passing it as props to the ProjectContent component. It's worth noting that the "projects" object contains the data for all the projects.

```jsx
<ProjectContent
  project={projects.find((project) => project.slug === router.query.slug)}
  pathname={router.query.slug}
/>
```

### Slug (pages/projects/[slug].js)

This page is responsible for rendering the detailed content view when users access the route directly by entering a URL in the browser's address bar or when they refresh the modal. **getStaticProps** retrieves data specific to the project and passes it as props to the "ProjectContent" component. **getStaticPaths** generates the dynamic paths for projects.

```jsx
const ProjectDetailPage = (props) => {
  const { project } = props;

  return (
    <>
      <Head>
        <title>Project - {project.title}</title>
        <meta name='description' content={project.description} />
      </Head>

      <ProjectContent project={project} />
    </>
  );
};

//export const getStaticProps = (context) => {...};
//export const getStaticPaths = () => {...};
```

## Components

### Modal

The Modal component is an essential part of implementing modal routing. It controls the visibility of the modal and prevents scrolling when the modal is open.

```jsx
const ProjectModal = (props) => {
  const { isOpen, onRequestClose } = props;

  useEffect(() => {
    if (isOpen) document.body.style.overflow = 'hidden';
    if (!isOpen) document.body.style.overflow = 'unset';
  }, [isOpen]);

  return (
    <>
      {isOpen && (
        <div className={classes.backdrop} onClick={onRequestClose}>
          <div className={classes.content}>{props.children}</div>
        </div>
      )}
    </>
  );
};

export default ProjectModal;
```

### ProjectItem (Link)

The ProjectItem component is a child of AllProjects component, shown at pages/projects/index.js, which serves as a gallery for displaying a collection of projects. In the Link we have following parameters:

**?slug=** is used to pass query parameters to the route. It's a way to send data to the dynamic route, typically used to specify which project or content to display.
The ?slug= format is used for query parameters and is often associated with dynamic routes. You can include query parameters in the href to send data to the dynamic page.

**as** used when you want to show a different URL in the browser's address bar than the one used for routing. This can be useful for creating more user-friendly or SEO-friendly URLs.

**shallow** prevents full page reloads and is useful for modal dialogs to maintain the current page position when navigating.

```jsx
<div className={classes.card}>
  <Link
    href={`/projects/?slug=${project.slug}`}
    as={`/projects/${project.slug}`}
    shallow={true}>
{/* ... */}
```

### ProjectItem (router.push)

While Link is the preferred method for modal routing, you can achieve similar results using router.push. However, this approach may have a negative impact on SEO.

```jsx
<div className={classes.card}>
  <button
    onClick={router.push(
      `/projects/?slug=${project.slug}`,
      `/projects/${project.slug}`,
      {
        shallow: true,
      }
    )}>
{/* ... */}
```

## Bonus

### Conditionally open modal with query parameters

If you want to implement Modal Routing on your root index page, which features both Projects and Posts, you'll need to ensure that only one instance of the Modal is opened at a time. To achieve this, you can pass ProjectContent and PostContent as children to the Modal. But how does the Modal know which one to render? This is where passing additional query parameters becomes crucial. [Next.js Documentation - Linking and Navigating](https://nextjs.org/docs/pages/building-your-application/routing/linking-and-navigating)

When constructing the Link's **href**, you should use an URL object that includes the **pathname**, which is the root ('/'), and within the **query**, specify the **slug** and the **type**. These query parameters will help identify whether the link corresponds to a project or a post and guide the rendering of the Modal content accordingly.

```jsx
<Link
  href={{
    pathname: '/',
    query: {
      slug: project.slug,
      type: 'project',
    },
  }}
  as={`/projects/${project.slug}`}
  shallow={true}>
```

Here is how your root index page should look like:

```jsx
<Modal
  isOpen={!!router.query.slug}
  onRequestClose={() => router.push('/', null, { shallow: true })}>
  {!!router.query.slug && router.query.type == 'project' && (
    <ProjectContent
      project={featuredProjects.find(
        (project) => project.slug === router.query.slug
      )}
      currentTheme={currentTheme}
      pathname={router.query.slug}
    />
  )}

  {!!router.query.slug && router.query.type === 'post' && (
    <PostContent
      post={featuredPosts.find((post) => post.slug === router.query.slug)}
      currentTheme={currentTheme}
      pathname={router.query.slug}
    />
  )}
</Modal>
```

Thanks for following along, and I hope this guide helps you implement Modal Routing with Pages Router effectively!


Modal Routing in Next.js with Pages Router


# How to deploy a static Next.js website on Github Pages

<time>June 23, 2022</time>

![Image ...](/images/posts/static-site-to-github-pages/github.jpg)

## Introduction

##### Using Next.js version 12.1.6

<blockquote>
Update: Since July 27th, this procedure can be done completely by github without a third party solution.

[github.blog](https://github.blog/changelog/2022-07-27-github-pages-custom-github-actions-workflows-beta/)

</blockquote>

I've wanted to build a cool, or at least presentable, Portfolio-Blog for a while now. Since I've been working a lot with Next.js lately, I figured it would be a great idea to build this portfolio using Next.js instead of some plain html/css/js. And since I didn't want to pay for hosting just right now, Github Pages should do the trick.

The original idea was to **next build** and **next export** the project and then manually upload the generated files to a repository. Since this didn't work the way I was thinking, I searched and found an even better solution. This involves using Github Actions and a third party CI/CD solution available at Github Marketplace. The one I used is ["Deploy to Github Pages"](https://github.com/marketplace/actions/deploy-to-github-pages).

### 1. Github Actions

1. In your repository go to actions and add a workflow by choosing Node.js:

   ![Image ...](/images/posts/static-site-to-github-pages/github-actions-01.jpg)

2. You'll get a **node.js.yml** file like the one bellow:

   ```yml
   # This workflow will do a clean installation of node dependencies, cache/restore them, build the source code and run tests across different versions of node
   # For more information see: https://help.github.com/actions/language-and-framework-guides/using-nodejs-with-github-actions

   name: Node.js CI

   on:
     push:
       branches: ['main']
     pull_request:
       branches: ['main']

     jobs:
     build:

     runs-on: ubuntu-latest

     strategy:
       matrix:
         node-version: [12.x, 14.x, 16.x]
         # See supported Node.js release schedule at https://nodejs.org/en/about/releases/

     steps:
       - uses: actions/checkout@v3
       - name: Use Node.js ${{ matrix.node-version }}
         uses: actions/setup-node@v3
         with:
           node-version: ${{ matrix.node-version }}
           cache: 'npm'
       - run: npm ci
       - run: npm run build --if-present
       - run: npm test
   ```

3. Select the node version e.g. **node-version: [16.x]** then start replacing at **- run: npm ci** like the code below. Since I'm using **yarn** I also changed the respective **npm** commands. For example: **run: yarn install --frozen-lockfile** is equivalent to **run: npm ci**.

   We also need to bypass Jekyll since it doesn't recognize folders that start with an underscore, like "\_next". More about bypassing Jekyll on Github [Github Blog](https://github.blog/2009-12-29-bypassing-jekyll-on-github-pages/) and [Stackoverflow](https://stackoverflow.com/questions/61450307/js-and-css-not-loading-when-hosting-next-application-on-github-pages).

   The section starting with **- name: Deploy** is the ["Deploy to Github Pages"](https://github.com/marketplace/actions/deploy-to-github-pages).

   ```yml
   - run: npm install -g yarn # Installs yarn.
   - run: yarn install --frozen-lockfile # Performs a clean install.
   - run: yarn build && export # Generates and exports files into "out" folder.
   - run: touch ./out/.nojekyll # This bypasses Github's Jekyll since it doesn't recognize folders that start with an underscore, like "_next".

   - name: Deploy
     uses: JamesIves/github-pages-deploy-action@v4.3.3
     with:
       branch: gh-pages # The branch the action should deploy to.
       folder: out # The folder the action should deploy.
   ```

4. The content of the folder **out** is then deployed to the **gh-pages** branch, which is then used by Github Pages.

### 2. Next.js config

#### - Custom image loader & basePath

1. In the Next.js application, we need to change the **next.config.js** file. We need to add a custom image loader since the standard one doesn't support **next export** which you can see in the error message bellow. More about built-in image loaders [official doc](https://nextjs.org/docs/api-reference/next/image#loader-configuration). This was a trial and error and the one that worked for me was the "akamai".

   Error message:

   ```txt
   Error: Image Optimization using Next.js' default loader is not compatible with `next export`.
     Possible solutions:
       - Use `next start` to run a server, which includes the Image Optimization API.
       - Use any provider which supports Image Optimization (like Vercel).
       - Configure a third-party loader in `next.config.js`.
       - Use the `loader` prop for `next/image`.
     Read more: https://nextjs.org/docs/messages/export-image-api
   ```

   next.config.js:

   ```js
   /** @type {import('next').NextConfig} */
   const isProd = process.env.NODE_ENV === 'production';
   const nextConfig = {
     reactStrictMode: true,
     images: {
       loader: 'akamai',
       path: isProd ? 'https://<your github account>.github.io/' : '',
     },
     basePath: '/<your github repo>',
   };

   module.exports = nextConfig;
   ```

2. As seen above, you also need to define a **basePath**. The reason behind it is that images/assets will not load because your repository name will be part of the URL. There is another option called [assetPrefix](https://nextjs.org/docs/api-reference/next.config.js/cdn-support-with-asset-prefix) but it is discouraged. By the way you can also use a **isProduction** variable like this:

   next.config.js:

   ```js
   const isProd = process.env.NODE_ENV === 'production';
   //and then something like this ternary :
   basePath: isProd ? '/<your github repo>' : '',
   ```

#### - Changing Image src

1. Replace each image src as described in the [official docs](https://nextjs.org/docs/api-reference/next.config.js/basepath#images)

   ```jsx
   <Image
     src='/images/profile-pic.png'
     width={360}
     height={360}
     alt='profile-pic'
   />
   ```

   ```jsx
   <Image
     src='/<your github repo>/images/profile-pic.png'
     width={360}
     height={360}
     alt='profile-pic'
   />
   ```

Thanks for following along and I hope it helps you too!


BLOG POSTS

Securely Managing API Keys - Next.js vs. Angular

Modal Routing in Next.js with Pages Router

How to deploy a static Next.js website on Github Pages