Blog

Traditional offset-based pagination (using SKIP and TAKE) isn't viable in DynamoDB due to performance constraints. Instead, DynamoDB uses cursor-based pagination through LastEvaluatedKey, which acts as a pointer to the next page.

While navigating "Next" is straightforward, implementing a full set of controls—First, Previous, Next, and Last—requires a deeper understanding of DynamoDB's architecture.

In this guide, we’ll implement a complete pagination solution in C#.

Introduction to DynamoDB Pagination

Amazon DynamoDB is a fully managed NoSQL database designed for fast, scalable, and predictable performance. When querying large datasets, DynamoDB automatically paginates results and returns up to 1 MB of data per request.

Instead of using offset-based pagination like SQL, DynamoDB uses a special value called LastEvaluatedKey. Each query response includes:

• A page of items.

• A LastEvaluatedKey (if more items exist).

To retrieve the next page, the client passes this key back to DynamoDB using the ExclusiveStartKey parameter. Because DynamoDB does not support random access to pages, implementing controls like Previous and Last requires applying cursor logic or manipulating the sort order.

When to Use Pagination in DynamoDB

Pagination is essential when dealing with:

• Large datasets: Fetching thousands of items in a single request is inefficient and costly.

• User interfaces: UI components (dashboards, tables) need friendly controls.

• APIs returning limited result sets: Public endpoints must paginate to avoid timeouts.

• Reducing Read Costs: Controlled queries reduce Read Capacity Units (RCU) consumption.

• High-traffic systems: Fetching data incrementally prevents backend resource exhaustion.

The Secret Weapon: ScanIndexForward

DynamoDB allows you to navigate forward easily. However, it does not natively support "Previous" or "Last". To solve this, we utilize the ScanIndexForward parameter.

• ScanIndexForward = true (Default): Returns items in ascending order.

• ScanIndexForward = false: Returns items in descending order.

This feature allows us to:

Efficiently get the "Last Page"

Querying in descending order gives you the newest/last items first.

Key Concept: The first page of a descending query is effectively the last page of an ascending query.

Support Backward Pagination

When moving backward, using reverse sort order allows us to fetch items preceding the current batch without scanning the entire table.

Note: This technique requires your Table or GSI to have a Sort Key defined.

