Securing Modern SPA Applications with OAuth 2.0 Authorization Code Flow

A few years ago, authentication was much simpler in most enterprise applications.

Most applications were server-rendered, where both frontend and backend lived together in the same application. The backend handled authentication completely — managing user sessions, storing client secrets securely, and communicating directly with authentication providers. Since everything sensitive stayed on the server side, traditional OAuth Authorization Code Flow worked without many concerns.

But application architecture has changed a lot over the years.

Modern web applications are no longer simple server-rendered systems. Today’s frontend applications are usually built using frameworks like Angular or React and communicate with backend APIs independently. This architecture gives us better scalability, cleaner separation between frontend and backend, and a much smoother user experience.

At the same time, it also introduces new security challenges around authentication and token handling.

Unlike backend applications, frontend SPA applications run entirely inside the browser. That means we can no longer safely store sensitive credentials like client secrets inside the application because browser code is publicly accessible.

This became a major concern in OAuth-based authentication flows.

Earlier, applications commonly used the OAuth Implicit Flow for browser applications, but over time it became clear that exposing tokens directly in the browser was not the safest approach. Authorization codes could potentially be intercepted, and frontend applications had no secure way to protect secrets like backend servers do.

That is exactly why PKCE was introduced.

What is PKCE?

PKCE (Proof Key for Code Exchange) is a security extension added to the OAuth 2.0 Authorization Code Flow.

It was introduced to secure public client applications such as:

• Angular applications
• React applications
• Mobile applications
• Single Page Applications (SPAs)

Unlike backend applications, frontend applications cannot securely store client secrets because all code is accessible in the browser. PKCE solves this problem by introducing a temporary secret generated during login.

Why PKCE is Important in Modern Applications

Traditional OAuth flows were vulnerable to authorization code interception attacks.

Without PKCE:

1. User logs in
2. Authorization server returns authorization code
3. Frontend exchanges code for access token

If an attacker intercepts the authorization code, they may generate valid tokens.

PKCE prevents this by adding two important values:

ValuePurposecode_verifierRandom secret generated by frontendcode_challengeSHA-256 hashed version of verifier

The authorization server validates both values before issuing tokens.

Even if the authorization code is intercepted, it cannot be used without the original verifier.

High-Level Architecture

Our implementation includes:

ComponentTechnologyFrontend SPAAngular / ReactAuthorization ServerOktaBackend APISpring BootAuthentication ProtocolOAuth 2.0 with PKCE

PKCE Authentication Flow

Step 1 — Configure Okta Application

First, create an application in Okta.

Create SPA Application

Inside Okta:

1. Go to Applications
2. Click Create App Integration
3. Choose:

• Sign-in method → OIDC
• Application type → Single Page Application (SPA)

Configure Redirect URIs

Add your frontend redirect URLs:

For Angular:

http://localhost:4200/login/callback

For React:

http://localhost:3000/login/callback

Enable PKCE

Okta automatically enables PKCE for SPA applications.

After creation, note down:

• Client ID
• Issuer URL

Example:

Issuer: https://dev-123456.okta.com/oauth2/default
Client ID: 0oa123example

Step 2 — Configure Angular / React Application

Frontend applications use Okta SDKs to simplify authentication handling.

Angular Configuration

Install Okta SDK

npm install @okta/okta-angular @okta/okta-auth-js

Configure Okta

Create okta.config.ts:

import { OktaAuth } from '@okta/okta-auth-js';

export const oktaConfig = new OktaAuth({
  issuer: 'https://dev-123456.okta.com/oauth2/default',
  clientId: '0oa123example',
  redirectUri: window.location.origin + '/login/callback',
  scopes: ['openid', 'profile', 'email'],
  pkce: true
});

What Each Property Does

PropertyPurposeissuerOkta authorization server URLclientIdUnique application identifierredirectUriURL Okta redirects to after loginscopesDefines user information accesspkceEnables PKCE Authorization Flow

React Configuration

Install Dependencies

npm install @okta/okta-react @okta/okta-auth-js

Configure Okta

