DEV Community: Tomasz Szewczyk

Next.js vs pure React - what we would choose for a landing page, SPA, and e-commerce

Tomasz Szewczyk — Tue, 03 Feb 2026 19:23:58 +0000

Working title and summary

Choosing a web technology stack is no longer about what is fashionable. For established businesses, it is about what can be owned, operated, and evolved over many years. Next.js and so called pure React are often discussed as interchangeable, but in practice they solve different problems and introduce different risks. This article compares the two approaches across three concrete project types - a marketing landing page, a business SPA, and an e-commerce system - and explains why the right choice is not the same in each case.

Target reader and business context

This comparison is written for owners, directors, and technical decision makers in established small to medium businesses. These organisations usually operate existing systems, have compliance and security obligations, and care about predictable costs. Technology decisions are expected to survive staff changes, integrate with legacy infrastructure, and remain maintainable without constant rewrites. In markets like Poland, where many companies work with external partners such as a software house poland, long term ownership and clarity of responsibility matter more than early adoption of new patterns.

What "pure React" actually means today

The term pure React is often misunderstood. React is not a complete application framework. It is a user interface library responsible for rendering components and managing state. In production systems, React is always part of a broader setup that includes a build tool, routing, data access, and a deployment model.

In modern projects, pure React usually means React combined with a fast bundler such as Vite, a client side router, and explicit API communication with backend services. The result is most often a single page application that runs in the browser after loading an initial HTML shell. Hosting is straightforward, because the output consists of static files that can be served by almost any web server or CDN.

Pure React is also commonly embedded into existing systems. Many established businesses already have backends written in Java, .NET, or PHP. In those cases, React acts only as the frontend layer, while authentication, business logic, and data persistence remain in existing services. This separation aligns well with long term ownership and reduces architectural coupling.

There are also hybrid approaches. React can be used inside meta frameworks such as Astro, where most content is rendered as static HTML and React is reserved for interactive parts. Newer runtimes like Deno or Bun can host React tooling, but for most businesses they remain alternatives rather than defaults. The key point is that pure React is not a product, but a set of deliberate architectural choices.

Comparison framework

Rather than comparing feature lists, this article focuses on operational questions. How is content rendered and delivered. How does this affect search engines. What infrastructure must be run and monitored. How difficult is it to upgrade the system after several years. And what risks are introduced if requirements change.

These factors matter more to established businesses than marginal performance gains or developer convenience.

Landing page case

A typical landing page focuses on content, brand presentation, and lead generation. SEO and fast initial load times are critical. Content changes occasionally, but not per user.

Next.js fits this model well. It supports static generation, meaning pages are rendered ahead of time into HTML. This results in predictable SEO behaviour and fast delivery. Operationally, a statically generated Next.js site can be deployed as static files, avoiding the need for a permanent server process. Routing and metadata handling are structured and easy to maintain as the site grows.

A pure React approach is less suitable. A client rendered React application initially serves little or no content and relies on JavaScript execution to display it. While search engines can execute JavaScript, indexing becomes slower and less reliable. Workarounds such as prerendering exist, but they reintroduce complexity that frameworks like Next.js already solve.

Conclusion for landing pages: if React is required, Next.js is usually the safer choice. In many cases, an even simpler static solution without React may be sufficient, but between these two options, Next.js better supports SEO driven business goals.

SPA case

Business SPAs include internal tools, dashboards, and customer portals. They are often behind authentication and not intended for search indexing. The primary concerns are maintainability, integration with backend systems, and predictable operation.

In this scenario, pure React is usually the better fit. A React SPA communicates directly with existing APIs, keeps rendering on the client, and avoids server side rendering complexity. Hosting remains simple and infrastructure requirements are minimal. Teams retain control over data flow and state management without adapting to framework specific conventions.

Next.js can be used for SPAs, but many of its features add little value here. Server side rendering is rarely needed for authenticated views. Introducing a server runtime increases operational overhead and the potential failure surface without improving outcomes. Long term maintenance also becomes harder, as teams must track framework changes that do not directly benefit the application.

Conclusion for SPAs: for most internal or application style systems, pure React offers lower complexity and lower long term risk.

E-commerce case

E-commerce systems combine public content with highly dynamic user interactions. Product pages must rank well in search engines, and performance directly affects conversion rates. Integrations with payments, logistics, and external services are common.

Next.js offers clear advantages in this context. Server side rendering or static generation ensures product pages are crawlable and fast. Hybrid rendering allows public pages to be optimised for SEO while interactive elements such as carts remain client driven. The framework scales well for large numbers of routes and content heavy structures.

A pure React e-commerce frontend faces structural challenges. Client rendered product pages depend on search engines executing JavaScript, which is slower and less reliable. Prerendering pipelines can reduce the gap, but they often grow into bespoke systems that are expensive to maintain. Over time, the effort required to match the SEO and performance characteristics of server rendered pages usually exceeds the cost of adopting a framework.

Conclusion for e-commerce: Next.js is typically the more appropriate choice, provided the organisation is prepared to operate and maintain a server side environment.