Implementing Pagination (C# Example)

Below is a reusable pagination structure supporting First, Next, Previous, and Last.

Important: Handling State in Web APIs

Before looking at the code, note that in a stateless environment (like a REST API), you cannot store the PagingState object in server memory. You must serialize the state (e.g., to a Base64 JSON string) and send it to the client. The client must then send this token back in the next request.

Models

using Amazon.DynamoDBv2.Model;

// Represents the result of a paginated query
public class PageResult
{
    // List of DynamoDB items returned for this page
    public List<Dictionary<string, AttributeValue>> Items { get; set; }

    // Cursor pointing to the next page (null if no more pages)
    public Dictionary<string, AttributeValue>? NextKey { get; set; }

    // Number of items per page
    public int PageSize { get; set; }
}

// Stores the pagination state for navigating Next/Previous
public class PagingState
{
    // Stack of previous page tokens -> used to move backwards
    // In a Web API, this list should be serialized and sent to the client
    public Stack<Dictionary<string, AttributeValue>?> PrevTokens { get; set; } = new();

    // Token used to load the current page
    public Dictionary<string, AttributeValue>? CurrentToken { get; set; }

    // Token used to load the next page
    public Dictionary<string, AttributeValue>? NextToken { get; set; }
}

Base Query Method

This generic method handles the core DynamoDB query logic.

public async Task<PageResult> QueryPageAsync(
    string userType,
    Dictionary<string, AttributeValue>? startKey,
    int pageSize,
    bool scanForward = true)
{
    var request = new QueryRequest
    {
        TableName = "Users",
        // Partition key condition
        KeyConditionExpression = "UserType = :u",
        ExpressionAttributeValues = new Dictionary<string, AttributeValue>
        {
            {":u", new AttributeValue { S = userType }}
        },
        // Cursor for next page (null for first page)
        ExclusiveStartKey = startKey,
        // Maximum items to return
        Limit = pageSize,
        // Sorting direction: true = ascending, false = descending
        ScanIndexForward = scanForward
    };

    var response = await _client.QueryAsync(request);

    return new PageResult
    {
         Items = response.Items,
         NextKey = response.LastEvaluatedKey,
         PageSize = pageSize
    };
}

First Page

public async Task<PageResult> GetFirstPageAsync(string userType, int pageSize, PagingState state)
{
    // Clear backward history as we are starting over
    state.PrevTokens.Clear();
    state.CurrentToken = null;

    // Load first page in ascending order
    var result = await QueryPageAsync(userType, null, pageSize, scanForward: true);
    // Store next page cursor
    state.NextToken = result.NextKey;
    return result;
}

Next Page

public async Task<PageResult> GetNextPageAsync(string userType, int pageSize, PagingState state)
{
    // Check if there are more pages
    if (state.NextToken == null)
        return new PageResult { Items = new(), NextKey = null };

    // Save current token to history so we can navigate backwards later
    state.PrevTokens.Push(state.CurrentToken);

    // Move forward
    state.CurrentToken = state.NextToken;
    // Load next page
    var result = await QueryPageAsync(userType, state.CurrentToken, pageSize);
    state.NextToken = result.NextKey;
    return result;
}

Previous Page

public async Task<PageResult> GetPreviousPageAsync(string userType, int pageSize, PagingState state)
{
    // If no history, default to First Page
    if (!state.PrevTokens.Any())
        return await GetFirstPageAsync(userType, pageSize, state);

    // Retrieve the most recent previous token
    var previousKey = state.PrevTokens.Pop();
    // Update current cursor
    state.CurrentToken = previousKey;
    // Load page using the retrieved token
    var result = await QueryPageAsync(userType, previousKey, pageSize);
    state.NextToken = result.NextKey;
    return result;
}

Last Page

This is where the magic happens using ScanIndexForward = false.

public async Task<PageResult> GetLastPageAsync(string userType, int pageSize)
{
    // Reverse the sort order so newest items come first
    // This effectively fetches the "Last Page" immediately
    var result = await QueryPageAsync(
        userType,
        startKey: null,
        pageSize: pageSize,
        scanForward: false); // Critical: Read backwards

    // Reorder items for UI display (so they appear Ascending within the page)
    result.Items.Reverse();

    return result;
}

Note on Navigation: Jumping directly to the "Last Page" isolates the user from the previous navigation history. The PrevTokens stack will not automatically know how to go back to the "Second to Last" page. In most UI implementations, clicking "Last" resets the navigation context.

Conclusion

DynamoDB’s cursor-based pagination offers a scalable and cost-efficient alternative to offset-based pagination. While paging forward is simple, paging backward and jumping to the last page requires creative use of sorting.

By leveraging ScanIndexForward = false, developers can:

1. Retrieve the last page instantly (O(1) complexity).

2. Reverse the paging direction efficiently.

3. Reduce unnecessary read costs.

With the C# implementation provided, you now have a robust starting point for building user-friendly tables on top of DynamoDB.

References

These authoritative resources help deepen your understanding:

• AWS Docs – Query API
  https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Query.html

• AWS Docs – DynamoDB Pagination
  https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Query.Pagination.html

• AWS .NET SDK Documentation
  https://docs.aws.amazon.com/sdkfornet/v3/apidocs/index.html

• Best Practices for DynamoDB
  https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html

Modern web applications often need to export reports as PDF files. Instead of building PDF layouts manually, ActiveReportsJS by Mescius allows developers to design report templates using a JSON format, then render these templates inside Next.js using dynamic parameters and data sources.

1. Introduction

In this article, we will explore how to use ActiveReportsJS inside a Next.js project to generate PDF documents on the server side. The workflow is simple: prepare a JSON report template, pass data and parameters to it, and let ActiveReportsJS create the final PDF file.

This approach is useful for invoices, summaries, forms, and any business reports that need flexible formatting. The content below uses common technical vocabulary and is designed for developers of all levels.

2. How ActiveReportsJS Works in a Next.js Environment

ActiveReportsJS is a client-side and server-side reporting engine. When used with Next.js API routes, it can render PDF files without exposing sensitive logic to the browser. The typical flow includes:

• Loading a JSON report template (.rdl.json)
• Passing parameters and dynamic data
• Rendering the report into a PDF stream
• Returning the file to the user

Below is a simplified example of how the process looks.

2.1 JSON Template Structure

A basic ActiveReportsJS template includes layout, text boxes, and bindings. Templates are normally created using the ActiveReportsJS Designer tool.

{
  "Name": "StudentReport",
  "Type": "report",
  "DataSources": [
    {
      "Name": "ReportDataSource",
      "ConnectionProperties": {
        "DataProvider": "JSON",
        "ConnectString": "jsondata="
      }
    }
  ],
  "DataSets": [
    {
      "Name": "ReportDataSet",
      "Query": {
        "DataSourceName": "ReportDataSource",
        "CommandText": "$.value[*]"
      },
      "Fields": [
        {
          "Name": "qrcd",
          "DataField": "qrcd",
          "Type": "String"
        },
        {
          "Name": "studentId",
          "DataField": "studentId",
          "Type": "String"
        },
        {
          "Name": "ticketInfo",
          "DataField": "ticketInfo",
          "Type": "Object"
        }
      ]
    }
  ],
  "Page": {
    "PageWidth": "8.5in",
    "PageHeight": "11in",
    "Margins": {
      "Top": "0.5in",
      "Bottom": "0.5in",
      "Left": "0.5in",
      "Right": "0.5in"
    }
  },
  "Body": {
    "ReportItems": [
      {
        "Type": "textbox",
        "Name": "QrcdValue",
        "Value": "=Fields!qrcd.Value",
        "Style": {
          "FontFamily": "Noto Sans JP",
          "FontSize": "10pt"
        },
        "Top": "0.9in",
        "Left": "2in",
        "Width": "5.5in",
        "Height": "0.25in"
      },
      {
        "Type": "textbox",
        "Name": "TicketIdValue",
        "Value": "=Fields!ticketInfo.Value.ticketId",
        "Style": {
          "FontFamily": "Noto Sans JP",
          "FontSize": "10pt"
        },
        "Top": "2.3in",
        "Left": "2in",
        "Width": "5.5in",
        "Height": "0.25in"
      }
    ],
    "Height": "9.8in"
  }
}

2.2 Basic PDF Generation with Parameters

The simplest example: using parameters to inject values into the report template.

// pages/api/basic-report.ts
import { NextApiRequest, NextApiResponse } from 'next';
import { 
  outputPDFByARJ, 
  createParameter
} from '@/common/utils/sample-active-report-js';

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  try {
    const { title, author } = req.query;

    // Create simple parameters
    const parameters = [
      createParameter('reportTitle', title || 'Default Report Title'),
      createParameter('authorName', author || 'Unknown Author'),
      createParameter('generationDate', new Date().toLocaleDateString('ja-JP'))
    ];

    // Generate PDF using the utility function
    await outputPDFByARJ({
      jsonUrl: '/data/basic-report-template.json',
      fileName: `basic-report-${Date.now()}.pdf`,
      parameters
    });

  } catch (error) {
    console.error('PDF Generation Error:', error);
    res.status(500).json({ error: 'Failed to generate PDF' });
  }
}

