When it comes to setting up a database connection similar to express.js in next.js, it's not as straightforward. I've discussed this issue here. In Express.js, database connections are usually long-lived, established at the start of the application and active throughout its lifetime. However, in next.js, due to the nature of serverless functions, we need to implement per-request connections.

If you're looking to implement dependency injection, you can give tsyringe by Microsoft a try. To integrate this with next.js, you can refer to this guide. Just in case the link becomes unavailable in the future:

// Installing reflect metadata allows the use of decoraters
npm install --save tsyringe reflect-metadata

Update your tsconfig.json file with the following settings to enable decorators usage in TypeScript:

{
  "compilerOptions": {
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true
  }
}

Add a .babelrc file to your project with the following configurations:

{
  "presets": ["next/babel"],
  "plugins": [ 
    # These plugins implement decorators
    "babel-plugin-transform-typescript-metadata",
    ["@babel/plugin-proposal-decorators", { "legacy": true }],
    ["@babel/plugin-proposal-class-properties", { "loose": true }]
  ]
}

Finally, include this import statement in your _app.tsx file or within the app directory for layout purposes:

import "reflect-metadata";

We are now prepared to refactor the code into a more maintainable structure.

Below is an example code snippet that creates a graphql client:

Importing the necessary packages:

import { DocumentNode } from "graphql";

export interface graphClient {
  query(query: DocumentNode, variables?: {}): any;
}

Please note that you will need to use class components for constructor injections:

import { inject, injectable } from "tsyringe";

@injectable()
export class getLatestPosts implements iGetLatestPosts {
  graphClient: graphClient;

  constructor(@inject("graphClient") private graphClientParam: graphClient) {
    this.graphClient = graphClientParam;
  }
...
}

Here is an example of creating a dataAccess.ts file:

// dataAccess.ts

import {
  MongoClient,
  Db,
  Collection
} from 'mongodb';

let client: MongoClient;

export async function connectDatabase() {
  if (!client) {
    client = new MongoClient(process.env.MONGODB_URI);
    await client.connect();
  }
  return client.db();
}

export function getSurveysCollection(db: Db): Collection {
  return db.collection('survey-templates');
}

Utilize Dependency Injection for your API routes by creating a middleware that handles the database connection and provides it to route handlers:

// Example middlewareDB.ts

import {
  NextApiRequest,
  NextApiResponse
} from 'next';
import {
  connectDatabase
} from './dataAccess';

export default function withDB(handler: (db: Db) => (req: NextApiRequest, res: NextApiResponse) => Promise < void > ) {
  return async(req: NextApiRequest, res: NextApiResponse) => {
    const db = await connectDatabase();
    await handler(db)(req, res);
  };
}

Update your API routes to use the withDB middleware and DAL functions. Adapt your POST route as needed:

// api/survey.ts

import {
  NextApiRequest,
  NextApiResponse
} from 'next';
import withDB from '../../middleware/withDB';
import {
  getSurveysCollection
} from '../../dataAccess';

const handler = async(db: Db) => async(req: NextApiRequest, res: NextApiResponse) => {
  try {
    const collection = getSurveysCollection(db);
    // Handle database operations here
    // ...
    res.status(201).json({
      "survey-id": uuid
    });
  } catch (error) {
    res.status(500).json({
      error: 'Internal Server Error'
    });
  }
};

export default withDB(handler);

This setup keeps your API routes focused on handling HTTP requests, while abstraction of data access logic into the DAL allows for easy modifications to the backend without affecting the routes.

To enhance the scalability of your Next.js API routes and promote code organization and flexibility, consider implementing a data access layer that abstracts the database-specific functionalities. Here is a step-by-step guide to help you achieve this:

Establish a Data Access Layer:

Begin by creating a dedicated directory within your project for the data access layer. You can name it something intuitive like data-access or any other suitable identifier.

/data-access
  - surveys.ts

Within the surveys.ts file (or additional files if necessary), define functions that encapsulate the database operations related to surveys. These functions should be designed in a manner that decouples them from any particular database implementation.

// data-access/surveys.ts

import { Db, ObjectId } from 'mongodb';

export interface Survey {
  // Define the schema for your survey here
}

export class SurveyDataAccess {
  private readonly db: Db;

  constructor(db: Db) {
    this.db = db;
  }

  async createSurvey(survey: Survey): Promise<string> {
    const result = await this.db.collection('survey-templates').insertOne(survey);
    return result.insertedId.toString();
  }

  async getSurveyById(id: string): Promise<Survey | null> {
    const survey = await this.db.collection('survey-templates').findOne({ _id: new ObjectId(id) });
    return survey;
  }

  // Include any other necessary data access methods
}

Integrate Database Dependency:

In your Next.js API routes, incorporate the database dependency by instantiating an instance of SurveyDataAccess and passing the database connection as a parameter to the constructor.

// api/surveys.ts

import { NextApiResponse } from 'next';
import { SurveyDataAccess } from '../data-access/surveys';

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  const client = await clientPromise; // Assuming clientPromise represents your database connection
  const surveyDataAccess = new SurveyDataAccess(client.db('survey-db'));

  if (req.method === 'POST') {
    // Utilize surveyDataAccess to create a new survey
    // ...
  } else if (req.method === 'GET') {
    // Utilize surveyDataAccess to fetch surveys
    // ...
  }
}

Abstracting Database-Specific Logic:

In your API routes, leverage the surveyDataAccess object to interact with the database instead of directly invoking MongoDB-specific code. This abstraction facilitates the potential transition to a different database system without necessitating modifications to your API routes.

Testing and Upkeep:

By delineating the responsibilities in this manner, you can easily conduct unit tests on your data access layer independently of the API routes. If there is a future need to switch databases, you can simply update the SurveyDataAccess class while maintaining the integrity of your API routes.

Adopting this methodology not only fosters a clear separation of concerns but also enhances the maintainability and adaptability of your codebase to forthcoming alterations in the database infrastructure.