ReVuelo
Flight booking on ASP.NET, N-Tier architecture
| Role | Frontend developer — backend integration, Google login, Stripe payments, and Google Maps |
|---|---|
| Period | May 2026 – Jun 2026 |
| Stack | ASP.NET Framework, SQL Server, Stripe, Google Maps API |
| Repo | https://github.com/AdrianRCV/Web-Agencia-Viajes |
Team project, not deployed publicly — the booking, payment, and map flows were demoed locally with test credentials.
Context
ReVuelo is a flight booking platform — search flights, pick one, pay for it — built as a team project on ASP.NET Framework with an N-Tier architecture. My part was everything the traveler actually interacts with: the frontend, wiring it to the backend, and three integrations that don't come for free — Google login, Stripe payments, and Google Maps for picking airports and destinations.
Role & scope
Frontend developer, May 2026 – Jun 2026, on a team project. Built the presentation layer, integrated it with the existing backend/data layers, and implemented Google OAuth login, Stripe checkout, and Google Maps-based airport/destination selection.
Architecture
Classic N-Tier: a presentation layer (the pages and controllers I worked on) talks to a business logic layer, which talks to a data access layer backed by SQL Server — each layer only allowed to call the one below it, never skip ahead. Google OAuth handles login without ReVuelo storing passwords itself. Stripe Elements renders the actual card fields, so card data never touches ReVuelo's own servers. Google Maps' Places API backs the destination/airport picker so users search by typing a city or airport name instead of picking from a long dropdown.
| Layer | Choice |
|---|---|
| Presentation / Business / Data | ASP.NET Framework, N-Tier |
| Database | SQL Server |
| Auth | Google OAuth |
| Payments | Stripe Elements |
| Location search | Google Maps Places API |
Key decisions
Hard problem
Keeping the booking flow consistent while three different third-party SDKs — Google Identity, Stripe Elements, and Google Maps — each loaded and initialized on their own schedule was the trickiest part of the frontend work. A user could, for example, start picking a destination on the map, get interrupted by the Google login prompt, and come back to a payment step that needed to remember exactly where they'd left off. Coordinating that state across an app that wasn't originally built with a single-page-app style state manager in mind took more care than any individual integration did on its own.
Results
Shipped as a team project with a working end-to-end booking flow — search, select, pay — covering login, payment, and location search through three real third-party integrations rather than mocked versions of them.