2.3 Working with Complex Data Structures

When dealing with complex business data containing nested objects, ActiveReportsJS requires careful handling. The template in our example expects data with nested structures like ticket information, status, and procedure details.

// pages/api/generate-student-report.ts
import { NextApiRequest, NextApiResponse } from 'next';
import { 
  outputPDFByARJ, 
  createParameter,
  flattenNestedObjectToParameters 
} from '@/common/utils/sample-active-report-js';

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  try {
    const { studentId, orgCode } = req.query;

    // Sample complex data structure matching the report template
    const reportData = {
      value: [
        {
          qrcd: `QR${Date.now()}`,
          studentId: studentId || "STU001",
          orgCode: orgCode || "ORG001",
          ticketInfo: {
            ticketId: `TICKET${studentId || '001'}`,
            seatNumber: "A-001",
            facultyName: "Faculty of Arts",
            departmentName: "Design",
            categoryName: "General Admission",
            area: "Main Campus"
          },
          numberInfo: {
            number: "2024001",
            appNumber: `APP${studentId || '001234'}`,
            schoolName: "Sample High School"
          },
          resultInfo: {
            status: "Passed",
            comment: "Congratulations on your success!"
          },
          procedures: {
            fee: "$3,000",
            startDate: "2024-04-01",
            endDate: "2024-04-30"
          },
          qrCodeReference: {
            comment: "Scan for details",
            destAddress: "contact@example.com",
            destName: "Admission Office"
          }
        }
      ]
    };

    // Method 1: Using createParameter for simple values
    const simpleParams = [
      createParameter('reportTitle', 'Admission Certificate'),
      createParameter('generatedDate', new Date().toISOString().split('T')[0])
    ];

    // Method 2: Using flattenNestedObjectToParameters for complex objects
    const nestedData = {
      student: {
        name: "John Doe",
        studentId: "S2024001"
      },
      contact: {
        email: "john.doe@example.com",
        phone: "+1-555-0123"
      }
    };
    
    const flattenedParams = flattenNestedObjectToParameters(nestedData);

    // Combine all parameters
    const allParameters = [...simpleParams, ...flattenedParams];

    // Generate PDF using the utility function
    await outputPDFByARJ({
      jsonUrl: '/data/student-report-template.json', // Updated generic filename
      fileName: `report-${Date.now()}.pdf`,
      parameters: allParameters,
      data: reportData
    });

  } catch (error) {
    console.error('PDF Generation Error:', error);
    res.status(500).json({ error: 'Failed to generate PDF' });
  }
}