When Next.js is viable

Next.js is a good architectural choice when SEO is a primary concern, when public content must be delivered quickly, and when a unified approach to rendering and routing reduces long term maintenance risk.

When to avoid Next.js

Next.js should be avoided when server side rendering brings little value. This includes internal tools, highly interactive applications, and systems that already rely on established backend architectures. In these cases, the framework increases complexity and cost without improving business outcomes.

SEO considerations

Next.js is often described as better for SEO, but the advantage comes from deterministic HTML output at build or request time, not from the framework itself. Search engines and social platforms consume this output more reliably than content rendered only after JavaScript execution. For non public applications, this advantage is irrelevant and should not influence the decision.

Summary and decision heuristic

The choice between Next.js and pure React depends on what must be rendered, who consumes it, and how long the system must be supported. If public content and discoverability drive value, Next.js usually justifies its complexity. If the system is primarily an application rather than a publication, pure React keeps ownership costs lower.

A practical rule is to ask whether the project benefits from server rendered HTML. If the answer is yes, consider Next.js. If not, pure React is often the more durable option.

Sources and further reading

https://react.dev - explains the scope of React as a UI library
https://vitejs.dev - documents a modern build tool commonly used with React
https://astro.build - shows a static first approach that can still use React components
https://deno.com - illustrates alternative JavaScript runtimes beyond Node
https://bun.sh - presents an emerging runtime and bundler that may influence future tooling choices

Leveraging Stack Traces for SQL Performance Analysis in Spring Boot Applications

Tomasz Szewczyk — Wed, 30 Jul 2025 20:55:08 +0000

Performance optimization in Spring Boot applications often requires deep visibility into database interactions. While traditional logging provides basic SQL query information, it frequently lacks the crucial context of where these queries originate in your codebase. This is especially important with lazy loading of Hibernate entities, where queries can be triggered unexpectedly throughout the application lifecycle. This article demonstrates how to implement a sophisticated logging solution that captures SQL execution stack traces, enabling developers to quickly identify and resolve performance bottlenecks.

The Challenge: Contextual SQL Performance Monitoring

In complex Spring Boot applications, SQL queries can be triggered from various layers—controllers, services, repositories, or even background processes. When performance issues arise, developers often face the challenge of connecting slow queries back to their source code. Standard Hibernate logging shows what queries are executed but not where they're called from, making optimization efforts time-consuming and error-prone.

Solution Architecture: Custom SQL Logging with Stack Traces

The solution involves creating a custom Logback layout that captures and filters stack traces for SQL operations, providing immediate visibility into the execution path. This approach combines Spring Boot's conditional configuration with Logback's extensible logging framework.

All code examples in this article are written in Kotlin, leveraging its concise syntax, null safety, and seamless Java interoperability. Kotlin's expressive language features make the implementation more readable and maintainable compared to traditional Java approaches, while providing full compatibility with the Spring Boot ecosystem.

Conditional Configuration Setup

The foundation begins with a configuration class that activates only when needed:

@Configuration
@ConditionalOnProperty(
    name = ["sql-logging.stack-trace.enabled"],
    havingValue = "true",
    matchIfMissing = false,
)
class LogConfig(
    @Value("\${sql-logging.stack-trace.enabled:false}")
    private val enabled: Boolean,
) {
    @PostConstruct
    fun setMDC() {
        MDC.put("springProfile", activeProfiles.ifBlank { "default" })
        configureSqlLogging()
    }
}

This configuration uses Spring Boot's @ConditionalOnProperty annotation to ensure the enhanced logging is only active when explicitly enabled via the sql-logging.stack-trace.enabled=true property. This design prevents performance overhead in production environments where detailed SQL tracing isn't needed.

Dynamic Logger Configuration

The core logging setup programmatically configures Hibernate's SQL loggers:

private fun configureSqlLogging() {
    val loggerContext = LoggerFactory.getILoggerFactory() as LoggerContext

    val appender = ConsoleAppender<ch.qos.logback.classic.spi.ILoggingEvent>()
    appender.context = loggerContext
    appender.name = "SQL_STACK_TRACE_APPENDER"

    val layout = SqlLogLayout()
    layout.context = loggerContext
    layout.start()
    appender.setLayout(layout)

    appender.start()

    // Configure SQL query logging
    val sqlLogger = loggerContext.getLogger("org.hibernate.SQL") as Logger
    sqlLogger.level = ch.qos.logback.classic.Level.DEBUG
    sqlLogger.isAdditive = false
    sqlLogger.addAppender(appender)

    // Configure parameter binding logging
    val bindLogger = loggerContext.getLogger("org.hibernate.type.descriptor.sql.BasicBinder") as Logger
    bindLogger.level = ch.qos.logback.classic.Level.TRACE
    bindLogger.isAdditive = false
    bindLogger.addAppender(appender)
}

This configuration creates dedicated appenders for both SQL queries and parameter binding, ensuring complete visibility into database operations while maintaining separation from other application logs.

Custom Stack Trace Layout Implementation

The SqlLogLayout class provides intelligent stack trace filtering and formatting:

class SqlLogLayout : LayoutBase<ILoggingEvent>() {
    private val ignoredPackages = setOf(
        "ch.qos.logback",
        "org.slf4j",
        "java.lang.Thread",
        "com.bluesbrackets.config.SqlLogLayout",
    )

    override fun doLayout(event: ILoggingEvent): String = buildString {
        val timestamp = dateFormatter.format(Instant.ofEpochMilli(event.timeStamp))
        appendLine("$timestamp [${event.threadName}] ${event.level} ${event.loggerName} - ${event.formattedMessage}")

        appendLine("=== SQL EXECUTION STACK TRACE ===")

        val stackFrames = Thread.currentThread().stackTrace
            .asSequence()
            .filter { frame -> ignoredPackages.none { frame.className.startsWith(it) } }
            .take(500)
            .toList()

        var lastWasEllipsis = false

        stackFrames.forEach { frame ->
            if (frame.className.startsWith("com.bluesbrackets")) {
                val location = frame.fileName?.let {
                    if (frame.lineNumber > 0) "$it:${frame.lineNumber}" else it
                } ?: "Unknown Source"

                appendLine("    at ${frame.className}.${frame.methodName}($location)")
                lastWasEllipsis = false
            } else {
                if (!lastWasEllipsis) {
                    appendLine("    ...")
                    lastWasEllipsis = true
                }
            }
        }

        appendLine("=== END STACK TRACE ===")
    }
}

Key Features of the Stack Trace Layout

Intelligent Filtering: Excludes framework and logging infrastructure classes to focus on application code
Compact Representation: Groups non-application frames into ellipsis markers to reduce noise
Precise Location Information: Includes file names and line numbers for accurate source mapping
Performance Conscious: Limits stack depth to 500 frames to prevent excessive memory usage

Benefits and Use Cases

Immediate Performance Bottleneck Identification

With this logging configuration, developers can immediately identify the source of problematic queries:

2024-01-15 14:23:45.123 [http-nio-8080-exec-1] DEBUG org.hibernate.SQL - select user0_.id, user0_.email from users user0_ where user0_.status=?
=== SQL EXECUTION STACK TRACE ===
    at com.bluesbrackets.service.UserService.findActiveUsers(UserService.kt:45)
    at com.bluesbrackets.controller.UserController.getActiveUsers(UserController.kt:28)
    ...
    at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1087)
    ...
=== END STACK TRACE ===

This output immediately reveals that the query originates from UserService.findActiveUsers() called by UserController.getActiveUsers(), enabling rapid identification and optimization.

N+1 Query Detection

The stack trace logging excels at detecting N+1 query patterns by showing repeated calls from the same location:

// Multiple similar stack traces pointing to the same method
// indicate potential N+1 query issues
at com.bluesbrackets.service.OrderService.loadOrderItems(OrderService.kt:67)

Optimization Impact Measurement

By comparing logs before and after optimizations, developers can quantitatively measure the impact of their changes, ensuring modifications actually improve performance.

Configuration and Deployment

Development Environment Setup

Add the following property to your application-dev.properties:

logging.sql.stack-trace.enabled=true

Production Considerations

In production environments, disable the enhanced logging to avoid performance overhead:

logging.sql.stack-trace.enabled=false

Alternatively, use Spring profiles to automatically configure appropriate logging levels:

spring:
  config:
    activate:
      on-profile: development
  logging:
    sql:
      stack-trace: 
        enabled: true

Performance Considerations

While this logging approach provides invaluable debugging information, consider these performance implications:

Stack Trace Capture Overhead: Capturing stack traces for every SQL query introduces CPU overhead
Memory Usage: Extended stack traces consume additional memory
I/O Impact: Increased logging volume affects disk I/O performance

Therefore, this configuration should be used judiciously—enabled during development and debugging phases, but disabled in production unless specific performance issues require investigation.

Advanced Usage Patterns

Custom Filtering Logic

Extend the SqlLogLayout to implement application-specific filtering:

private val criticalPackages = setOf(
    "com.yourcompany.service",
    "com.yourcompany.repository"
)

// Filter to show only critical application layers
stackFrames.filter { frame -> 
    criticalPackages.any { frame.className.startsWith(it) }
}

Performance Threshold Logging

Combine this approach with execution time measurement to log stack traces only for slow queries:

if (executionTime > threshold) {
    // Log with stack trace
}

Conclusion

Implementing custom SQL logging with stack traces transforms performance debugging from a reactive, time-intensive process into a proactive, efficient workflow. By providing immediate context for database operations, developers can quickly identify bottlenecks, optimize queries, and maintain application performance standards.

The conditional configuration ensures this powerful debugging tool doesn't impact production performance while remaining readily available for development and troubleshooting scenarios. This approach represents a significant advancement in observability for Spring Boot applications, enabling more efficient development cycles and higher-quality software delivery.

The combination of Spring Boot's conditional configuration, Logback's extensibility, and intelligent stack trace filtering creates a robust foundation for database performance monitoring that scales with application complexity while maintaining operational efficiency.