Professional Project · 2026

Solution Square (Global)

2025 – Present

Screens

Purpose

LS ELECTRIC's global customer portal, providing product information, technical resources, selection tools, and engineering knowledge across regions and languages.

Role · Tech Stack

Contributed to product, dashboard, search, and AI services across Java/Spring backend services, the API servers that receive frontend requests (BFF), and the React/TypeScript front end.

Java · Spring Boot · React · TypeScript · Azure · Elasticsearch · Jenkins

JavaSpring BootReactTypeScriptAzureElasticsearchJenkins

Achievement 01

Unifying Authentication Logic

Background & Cause: The global portal and an asset-management service grew from the same roots. They originally shared one API server that received frontend requests and handled authentication (a BFF). When the owning teams split, the asset-management side got its own API server with a hard copy of the same authentication logic. The copies then diverged and became difficult to diagnose.
Decision & Rationale: I ruled out a dedicated auth server because its operating cost and an extra network hop were not justified for two services. Following the repository convention for shared modules, I extracted session, authentication-token and SAML utilities, then JWT in stages. Each stage was verified before the next, and adapters changed only the connection points rather than both applications at once.
Outcome: Authentication changes now end with one edit, and both applications behave identically. The migration also removed leftover dead code and duplicate dependencies, leaving the JWT library under one owner.
Retrospective: For legacy work, follow existing conventions to reduce the change surface. Migrating in verifiable units is safer than replacing everything at once.

Achievement 02

Building a Notification Template & Recipient Management System

Background & Cause: Email notification templates were hardcoded as 54 per-language HTML files, each with its own request class and endpoint. Code grew with every notification type, and changing copy or recipients required a deployment.
Decision & Rationale: I moved templates from code to data so administrators could change copy and recipients without deployments. A four-axis model—channel, event type, service type, and language—makes a new notification a row addition. A separate recipient registry, a combined admin API, and one common send implementation avoid duplicated changes and round trips.
Outcome: Administrators can now manage templates and recipients dynamically without deployments. Later features reuse the existing send logic without new code. Recipient and delivery-history records were also included in personal-data encryption.
Retrospective: Repeated code of the same shape signals a missing data model. Moving identifying axes into data lets new requirements end as row additions rather than code changes.

Achievement 03

Encrypting Personal Data Without Breaking Search

Background & Cause: Raising the standard for personal-data protection required encrypting fields such as names and contact details. Encryption breaks the equality searches that use those values. Protection and searchability were in direct conflict.
Decision & Rationale: Rather than leave a plaintext search path while solving search later, I designed envelope encryption and blind indexes together. Key versions preserve a re-encryption path. Staged write, search, and backfill phases let the service read both plaintext and ciphertext during the live-data transition.
Outcome: Equality search remains available on encrypted values, applied in stages to live data. The backfill resumes from row state, making interruption and re-execution safe.
Retrospective: Security requirements can be applied to a running system only when their transition path preserves features. Every encryption-migration phase should be re-enterable.

Achievement 04

Automating Deployment Notifications and Sequential Deploys

Background & Cause: In an environment deploying multiple modules, deployment facts were not shared with the team and commit-level review gaps were possible. Build-server memory prevented parallel builds, so people waited for each build and manually started the next deployment.
Decision & Rationale: Teams was the primary notification channel, with email as a fallback so a channel failure would not silence automation. I separated AI review by merge request and push. Instead of increasing server memory, the pipeline detects completion and starts the next build and deployment automatically.
Outcome: Deployments and review results are shared automatically, and sequential deployments no longer require human waiting.
Retrospective: Notifications are trustworthy only when their failure fallback is designed too. Automation should target the waiting between tasks as well as the tasks themselves.

Achievement 05

Java 11 → 21 → 25 runtime modernization

Background & Cause: A new application had to be added for mobile-client authentication and per-site project file management. The existing Java 11 approach constrained what could be built, and leaving an old runtime in place was itself a long-term maintenance risk.
Decision & Rationale: Modernization started alongside that new application. Java 21 was merged first so new feature work and the runtime move ran in the same period. Java 25 followed, with a Spring Boot 4 BOM unifying version management. Jackson 3 migration, single ownership for the JWT library, and per-module build JDK changes were handled together. That kept dependencies from diverging across modules.
Outcome: What the upgrade broke was repaired alongside it. HTTPS detection inverted in SAML header handling, the entity-id scheme broke on non-standard ports, and staging returned 403 for origins. Client IPs lost behind a proxy were restored too, each case narrowed with diagnostic filters. The same effort moved the front-end build from CRA to Vite and raised the search client to 9.x, clearing stale dependencies on both sides. The move also let the later SAML standardization sit on a framework-supported path.
Retrospective: The real work in a runtime upgrade is not raising the version. It is finding and restoring the behavior that quietly broke because of environment differences.

Achievement 06

Standardizing SAML for Future SSO Expansion

Background & Cause: A new partner IdP integration was requested. The legacy SAML implementation made a flexible, extensible structure difficult to build within the framework. Spring Boot 4 in particular restricts the legacy IdP approach.
Decision & Rationale: I switched from the homegrown approach to the framework-supported standard so upgrades and extensions can follow the framework path. An SSO provider registry replaces per-provider branches, and a dedicated security chain isolates IdP rules. A generic SAML 2.0 mock SP verifies compliance without waiting for each partner environment.
Outcome: IdP-initiated auto-login now runs on a standard foundation. A generic SAML 2.0 mock SP test application makes each new provider integration repeatable.
Retrospective: Checking what the next framework version restricts and standardizing early lowers the cost of later expansion beyond the immediate request.

Achievement 07

Rule-Based Product Configurator (Drive Panel Selector)

Background & Cause: Customers had to make a technical inquiry every time they needed a drive and panel configuration matching their specifications. Sales needed a tool that continued from consultation into a quote request within the system.
Decision & Rationale: I used explicit rules instead of a learned model because product configuration has clear constraints between options. Results must also be explainable when they affect quotes and orders. Earlier choices dynamically narrow later ones. Final-step images, customer inputs, inquiry-history integration, and duplicate-request prevention extend the flow into quoting.
Outcome: Customers can narrow a configuration to match their specifications and reach the resulting model without a technical inquiry. From there they move directly to an inquiry or quote request.
Retrospective: Requirements that look like recommendation can be solved predictably with explicit dependencies between options. The tool is complete only when it connects to consultation and quoting, not just a result screen.

Visit

← Back to list