2.4 Client-Side Integration with React Components

Here's how to integrate PDF generation into your React components:

// components/ReportGenerator.tsx
import { useState } from 'react';
import { 
  outputPDFByARJ, 
  createParameter,
  flattenNestedObjectToParameters 
} from '@/common/utils/sample-active-report-js';

// Define interface for data structure
interface ReportData {
  qrcd: string;
  studentId: string;
  orgCode: string;
  ticketInfo: {
    ticketId: string;
    seatNumber: string;
    facultyName: string;
    departmentName: string;
    categoryName: string;
    area: string;
  };
  numberInfo: {
    number: string;
    appNumber: string;
    schoolName: string;
  };
  resultInfo: {
    status: string;
    comment: string;
  };
  procedures: {
    fee: string;
    startDate: string;
    endDate: string;
  };
  qrCodeReference: {
    comment: string;
    destAddress: string;
    destName: string;
  };
}

export const ReportGenerator = () => {
  const [isGenerating, setIsGenerating] = useState(false);
  const [studentId, setStudentId] = useState('');
  const [orgCode, setOrgCode] = useState('');

  const generateReport = async () => {
    if (!studentId || !orgCode) {
      alert('Please enter Student ID and Org Code');
      return;
    }

    setIsGenerating(true);
    try {
      // Prepare complex nested data
      const data: ReportData = {
        qrcd: `QR${Date.now()}`,
        studentId,
        orgCode,
        ticketInfo: {
          ticketId: `TICKET${studentId}`,
          seatNumber: 'A-001',
          facultyName: 'Faculty of Arts',
          departmentName: 'Design',
          categoryName: 'General Admission',
          area: 'Main Campus'
        },
        numberInfo: {
          number: studentId,
          appNumber: `APP${studentId}`,
          schoolName: 'Sample High School'
        },
        resultInfo: {
          status: 'Passed',
          comment: 'Congratulations on your success.'
        },
        procedures: {
          fee: '$3,000',
          startDate: '2024-04-01',
          endDate: '2024-04-30'
        },
        qrCodeReference: {
          comment: 'Access Link',
          destAddress: 'contact@example.com',
          destName: 'Office'
        }
      };

      // Create parameters using utility functions
      const parameters = [
        createParameter('reportTitle', 'Admission Certificate'),
        createParameter('generationTime', new Date().toLocaleString('en-US')),
        ...flattenNestedObjectToParameters({
          metadata: {
            version: '1.0',
            generatedBy: 'Report System'
          }
        })
      ];

      // Generate PDF with complex data
      await outputPDFByARJ({
        jsonUrl: '/data/student-report-template.json',
        fileName: `admission-certificate-${studentId}.pdf`,
        parameters,
        data: { value: [data] } // Wrap in { value: [...] } as expected by template
      });

      alert('PDF generated successfully!');
    } catch (error) {
      console.error('Generation failed:', error);
      alert('Failed to generate PDF. Please try again.');
    } finally {
      setIsGenerating(false);
    }
  };

  return { generateReport };
}

