GDS Platform

Overview

GDS Platform is a private B2B travel integration platform designed to give clients a single API for working with multiple travel providers.

The idea and the initial technical direction came from me. I designed and built the platform from the ground up, including the architecture, frontend, backend services, provider integrations, authentication flow, data model, and API design.

The platform was developed as an Nx monorepo, with a React and Vite frontend and a NestJS-based microservices backend.

I built the application independently from A to Z. The DevOps team handled the initial AWS deployment, while I worked closely with them on the deployment setup and retained access to the AWS environment for application operations, including updating environment variables and secrets and checking application logs through CloudWatch.

The Problem

Travel providers expose different APIs, authentication mechanisms, request structures, and response formats.

A client integrating directly with several providers would have to manage each provider separately and adapt its application to every provider's API.

The goal of GDS Platform was to provide a single integration layer that hides these differences.

Instead of building separate integrations for each provider, clients can communicate with one unified API and let the platform handle provider-specific authentication, request mapping, and response mapping.

Platform Architecture

The entire application was developed inside an Nx monorepo.

The frontend is built with React and Vite.

The backend follows a microservices architecture built with NestJS.

The backend is composed of:

• API Gateway
• Authentication Microservice
• Flights Microservice
• Hotels Microservice

Redis is used for caching and inter-service communication, while MongoDB is used for persistent data storage.

Only the API Gateway is publicly reachable by clients. The internal microservices remain behind the gateway.

Client Onboarding

The platform was initially developed as a private beta, so client accounts are created through the administration process.

Once a client receives an account, they can log in to the platform and configure the services they need.

The client can configure:

• Required travel services
• Travel providers
• Provider credentials
• Allowed origins

Supported provider integrations include providers such as Amadeus, TBO, and Travelport.

Provider credentials are encrypted before being stored in the database.

API Key Authentication

After configuring their account, the client can generate a unique API key.

The client then uses this API key when communicating with the public Gateway API.

The client does not need to send the credentials of each travel provider with every request.

Instead, the authentication microservice handles the client authentication and retrieves the required provider configuration from the platform.

This keeps provider credentials isolated from the client's application and removes the need for clients to implement provider-specific authentication themselves.

Allowed Origins

Clients can configure the origins that are allowed to access their API.

The platform validates requests against the configured origins before allowing access to the API.

This provides an additional layer of control over where a client's API key can be used.

Unified API

One of the main goals of the platform was to hide the differences between travel providers.

Different GDS providers can require different request structures and response formats for the same operation.

Instead of exposing those differences to the client, the platform uses a unified DTO structure for each supported action.

For example, a client can send the same type of request regardless of whether the underlying provider is Travelport, TBO, or another supported provider.

The provider-specific differences are handled internally by mapper logic inside the relevant microservice.

Request Mapping

Each microservice contains provider-specific mapping logic.

The client sends a unified request structure, while the platform transforms that request into the format required by the selected provider.

The provider is selected through the request path.

This keeps provider-specific implementation details inside the platform instead of forcing clients to maintain separate integrations.

Response Mapping

The same approach is used for provider responses.

Provider-specific responses are transformed into a unified response structure before being returned to the client.

As a result, clients can work with a consistent API even when the underlying providers return different data structures.

This makes it easier to add or replace providers without requiring clients to redesign their integrations.

Query Features

The API also supports common query capabilities through query parameters, including:

• Pagination
• Sorting

These capabilities are handled consistently across the supported API endpoints.

MCP

The platform also provides an MCP interface, allowing its travel capabilities to be consumed by MCP-compatible clients and automation workflows.

This extends the platform beyond traditional REST API integrations and provides another way to interact with the travel services exposed by the platform.

My Role

Founder of the Idea & Full-Stack Developer

I was responsible for the platform from the initial idea through development and integration.

The main idea and technical direction were mine, and I designed and implemented the platform architecture from scratch.

My work covered:

• Defining the platform architecture
• Designing the Nx monorepo structure
• Designing the microservices architecture
• Building the React/Vite frontend
• Building the NestJS backend
• Developing the API Gateway
• Developing the Authentication Microservice
• Developing the Flights Microservice
• Developing the Hotels Microservice
• Designing the client authentication flow
• Implementing API key generation and validation
• Implementing allowed-origin configuration
• Implementing encrypted provider credential storage
• Integrating travel providers
• Designing unified DTOs
• Implementing provider request mappers
• Implementing provider response mappers
• Building pagination and sorting capabilities
• Implementing the MCP interface
• Working with the DevOps team on AWS deployment
• Managing environment variables and secrets in the deployed environment
• Monitoring application logs through AWS CloudWatch

The application was built by me from A to Z, with the DevOps team responsible for the deployment infrastructure and AWS setup.

Technology