{"id":50467485,"url":"https://github.com/podaac/swodlr-api","last_synced_at":"2026-06-01T08:02:48.267Z","repository":{"id":77917190,"uuid":"604854142","full_name":"podaac/swodlr-api","owner":"podaac","description":"API for accessing swodlr (swaa·dler) system","archived":false,"fork":false,"pushed_at":"2026-04-12T21:14:05.000Z","size":844,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":5,"default_branch":"develop","last_synced_at":"2026-04-12T22:25:51.870Z","etag":null,"topics":["development","swodlr","tva"],"latest_commit_sha":null,"homepage":"","language":"Java","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/podaac.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2023-02-21T23:35:55.000Z","updated_at":"2026-04-12T21:14:08.000Z","dependencies_parsed_at":"2023-10-11T00:28:30.451Z","dependency_job_id":"6b9f59d9-3272-4306-8fae-178ebaf02d6f","html_url":"https://github.com/podaac/swodlr-api","commit_stats":null,"previous_names":[],"tags_count":67,"template":false,"template_full_name":null,"purl":"pkg:github/podaac/swodlr-api","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/podaac%2Fswodlr-api","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/podaac%2Fswodlr-api/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/podaac%2Fswodlr-api/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/podaac%2Fswodlr-api/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/podaac","download_url":"https://codeload.github.com/podaac/swodlr-api/tar.gz/refs/heads/develop","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/podaac%2Fswodlr-api/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":33765379,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-01T02:00:06.963Z","response_time":115,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["development","swodlr","tva"],"created_at":"2026-06-01T08:02:44.079Z","updated_at":"2026-06-01T08:02:48.251Z","avatar_url":"https://github.com/podaac.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"# swodlr-api\nA GraphQL API for SWODLR\n\nSWODLR has been developed from the ground up as a GraphQL-first service giving\ndevelopers a more flexible way to interact with the system. This API is intended\nfor both direct frontend and backend consumption\n\n## Authentication\n\nSWODLR-API utilizes bearer tokens from\n[Earthdata Login](https://urs.earthdata.nasa.gov/) as its primary authentication\nmechanism. Once a bearer token is generated, simply include the bearer token as\npart of a request's `Authorization` header.\n\n```\nAuthorization: Bearer eyJ0e...\n```\n\nSWODLR-API currently does not provide support for username/passwords being\nused in Basic authentication as some other Earthdata APIs may allow.\n\n### Frontend Integration\n\nSWODLR-API does not provide any mechanism to perform direct authentication via\na user's credentials (username/password); this is by design. SWODLR-API takes a\n\"client-first\" approach to authentication leaving it up to our integrators to\nprovide authentication to their users as they see fit against Earthdata Login.\nFor example, on\n[SWODLR-UI](https://github.com/podaac/swodlr-ui), we perform authentication\npurely via the frontend with OAuth2 Primary Key Code Exchange which allows for\nsecure authentication to Earthdata Login without needing to publish our client\nsecret publicly and securing the authentication between the client and Earthdata\nLogin.\n\nUnfortunately, Earthdata Login does not currently provide support for OAuth2's\nPKCE extension. Instead SWODLR provides a OAuth2 PKCE wrapper which enables this\nauthentication flow by wrapping around the existing Earthdata Login OAuth2\nendpoints. These PKCE-enabled endpoints are compliant with RFC 7636 and are\navailable at:\n\n```\n/api/edl/oauth/authorize\n/api/edl/oauth/token\n```\n\nThese endpoints are provided as a courtesy to frontend integrators while\nEarthdata Login works on providing proper support for PKCE.\n\n## Design\n\nSWODLR-API does not directly provide raster generation/job tracking on its own.\nInstead SWODLR-API acts as a caller to\n[swodlr-raster-create](https://github.com/podaac/swodlr-raster-create) which\nperforms these actions asynchronously. SWODLR-API instead acts as the\nauthentication and caching layers for the rest of the SWODLR system as it is the\nonly publicly accessible portion of the system. All other microservices are not\ndirectly user invocable or publicly accessible.\n\n### Security\n\nOnce a user's request leaves SWODLR-API, SWODLR's microservices assume that\nrequests have been fully authenticated and are not required to perform further\nauthentication checks. Therefore it is important that SWODLR performs proper\nauthentication/authorization checks before any request leaves its scope.\n\nSWODLR-API utilizes Earthdata Login as its primary authentication provider. As\nnoted above, SWODLR-API's authentication is handled by Earthdata Login bearer\ntokens. These tokens are encoded as\n[JSON Web Tokens](https://datatracker.ietf.org/doc/html/rfc7519) which allow\nus as an API provider to verify these tokens without requiring a call to\nEarthdata Login by verifying the cryptographic signature in the token against\nthe public key of Earthdata Login.\n\nAdditionally, SWODLR-API also provides functionality which is specifically gated\nbehind Earthdata Login user roles. These roles are only assignable by\napplication administrators as part of Earthdata Login's OAuth2 implementation.\nSWODLR-API retrieves a user's roles in the course of its request-response flow\nand authorizes certain endpoints based on those roles.\n\n### Generation Workflow\n\nSWODLR-API is ***NOT*** a job management system and it does ***NOT*** provide\nusers with direct access to the underlying Science Data System (SDS). Instead\nSWODLR-API is designed around the idea that a customized product generated for\none user is the same product that would be generated for another user.\n\nAs such, when a user requests a product for generation, SWODLR-API will first\nevaluate if such a product has already been generated in the past. If it has,\nthen that existing product will be returned and the SDS will not be invoked for\na new product generation. It is only if the product has not been generated in\nthe past that the SDS will be invoked to generate a new product. This approach\nhas obvious cost savings benefits for products that will be generated repeatedly\nby multiple users. \n\nOnce a request is submitted to SWODLR-API and the API's internal cache does not\ncontain an existing product, SWODLR-API invokes the swodlr-raster-create Step\nFunction by sending a message to its SNS topic. SWODLR-API will then mark that\nproduct as `NEW` in its database. This is where SWODLR-API ends its interaction\nwith this request directly and where the rest of SWODLR's microservices take\nover.\n\nSWODLR was designed to be highly-scalable and asynchronous from day one. Each\nmicroservice of SWODLR is designed to perform a specific task and report back\nits results throughout execution. For example, `swodlr-raster-create` will\nprovide updates back to `swodlr-api` for the user to monitor a product's\ngeneration process. It performs this update by interfacing with another\nmicroservice, `swodlr-async-update`, which contains the logic to update\n`swodlr-api`'s database to reflect any new status changes to products.\n\nSWODLR-API does not directly perform monitoring during a microservice's\nexecution and leaves it up to the microservices to perform the reporting back to\nthe database as they execute. This approach has several advantages, but the main\nbeing that SWODLR-API doesn't need to scale according to the number of products\nthat are being generated. Instead SWODLR-API is dedicated to just servicing API\nrequests and only needs to be scaled as such to handle the demand of API\nrequests.\n\nServices such as `swodlr-raster-create` and `swodlr-async-update` are built on\ntop of AWS serverless technologies such as Step Functions and Lambdas, and can\nautomatically scale SWODLR during periods of high demand without any issue.\n\nAs mentioned before, SWODLR-API is ***NOT*** a job management system. Instead\nSWODLR leans on existing SDS systems such as HySDS for these features.\nSWODLR-API also does ***NOT*** interface directly with these SDS's directly;\ninstead performing SDS actions via its microservices. This design has the\nadvantage of narrowing scope for each of SWODLR's components and creating\nsecurity boundaries for the information that is passed between SWODLR's\ncomponents.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpodaac%2Fswodlr-api","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fpodaac%2Fswodlr-api","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpodaac%2Fswodlr-api/lists"}