2.5 Understanding the outputPDFByARJ Function

Before diving into complex examples, let's understand the outputPDFByARJ function - this is the main utility function for generating PDFs from JSON templates:

/**
 * Generates and downloads a PDF file from a report definition JSON (RDL).
 * This function fetches the report layout, applies specified parameters, runs the report,
 * and then exports the result as a PDF, triggering a download in the browser.
 */
export const outputPDFByARJ = async ({
  jsonUrl,
  fileName,
  parameters,
  password,
  data,
}: OutputPdfParams): Promise => {
  // Check if running in browser environment
  if (typeof window === 'undefined') {
    console.log('PDF Output Error: Not running in browser environment');
    return;
  }

  // Helper: Temporarily neutralize i18n mutating methods to avoid vendor side-effects
  const runWithI18nPatched = async (work: () => Promise) => {
    // Save original methods
    const i18nAny = i18n as unknown as Record<string, unknown>;
    const original = {
      use: i18nAny.use,
      init: i18nAny.init,
      changeLanguage: i18nAny.changeLanguage,
      addResourceBundle: i18nAny.addResourceBundle,
      addResources: i18nAny.addResources,
      addResource: i18nAny.addResource,
      loadLanguages: i18nAny.loadLanguages,
      loadNamespaces: i18nAny.loadNamespaces,
    };

    // Patch to no-ops (non-mutating)
    i18nAny.use = () => i18n;
    i18nAny.init = () => i18n;
    i18nAny.changeLanguage = () => i18n.language;
    i18nAny.addResourceBundle = () => undefined;
    i18nAny.addResources = () => undefined;
    i18nAny.addResource = () => undefined;
    i18nAny.loadLanguages = () => undefined;
    i18nAny.loadNamespaces = () => undefined;

    try {
      await work();
    } finally {
      // Restore originals
      i18nAny.use = original.use;
      i18nAny.init = original.init;
      i18nAny.changeLanguage = original.changeLanguage;
      i18nAny.addResourceBundle = original.addResourceBundle;
      i18nAny.addResources = original.addResources;
      i18nAny.addResource = original.addResource;
      i18nAny.loadLanguages = original.loadLanguages;
      i18nAny.loadNamespaces = original.loadNamespaces;
    }
  };

  await runWithI18nPatched(async () => {
    // Dynamically import ActiveReports to avoid SSR issues
    const { Core, PdfExport } = await import(
      './wrappers/activereports-wrapper'
    );

    // Fetch the report layout from the provided URL
    const response = await fetch(jsonUrl);
    const jsonData = await response.json();

    // Modify ConnectString with JSON data
    jsonData.DataSources[0].ConnectionProperties.ConnectString = `jsondata=${JSON.stringify(data)}`;

    const fontsToRegister = [
      {
        name: 'IPA EXG',
        source: '/fonts/ipaexg.ttf',
      },
      {
        name: 'IPA EXM',
        source: '/fonts/ipaexm.ttf',
      },
    ];
    await Core.FontStore.registerFonts(...fontsToRegister);

    // Load the report definition
    const report = new Core.PageReport();
    await report.load(jsonData);

    if (!data) {
      // Normalize and apply parameters to the report
      const normalizedParameters = parameters.map((param) => ({
        ...param,
        Value: normalizeParameterValue(param.Value),
      }));

      // Apply normalized parameters to the report
      await report.reportParameters.applySteps(normalizedParameters as any);
    }

    // Run the report to generate the document
    const pageDocument = await report.run();

    // Export the document to a PDF blob and initiate download
    const pdfSettings = password
      ? { security: { userPassword: password } }
      : undefined;
    const pdfBlob = await PdfExport.exportDocument(pageDocument, pdfSettings);
    pdfBlob.download(fileName);
  });
};

Parameters of the outputPDFByARJ function:

• jsonUrl: Path to the JSON template file
• fileName: Output PDF file name
• parameters: Array of parameters to pass to the report
• password (optional): Password to protect the PDF
• data: JSON data to bind to the report template

The function will:

1. Fetch the JSON template from the URL
2. Apply parameters and data
3. Render the report into a PDF
4. Trigger download in the browser

3. Best Practices When Using ActiveReportsJS with Next.js