const oktaConfig = {
  issuer: 'https://dev-123456.okta.com/oauth2/default',
  clientId: '0oa123example',
  redirectUri: window.location.origin + '/login/callback',
  scopes: ['openid', 'profile', 'email'],
  pkce: true
};

What Happens During Login?

When the user clicks Login:

1. Angular/React generates:

• code_verifier
• code_challenge

1. User is redirected to Okta /authorize endpoint
2. User authenticates successfully
3. Okta returns an authorization code
4. Frontend sends:

• authorization code
• code verifier

1. Okta validates both values
2. Okta returns JWT tokens

Understanding JWT Tokens

After successful authentication, Okta returns:

TokenPurposeAccess TokenUsed to call backend APIsID TokenContains user identity informationRefresh TokenUsed to obtain new access tokens

JWT (JSON Web Token) contains encoded user claims such as:

{
  "sub": "user123",
  "email": "user@example.com",
  "roles": ["USER"],
  "exp": 1712345678
}

JWT tokens are digitally signed by Okta, allowing backend APIs to verify authenticity.

Step 3 — Configure Spring Boot Backend

The backend acts as a Resource Server and validates JWT tokens issued by Okta.

Add Dependencies

Gradle

implementation 'org.springframework.boot:spring-boot-starter-security'
implementation 'org.springframework.boot:spring-boot-starter-oauth2-resource-server'

Configure Application Properties

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://dev-123456.okta.com/oauth2/default

Spring Security automatically downloads Okta’s public keys and validates JWT signatures.

Spring Security Configuration

