Software Engineer/Developer: Manuel Solalinde (manolosolalinde@gmail.com)
\nEvery month, reservoir and production engineers must set the monthly gas-production target for every well. Doing this well-by-well was a slow, manual grind; this full-stack web application lets an engineer process the entire well set in a single analysis, turning that process into about an hour of compute. It combines an interpolation/trend tool purpose-built for this task with guided manual review of the edge cases, then exports the finalized targets as the operator CSV consumed downstream. *(This page documents the v2.1.0 architecture — a React frontend with a FastAPI backend on AWS App Runner — since superseded by a unified Streamlit redesign on ECS Fargate.)* The heavy lifting — reading raw production history from the corporate data warehouse and fitting a trend per well — runs as a parallel, queue-driven Lambda fan-out, so the full well set is processed in one pass instead of one well at a time.
\nEach month an engineer creates an analysis (defined by its start/end date) and walks it through a four-stage workflow in the app. The application loads the analysis data from the corporate Amazon Redshift warehouse into a private working database, generates a production trend for every well in parallel, then surfaces two case-study reviews so the engineer can spot wells that need manual overrides before the final targets are exported.
\nThe user flow is organized as a set of sequential tabs:
\nThe system is a containerized, cloud-native stack provisioned entirely as code with Pulumi:
\nThe asynchronous operations follow a consistent pattern: the frontend calls a backend endpoint to kick off the work, then polls a state endpoint until the work reports finished. The backend enqueues one SQS message per unit of work (per table for the DB update, per well for trend generation); each message triggers an independent Lambda invocation, and a per-well job-status table tracks each well so the state endpoint knows when the whole batch is complete.
docker compose stack runs the frontend, backend, database, and Lambda together on a developer machine. Because the local environment can't reach Redshift or SQS, the warehouse reads are mocked and the backend invokes the Lambda directly instead of going through the queue — reproducing the production data flow without the cloud dependencies.\n","frontmatter":{"title":"Gas Targets App (React/FastAPI)","image_url":"./images/covers/gas_targets.png","description":"Web application that generates and sets monthly gas-production targets for every well.","technologies":"Python, JavaScript, React, Redux, FastAPI, SQLAlchemy, PostgreSQL, Amazon Redshift, AWS (App Runner, Lambda, SQS, RDS, VPC, ECR, IAM, Elastic IP), Pulumi, Docker, Docker Compose, GitHub Actions, Azure AD, Pandas, Plotly.js, MkDocs.","date":"2026-02-01T00:00:00.000Z"}},"user":"manolosolalinde","repository":"cv"}]},"site":{"siteMetadata":{"title":"Manuel Solalinde's Portfolio","description":"Manuel Solalinde's Portfolio and Featured Projects","author":"Manuel Solalinde"}}},"pageContext":{"uid":"bkv_gas_targets.md","rootQuery":"\n query mdProjectQuery($uid: String) {\n allGithubFile(filter: {base: {eq: $uid}, relativeDirectory: {eq: \"projects\"}}) {\n nodes {\n base\n relativeDirectory\n childMarkdownRemark {\n id\n html\n frontmatter {\n title\n image_url\n description\n technologies\n date\n }\n }\n user\n repository\n }\n }\n site {\n siteMetadata {\n title\n description\n author\n }\n }\n }\n"}},"staticQueryHashes":["3649515864"]}Note: Screenshots and architecture diagrams are omitted, as they display proprietary client data and systems. Available on request, subject to client approval.
\n