• Store report templates in a secure directory of your project.
• Validate all parameters to avoid unwanted data injection.
• Use API routes to protect server-side rendering logic.
• Do not expose confidential structures from real projects.
• Always review generated code before deployment.

4. Additional Considerations

• Using ActiveReportsJS together with i18next / other i18n libraries:
  If your Next.js project already uses i18next (or similar JavaScript localization / translation libraries), be aware that there can be potential conflicts — especially if your report templates or the rendering logic depend on global locale settings, overridden prototypes, or modifications to built‑in objects.
  To avoid unexpected behavior (e.g. locale/format overrides, translation JSON interfering with report JSON, or i18next initialization affecting global state), you should isolate the report‑rendering context from the rest of your app. For example: load and render the JSON template without i18next’s context, or ensure i18next is not active / initialized when generating PDF on the server.
• Licensing: Free for development / evaluation — but production requires a valid license key:
  ActiveReportsJS provides a “trial / evaluation mode” which allows you to develop locally without a license key. However, in this mode, exported reports will contain a watermark and the standalone designer has a limited evaluation period. For more details, see the official licensing documentation.
  When you deploy to staging or production (or distribute your application), you need to purchase the appropriate ActiveReportsJS license (e.g., a distribution / deployment license), generate a distribution key, and configure your application to set that license key (typically via Core.setLicenseKey(...) or similar). This will remove the watermark and ensure compliance with licensing terms.

5. Conclusion

Using ActiveReportsJS with Next.js provides a clean and scalable way to generate PDF files from JSON templates. By combining parameters, dynamic data, and predefined layouts, developers can create powerful report systems without building UI elements manually.

If you are exploring modern reporting solutions and want to apply them in real-world applications, our company encourages continuous learning and high-quality engineering. For more information about our technology expertise or to discuss potential collaboration, please reach out through our official contact channels.

Whether you need scalable software solutions, expert IT outsourcing, or a long-term development partner, ISB Vietnam is here to deliver. Let’s build something great together—reach out to us today. Or click here to explore more ISB Vietnam's case studies.

Reference Documentation

• ActiveReportsJS Official Documentation
• Next.js Official Documentation

As an experienced developer proficient in Object-Oriented Programming (OOP), you understand the foundational principles of encapsulation, inheritance, polymorphism, and abstraction. Spring is, at its core, the most ambitious application of OOP principles ever built at scale.

You know how to designing clean, decoupled classes, apply SOLID principles and managing object lifecycles.

However, transitioning that expertise to the Java Spring Framework and Spring Boot environment often presents a unique set of pitfalls. Spring introduces its own powerful paradigms, primarily Inversion of Control (IoC) and Dependency Injection (DI), which fundamentally alter how objects are created, managed, and interact. The "Spring Magic" of auto-configuration, annotations, and conventions can sometimes lead to shortcuts that violate core OOP tenets or ignore the framework's best practices.

This blog post explores the most common mistakes developers, particularly those with a strong OOP background, make when diving into the Spring ecosystem. We will cover areas from misusing annotations to neglecting performance and security, providing actionable advice to write cleaner, more maintainable, and robust Spring applications.

The most frequent source of errors stems from a conceptual clash between manual OOP object creation and Spring's automated lifecycle management.

Mistake 1: Ignoring Dependency Injection (DI) and Manually Instantiating Objects

A fundamental OOP habit is using the new keyword to create an object when you need it. In Spring, this is a major anti-pattern for framework-managed components.

The Mistake:

Instead of letting Spring inject dependencies into a component developers might manually instantiate the service:

@Service
public class OrderService {
    private final PaymentService paymentService = new PaymentService(); // ← Death sentence
}

You’ve been trained for years to create instance from class. So you do it instinctively. The result?

• The paymentService is not a Spring bean → no transaction management, no AOP, no proxying.
• You cannot mock it in unit tests without PowerMockito or ugly workarounds.
• You cannot swap implementations per profile (e.g., MockPaymentService in tests or SandboxPaymentService in staging).

The Fix:

Always rely on Spring's DI mechanism. Use Constructor Injection (the preferred method), Setter Injection, or Field Injection (using @Autowired).

Constructor Injection 1

@Service
public class OrderService {

    private final PaymentService paymentService;

    public OrderService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }
}

Constructor Injection 2