@Configuration
@EnableWebSecurity
public class SecurityConfig {    
@Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/actuator/**").permitAll()
                .anyRequest().authenticated()
            )
            .oauth2ResourceServer(oauth2 ->
                oauth2.jwt()
            );
        return http.build();
    }
}

How JWT Validation Works in Spring Boot

When the frontend calls a secured API:

Authorization: Bearer eyJhbGciOi...

Spring Security performs:

1. JWT signature verification
2. Expiration validation
3. Issuer validation
4. Claim extraction
5. User authentication setup

Only valid tokens are allowed to access protected APIs.

Why PKCE is the Recommended Standard Today

PKCE is now considered the recommended OAuth flow for browser-based applications because:

No client secret required
More secure than implicit flow
Prevents authorization code theft
Supported by Okta and modern OAuth providers
Works seamlessly with Angular, React, and Spring Boot

Final Thoughts

As frontend applications continue moving toward SPA architectures, securing authentication flows becomes critical.

Using PKCE with Angular or React, Okta as the identity provider, and Spring Boot as the secured backend creates a modern and secure authentication architecture.

With minimal configuration, developers can implement enterprise-grade OAuth security while protecting users and APIs from common attack vectors.

References

• OAuth 2.0 PKCE Flow Documentation
• Okta Developer Documentation
• Spring Security OAuth2 Resource Server

Integrating SonarQube with a Spring Boot project using Gradle primarily involves installing the SonarQube server, adding the necessary Gradle plugins, and configuring the analysis properties. Maintaining clean, reliable, and secure code is a cornerstone of modern software development. As applications scale, manually tracking issues, code smells, or test coverage becomes nearly impossible. That’s where SonarQube comes in as a powerful, open-source platform designed for continuous code quality inspection and automated static analysis.

In this blog post, we’ll explore how SonarQube helps developers write better code and walk through the process of integrating it into a Spring Boot project using Gradle.

What is SonarQube?

SonarQube is an open-source code quality management platform that continuously analyzes your source code, providing insights into bugs, vulnerabilities, and maintainability issues.

Here’s what makes SonarQube so valuable:

• Code Analysis: Performs in-depth analysis for multiple programming languages like Java, Kotlin, Python, C/C++, and JavaScript.
• Code Quality Metrics: Measures code duplication, complexity, and test coverage while offering recommendations to improve maintainability.
• Issue Detection: Identifies bugs, security vulnerabilities, and code smells before they reach production.
• CI/CD Integration: Seamlessly integrates into your existing CI/CD pipeline to automate quality checks.

Why SonarQube, SpringBoot & Gradle?

The combination of SonarQube, Spring Boot, and Gradle is popular because they each fulfill crucial roles in the modern Java development lifecycle, creating an efficient and high-quality build and release pipeline.

Step 1: Set Up SonarQube Locally

You can quickly get started with SonarQube in one of two ways:

Option 1: Using Docker

docker run -d — name sonarqube -p 9000:9000 sonarqube

Option 2: Manual Download
Download from the official SonarQube website and start the server.

Once running, access the web dashboard:
http://localhost:9000

Step 2: Integrate SonarQube into Your Spring Boot Project (Gradle)

In your Spring Boot project, you can easily add SonarQube integration using the Gradle SonarQube Plugin.

Add the SonarQube Plugin

In your build.gradle, include the SonarQube plugin under the plugins block:

plugins { 
 id 'java' 
 id 'jacoco' // for test coverage 
 id 'org.sonarqube' version '5.0.0.4638' 
}

Configure SonarQube Task Dependencies

Ensure that the SonarQube analysis runs after the tests are completed:

tasks.named('sonarqube'). configure { 
 dependsOn test 
}

Step 3: Add a SonarQube Configuration File

If your project doesn’t already have one, create a file named sonarqube.gradle inside the gradle/ directory.

• The test task is finalized by jacocoTestReport.
• The jacocoTestReport task ensures XML reporting is required:

Here’s a sample configuration:

tasks.named('test') { 
 useJUnitPlatform() 
 finalizedBy jacocoTestReport 
} 
 
jacoco { 
 toolVersion = '0.8.13' 
} 
 
jacocoTestReport { 
 dependsOn test 
 reports { 
 xml.required = true 
 html.required = true 
 } 
} 
 
sonarqube { 
 properties { 
 property "sonar.coverage.jacoco.xmlReportPath", "$build/reports/jacoco/test/jacocoTestReport.xml" 
 property "sonar.junit.reportPaths", "$build/test-results/test" 
 property "sonar.verbose", true 
 property "sonar.sources", "src/main" 
 property "sonar.tests", "src/test" 
 property "sonar.host.url", "http://localhost:9000" 
 property "sonar.projectName", "demo" 
 property "sonar.projectKey", "demo" 
 property "sonar.login", "" --replace sonar token here 
 } 
}

Explanation of Each Property

• sonar.coverage.jacoco.xmlReportPath → Points SonarQube to the JaCoCo XML coverage report so test coverage data can be included in analysis.
• sonar.junit.reportPaths → Specifies the path to JUnit test result reports for detailed test execution tracking.
• sonar.verbose → Enables detailed logging during the analysis process.
• sonar.sources → Defines the directory that contains the main application source code.
• sonar.tests → Identifies where the unit or integration test code resides.
• sonar.host.url → The URL where your SonarQube server is running (default http://localhost:9000).
• sonar.projectName → Friendly name of your project as it appears in the SonarQube dashboard.
• sonar.projectKey → A unique identifier used by SonarQube to reference your project.
• sonar.login → Authentication token for securely uploading analysis results (token-based authentication is required in modern SonarQube versions).

Apply the Configuration in Your Build

In your main build.gradle, include this line at the end to apply the custom configuration:

apply from: "gradle/sonarqube.gradle"

Step 4: Running SonarQube Analysis

To trigger a SonarQube scan, execute the following Gradle command:

./gradlew sonar

This command compiles your code, runs tests, generates JaCoCo coverage reports, and sends the analysis results to the configured SonarQube server.

Step 5: Viewing the Reports

Once the build completes successfully, open your browser and go to:

http://localhost:9000

You’ll be able to view:

• Code coverage percentages
• Bugs, vulnerabilities, and code smells
• Maintainability and reliability ratings
• Test results and duplication metrics

SonarQube presents these insights in an interactive dashboard, helping teams visualize code quality trends over time.

Conclusion

Integrating SonarQube into your Spring Boot project using Gradle is a simple yet highly effective step toward maintaining a healthy, maintainable codebase.

With SonarQube and JaCoCo combined, you’ll gain actionable insights into code coverage, potential issues, and technical debt all before deployment.

By automating this analysis as part of your build process, you ensure continuous improvement in code quality, security, and reliability.

Elevate Your Code Quality: Integrating SonarQube with a Spring Boot Project using Gradle was originally published in tech.at.core on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction:

Imagine you’re part of a fast-paced Angular project, collaborating with multiple developers who are constantly pushing code, fixing bugs, and rolling out new features. In such a dynamic environment, even the smallest oversight can snowball into major slowdowns. A developer might forget to format their code, a linting error could sneak past unnoticed, or a test might fail after a seemingly harmless commit. Individually, these issues may appear minor, but once they hit the CI/CD pipeline, they can derail progress, forcing the team to waste valuable time addressing problems that could’ve been caught much earlier.

That’s where pre-commit hooks come to the rescue. Think of them as tiny, automated guards standing at the door of your Git repository. Every time you try to commit code, these guards quickly check, “Is this code clean? Is it properly formatted? Did it pass all the basic checks?” If something’s off, they stop the commit right there before bad code ever gets in.

Now, tools like Husky, lint-staged, and Prettier make this process seamless. Husky links your Git workflow to custom scripts. Lint-staged checks only the files you changed. Prettier keeps your code looking consistent for the whole team. Together, they automate code quality, so you don’t have to think about it every time.

In this blog post, we will explore how to set up and configure pre-commit hooks in an Angular project

What is a Pre-Commit Hook in Angular?

A pre-commit hook in Angular, or any Git project, is an automatic check. It runs before you commit your code.

Think of it like a final “code check gatekeeper.” When you run git commit, the pre-commit hook checks your code. It makes sure your code follows standards. This includes formatting, passing lint rules, and running tests successfully. Only after these checks can the commit go through.

If everything looks good, the commit happens. If not, it stops you right there so you can fix the problem first.

Why It’s Important in Angular Projects

Angular projects often have multiple developers working together. Everyone might use different code editors or have slightly different formatting habits. Over time, this can lead to messy code. Small issues, like missing semicolons, unused imports, or failed tests, can slip into the repository.

Pre-commit hooks prevent that from happening. They automate the important checks, so you won’t accidentally commit broken or poorly formatted code. This keeps your Angular project:

• Clean (consistent formatting and structure)
• Stable (no broken tests or linting errors)
• Collaborative (everyone follows the same rules automatically)

Setting Up Pre-Commit Hooks with Husky

There are multiple ways to configure Git hooks, but one of the most convenient approaches for JavaScript/TypeScript projects is using the Husky library. Husky makes it easy to manage hooks and share the setup across your team.

Let’s walk through the setup for a React (or any Node-based frontend) application.

Step 1: Install Husky

Install Husky as a dev dependency:

npm install husky - save-dev

Step 2: Enable Husky in Your Repository

Run the following command to initialize Husky:

npx husky install

This creates a .husky/ directory in your project root and sets up Git hooks.

To make sure Husky is automatically enabled for all contributors, add this script in your package.json:

"scripts": {"prepare": "husky install" }

Step 3: Add a Pre-Commit Hook

Now, let’s create a pre-commit hook that runs your tests and lint checks before committing. Run:

npx husky add .husky/pre-commit “npm run test:ci && npx lint-staged”

This generates a file .husky/pre-commit with the following content:

#!/usr/bin/env sh. "$(dirname - "$0")/_/husky.sh" 
# Exit immediately if a command fails set -e 
# Run frontend tests in CI mode (exit on success/failure)npm run test:ci 
# Run lint checks on staged filesnpx lint-staged

Step 4: Understanding the Hook Script

Here’s a quick breakdown of what each line does:

• #!/usr/bin/env sh → Tells the system to execute the script using sh.
• . “$(dirname — “$0”)/_/husky.sh” → Loads Husky’s internal helper functions.
• set -e → Ensures the script stops immediately if any command fails.
• npm run test: ci → Runs frontend tests in continuous integration mode.
• npx lint-staged → Runs linting on only the staged files, ensuring faster feedback.

Step 5: Verify the Setup

Try committing some code:

git add . 
git commit -m "test commit"

If tests or linting fail, the commit will be blocked until the issues are fixed.

Skipping Hooks (If needed)

If you want to bypass the pre-commit checks (for example, in temporary WIP commits), you can use the — no-verify flag:

git commit - no-verify -m "quick commit"

Use this sparingly — skipping validations defeats the purpose of clean, consistent code.

Conclusion

By adding Husky pre-commit hooks to your frontend workflow, you:

• Catch linting and test issues before they reach the pipeline.
• Eliminate unnecessary “fix build” commits from Git history.
• Improve code quality and maintain consistency across your team.

With just a few steps, you can ensure that every commit meets your project’s coding and testing standards.

Using Husky and Lint-Staged: Enforce Code Quality in Angular Using Pre-Commit Hooks was originally published in tech.at.core on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction:

Imagine you’re building a new project based on code. You write your code, everything looks great on your device, and you push it up to the shared repository. Immediately, you get that dreaded notification: “CI/CD Pipeline Failed. Developers push code that looks fine locally but breaks an automated check (like formatting rules, missing tests, or static analysis) in the central Continuous Integration/Continuous Delivery (CI/CD) pipeline.

Fixing these problems often results in “noise commits” like Build fixes or Fix formatting, which clutters the Git history. A pre-commit hook is a script that runs before you complete a git commit action, allowing you to inspect the code that’s about to be committed. When integrating this with a Spring Boot Gradle project, the hook is typically used to automatically enforce quality checks, code formatting, and running tests against the staged files, ensuring that only high-quality, compliant code makes it into the repository.

In this blog post, we will discuss the Pre-Commit hook and how it works with Spring Boot for automating code quality.

What Is a Pre-Commit Hook?

A pre-commit hook is a small script that runs automatically before you make a Git commit.
Think of it as your local quality gatekeeper checks your code before it leaves your device.

With a pre-commit hook, you can:

• Run static code analysis and formatting checks.
• Execute unit tests.
• Enforce coding standards.
• Prevent sensitive files (like .env or secrets) from being committed.

Why Use Pre-Commit Hooks in a Spring Boot + Gradle Project?

Spring Boot projects often rely heavily on Gradle tasks for building and testing.
By combining Gradle with pre-commit hooks, you can automate essential checks before every commit without slowing down your workflow.

Here are a few common checks to automate:

• Code formatting using Spotless.
• Static analysis with Checkstyle.
• Running unit tests using./gradlew test.
• Verifying build integrity using./gradlew build — dry-run.
• Preventing sensitive data from being committed.

Step 1: Create a Pre-Commit Script

First, add a 'scripts' folder (if it's not already present) at the root of your project. Inside it, create a file named pre-commit with the following content:

Example hook adding-

#!/bin/bash echo "Running pre-commit checks..."#  
# Run unit tests./gradlew test || { 
  echo "Unit tests failed. Fix test failures before committing."exit 1 
} 
# If everything succeedsgit add .echo " All checks passed. Proceeding with commit." exit 0 

This script ensures that all tests succeed before the commit is created. If any step fails, the commit will be blocked until the issues are fixed.

Step 2: Automate Hook Installation

To make sure every developer has the hook in place, we can automate its installation via Gradle.

Create a new file pre-commit-hook. gradle inside the gradle folder with the following content:

tasks.register('installLocalGitHook', Copy) { 
    from new File(rootProject.rootDir, 'scripts/pre-commit') 
    into new File(rootProject.rootDir, '.git/hooks') 
    fileMode = 0775 
} 

This task copies the pre-commit script from the scripts folder into .git/hooks so that Git will execute it before every commit.

Step 3: Apply the Hook in build.gradle

In your project’s build. gradle, include the hook configuration so that it’s automatically set up:

apply from: 'gradle/pre-commit-hook.gradle' 

OR

Add this set of code directly in build .gradle

tasks.register('installLocalGitHook', Copy) { 
    from new File(rootProject.rootDir, 'scripts/pre-commit') 
    into new File(rootProject.rootDir, '.git/hooks') 
    fileMode = 0775 
}

And run the command below

Now, whenever you run the following command, the pre-commit hook will be installed:

./gradlew installLocalGitHook

Step 4: Verifying the Setup

Once installed, you can confirm that the hook is correctly placed by checking:

cat .git/hooks/pre-commit

If the contents match your script, the setup is successful. From this point onward, Git will run your checks before allowing a commit.

Skipping Hooks (When Needed)

There may be times when you want to bypass the pre-commit checks (e.g., for WIP commits). Git provides an option to skip hooks:

git commit - no-verify -m "Temporary commit"

However, it’s best to use this sparingly to maintain a clean and reliable history.

Benefits

• Cleaner Git history: eliminates “fix build” commits.
• Improved code quality: ensures formatting, and tests always pass locally.
• Team consistency: all developers follow the same rules automatically.
• Faster feedback: errors are caught before they even reach CI/CD pipelines.

Final Thoughts

Implementing pre-commit hooks in your Spring Boot Gradle project may seem like a small change, but it has a big impact on maintaining project quality. By automating checks at the source, you eliminate noisy commits, enforce consistent standards, and ensure that every piece of code merged into the repository meets your team’s expectations. It’s a proactive step toward cleaner collaboration and a more reliable CI/CD workflow.

Prevent Bad Commits Before They Happen: Automate Code Quality in Spring Boot with Pre-Commit Hooks was originally published in tech.at.core on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction:

Let’s start with an example, when creating a web application, the development process must be as fast and efficient as possible, and the configuration must be minimal. Setting up a Spring-based project has traditionally been a problem because it often requires extensive XML configuration, dependency management, and boilerplate code, which slows down development time and increases complexity.

However, Spring Boot simplifies this process, allowing you to quickly generate production-ready Spring applications with minimal configuration.

In this blog, we will walk you through setting up Spring Boot using Maven and Gradle, covering the installation process and system requirements. Let’s get started!

Getting Started with Spring Boot: Essential Prerequisites

Before getting started with Spring Boot, make sure you have the following in place:

1. Java
   Spring Boot applications are written in Java, so you must have Java installed on your system. Spring Boot is compatible with Java 8, 11, 16, and 17. Ensure your environment variables are properly configured.
2. Integrated Development Environment (IDE)

You can use any Java IDE of your choice for Spring Boot development. Popular options include Eclipse, IntelliJ IDEA, Visual Studio Code. Among these, I personally recommend IntelliJ IDEA, as it provides powerful features, seamless integration with Spring Boot, and an overall smooth developer experience. IntelliJ’s intelligent code assistance, built-in Spring support, and wide range of plugins make it an excellent choice for both beginners and experienced developers.

3. Installing Spring Boot

You can use Spring Boot with standard Java tools (STS) or as a command-line tool. Either way, Java SDK 17 or higher is required. Check your version using:

$ java -version

If you’re new to Java or want to experiment quickly, start with the Spring Boot CLI. Otherwise, follow the traditional setup instructions below.

4. Step-by-Step Guide: Spring Boot Setup via Spring Initializr

Step 1: Go to Spring Initializr

Open your browser and visit: https://start.spring.io

Step 2: Fill Project Details
You’ll see a form where you can configure your project:

• Project: Choose Maven or Gradle
• Language: Select Java
• Spring Boot version: Use the latest stable version

(e.g., 4.0.0 (SNAP SHOT), 4.0.0 (M1), 3.5.5 (SNAP SHOT), 3.4.9 (SNAP SHOT) 3.4.8 etc..)

Project Metadata:

• Group : e.g. com.example
• Artifact : e.g. demo
• Name : demo
• Description : Simple Spring Boot project
• Package Name : auto-filled
• Packaging : Jar
• Java : 24, 21, 17 or (based on your JDK)

Step 3: Add Dependencies
Dependencies are modules or libraries that add functionality to your project like connecting to a database, creating REST APIs, handling security, or rendering web pages. Spring Boot makes this easy by offering a wide range of pre-packaged starters.

When you use Spring Initializr, you simply select the features you need, and it adds the appropriate dependencies to your project’s build file (pom.xml for Maven or build.gradle for Gradle).

Click “Add Dependencies” and search what dependencies we need:

• Spring Web (for REST APIs)
• Spring Boot Dev Tools (for auto-reload during development)
• Spring Data JPA (for database access)
• H2 Database (for in-memory DB testing)

Step 4: Generate Project

• Click the “Generate” button.
• A .zip file will be downloaded with your project structure.

Step 5: Unzip & Open in IDE

• Unzip the file
• Open the folder using IntelliJ IDEA, Eclipse, or VS Code
• If you’re using IntelliJ IDEA:
• Choose File > Open > Select the folder
• Let it import Maven/Gradle dependencies
• Now all the dependencies are loaded successfully

Step 6: Run the Application

• Navigate to the main class DemoApplication.java (inside src/main/java/…)

5. Go to Main Class : The main class will look like below

import org.springframework.boot.SpringApplication; 
import org.springframework.boot.autoconfigure.SpringBootApplication; 
 
@SpringBootApplication 
public class DemoApplication { 
 
    public static void main(String[] args) { 
        SpringApplication.run(DemoApplication.class, args); 
    } 
}

@SpringBootApplication annotation tells Spring Boot that this is the entry point for your application.

6. Write Your First Controller: Create a simple controller class that handles HTTP requests. Use annotations like @RestController and @RequestMapping to define your endpoints and methods. Your main class will look like this now.

import org.springframework.boot.SpringApplication; 
import org.springframework.boot.autoconfigure.SpringBootApplication; 
import org.springframework.web.bind.annotation.GetMapping; 
import org.springframework.web.bind.annotation.RestController; 
 
@SpringBootApplication 
@RestController 
public class DemoApplication { 
 
    public static void main(String[] args) { 
        SpringApplication.run(DemoApplication.class, args); 
    } 

    @GetMapping("/hello") 
    public String sayHello() { 
        return "Hello, Spring Boot!"; 
    } 
}

7. Run Your Application: Run the main class (typically named Application) in your IDE or use terminal commands (./mvnw spring-boot:run for Maven, ./gradlew bootRun for Gradle). In IDE right-click on your project select run as spring boot app.

8. Access Your App: Open a web browser and go to http://localhost:8080/hello to see your Spring Boot application in action and you will get “Hello, Spring Boot!”.
Your Spring Boot app is now up and running at Tomcat Server (Apache tomcat) with certain port (http://localhost:8080)

Another Scenario:

• Explore Zip
• Click on “Build Gradle”
• Select dependencies from build Gradle and then copy.

Search & Copy Dependency for Maven/Gradle

1. Open browser in your PC/Laptop

2. Search Mavan Repository or Copy and paste to search the link https://mvnrepository.com/

3. Search for the dependency (e.g., spring-boot-starter-web)

4. Click on the correct library and version

5. Scroll down to find dependency code like this:

For Maven (pom.xml):

Gradle :

Conclusion
Spring Boot makes it simple to build, run, and manage Java applications. It helps developers start projects faster with very little setup, thanks to built-in support for tools like Maven and Gradle. Features like automatic configuration, built-in servers, and helpful developer tools save time and effort.

Whether you’re building something small with the Spring Boot CLI or adding it to a bigger project, Spring Boot gives you a strong, easy-to-use foundation for apps that can grow and are easy to maintain.

“In today’s fast-paced tech world, efficiency is essential. Spring Boot offers a streamlined development approach that saves time, minimizes errors, and makes building applications faster and smoother.”

Simplifying Spring Boot Setup: Step-by-Step Process to Spring Initializer was originally published in tech.at.core on Medium, where people are continuing the conversation by highlighting and responding to this story.