@Service
@RequiredArgsConstructor // Lombok, or write constructor yourself
public class OrderService {
    private final PaymentService paymentService; // Constructor injection FTW
}

Setter Injection

@Service
public class OrderService {

private PaymentService paymentService;

    @Autowired
    public void setPaymentService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }
}

Field Injection 

@Service

public class OrderService {

@Autowired
private PaymentService paymentService;

    public void placeOrder() {
        paymentService.processPayment();
    }
}

Misstake 2: Using @Autowired Without Qualifiers When Multiple Beans Exist

The mistake:

@Autowired
private PaymentService paymentService; // NoUniqueBeanDefinitionException at startup

Or the even worse variant:

@Autowired
private List<PaymentService> paymentServices; // You get all implementations in unknown order

Suddenly adding a new payment provider (say, Zalo Pay, Apple Pay) breaks production because the list order changed or the wrong one was injected.

The Fix (choose one):

• Primary bean + @Primary
• @Qualifier("stripePaymentService")
• Better: Strategy pattern with a Map<String, PaymentProvider> injected and qualified by name
• Best: Small focused interfaces instead of one fat PaymentService interface

Mistake 3: Misusing @Configuration and @Bean

Developers often struggle with when and how to define a "bean" outside of the standard component scanning.

The Mistake:

Defining a configuration method as @Bean within a class that isn't annotated with @Configuration (or an equivalent like @SpringBootApplication). Furthermore, they might accidentally create multiple instances of a singleton bean when it should be managed by the container.

The Fix:

A method annotated with @Bean is designed to be executed by a class annotated with @Configuration. This combination tells Spring, "When the application starts, run this method and register its return value as a singleton object (a bean) in the IoC container." Understand that most beans default to the singleton scope, aligning with the OOP practice of having a single point of control for certain resources.

Mistake 4: Logic Overload in Controllers

This is arguably the most common mistake that violates the Single Responsibility Principle (SRP).

The Mistake:

Developers, in an effort to speed up development, place business logic, complex data validation, or even direct database access logic inside the @RestController methods.

// Bad Practice: Controller doing too much
@RestController
public class UserProfileController {
    @Autowired private UserRepository repository;

    @PostMapping("/users")
    public ResponseEntity<User> createUser(@RequestBody User user) {
    // Business logic/validation here instead of Service layer
       if (user.getAge() < 18) {
            throw new InvalidUserException();
        }
      // Direct repository call
        repository.save(user);
      // ...
     }
}

The Fix:

Enforce strict layering.

• Controller (@RestController): Only handles HTTP request/response mapping, request validation (e.g., using JSR-303 annotations like @Valid), and calling the appropriate Service layer method. It acts as the "gatekeeper."

• Service (@Service): Holds all the business logic, transaction boundaries (@Transactional), and orchestrates calls to multiple Repositories. It's the "brain" of the application.

• Repository (@Repository): Only handles direct data access operations (CRUD) against the persistence store. @Repository enables exception translation from SQLException → DataAccessException hierarchy. If you slap @Component on your JPA repositories, you lose that translation and end up with raw, unchecked exceptions bubbling up. 

Mistake 5: Missing or Misplaced Transactional Boundaries

The Mistake:

Two opposite extremes I see constantly:

A. Forgetting @Transactional entirely → no rollback on exceptions B. Putting @Transactional on every service method → huge transactions, table locks, deadlocks

Worse: self-invocation bypasses the proxy.

@Service
public class OrderService {
    public void createOrder() {
        validateOrder(); saveOrder();
        // No transaction here because of self-call!
    }
    @Transactional
    public void saveOrder() {
       ...
    }
}

The Fix:

• Put @Transactional only on the public method that orchestrates the use case
• Never call @Transactional methods from within the same class
• If you must, extract to another Spring bean or use @Transactional(propagation = REQUIRES_NEW) carefully
• Always set readOnly = true for query methods
• Use @Transactional on class level only if literally every method needs it (rare)

Mistake 6: Not Understanding N+1 Queries and Fetch Strategies

The Mistake:

In MyBatis, the N+1 problem commonly happens when a developer defines a parent-child mapping where the child collection is loaded using another SQL query inside the <collection> tag.

<resultMap id="userResultMap" type="User">
    <id property="id" column="id"/>
    <result property="name" column="name"/>

    <!-- Causes N+1 queries -->
    <collection property="orders"
        ofType="Order"
        select="findOrdersByUserId"
        column="id"/>
</resultMap>

If you call

List<User> users = userMapper.findAllUsers();

MyBatis will execute: 1 query to retrieve all users + N queries to retrieve orders for each user

1 (parents) + N (children) = N+1 queries

The fix:

The most efficient way to avoid the N+1 problem in MyBatis is to replace nested selects with a single JOIN query, and let MyBatis map the flattened results.

<select id="findAllUsersWithOrders" resultMap="userOrderResultMap">
    SELECT u.id AS user_id,
        u.name,
        o.id AS order_id,
        o.product_name
FROM users u
LEFT JOIN orders o ON u.id = o.user_id

</select>

    <resultMap id="userOrderResultMap" type="User">
        <id property="id" column="user_id"/>
        <result property="name" column="name"/>
        <collection property="orders" ofType="Order">
        <id property="id" column="order_id"/>
        <result property="productName" column="product_name"/>
         </collection>
</resultMap>

• Only one SQL call is executed.

• MyBatis maps the parent-child relationships in memory.

• No performance penalties from multiple round-trips to the database.

Mistake 7: Storing Sensitive Data in application.properties / application.yml

This is a critical security vulnerability.

The Mistake:

Hardcoding sensitive information such as database passwords, API keys, or cloud credentials directly into the application's configuration files. This is easily exposed if the source code is compromised or accidentally checked into a public repository.

The Fix:

Use Environment Variables or Externalized Configuration. Spring Boot is designed to read configuration properties from multiple sources, with environment variables taking precedence.

# Instead of:
# spring.datasource.password=myhardcodedsecret

# Use this in application.properties/yml:
spring.datasource.password=${DB_PASSWORD} 

Then, set the DB_PASSWORD environment variable on the server. For production, consider dedicated tools like Spring Cloud Config or secrets managers (e.g., AWS Secrets Manager, HashiCorp Vault).

Mistake 8: Leaking Entity Objects Out of the Service Layer

This violates encapsulation and can lead to unintended state changes.

The Mistake:

Returning the raw JPA @Entity objects directly  (or mybatis) from a Service layer method to the Controller, and then exposing them as the JSON response. This breaks the domain boundary. Furthermore, lazy-loaded collections on the Entity might be accessed outside of the transaction scope (e.g., in the Controller or during JSON serialization), leading to a dreaded LazyInitializationException.

The Fix:

Implement the Data Transfer Object (DTO) pattern. The Service layer should map the internal @Entity objects to an external DTO before returning it. The Controller only works with DTOs. This ensures encapsulation (internal data structure is protected) and prevents serialization errors.

Even though you don't have JPA’s LazyInitializationException or persistence-context issues, you still get:

// Bad Practice: Relying on default behavior
@Service public class EmailService{      @Async public void sendEmail(String recipient){ // Expensive IO operation     }  }

Whether you need scalable software solutions, expert IT outsourcing, or a long-term development partner, ISB Vietnam is here to deliver. Let’s build something great together—reach out to us today. Or click here to explore more ISB Vietnam's case studies.

 What is Queue?

• •  Sending an email.
  •  Processing and resizing images when users upload.
  •  Sending notifications to multiple people.
  •  Generating PDF reports.
  •  Processing payments.

Why should we use Queues?

1. 1. Save user information.
   2. Create email content.
   3. Send an email.
   4. Return results to the browser.

1. 1. Save user information.
   2. Push the email request to the queue.
   3. Return results immediately to the user.
   4. Send an email in the background.

How to implement Laravel Queues simply

Step 1: Configure Queues Driver

Step 2: Create a Job

Step 3: Dispatching Jobs

 Step 4: Run the Queue Worker

Conclusion

Whether you need scalable software solutions, expert IT outsourcing, or a long-term development partner, ISB Vietnam is here to deliver. Let’s build something great together—reach out to us today. Or click here to explore more ISB Vietnam's case studies.

[References]

1. https://laravel.com/docs/12.x/queues
2. https://viblo.asia/p/gioi-thieu-ve-queues-trong-laravel-gAm5yqgD5db
3. https://www.luckymedia.dev/blog/laravel-for-beginners-using-queues (Image source)