Fern Go live

[leite08]

On https://github.com/metriport/metriport-internal/issues/670 we defined how we want to implement SDK and doc generation - with Fern.

Let's use this ticket to map the upcoming work to get it in production.

GO LIVE Plan May 24 2024

We want to actually do this. But it will require:

• refactoring docs
• refactoring all code that uses api-sdk
• solidifying ci/cd processes
  Plan here is now the following:

1. Until we finish e2e testing, don't do fern releases. Just make comments / update the definition but lets not waste dev time on the whole release process
2. Once e2e testing is done, we can confidently refactor api-sdk

GO LIVE

• SDKs (below)
• Express Routes (below)
• Enable Slack notifications for SDKs' repos (new issues, PRs opened/merged, etc.)
• Make the SDK repos public
  • TS
  • Python
  • Java
• Release the final version of SDKs - 8.0.0
• Pin the SDK repos to our org's Github page?
• Communicate to customers
• Remove the old metriport/metriport-api repository (already moved to private)
• Docs
  • Revert making this PR a draft

SDKs:

• Review the fern definition for MAPI endpoints (Org was already reviewed)
  • Notes on 🌿 introduce Fern Definition + SDKs #1029
  • make sure we listPatients() allows listing w/o filtering by facility
• Add "settings" and WH functions/types to SDKs - 1634 WHs on E2E tests (1/4) #2189
• Align on release plan
  • Confirm versions to be release for each language: 8.0.0
  • Release an alpha version of each
  • Review READMEs
    • TS: Update README.md metriport-node#1 @jonahkaye
    • Python: Update README.md metriport-python#1
    • Java: feat(docs): Updating Java Sdk Docs metriport-java#2
• Adjust how the SDK will look like @ each repository (company name, description, links, sdk documentation, etc.) @leite08
  • TS
  • Python
  • Java
• Have the tester packages on OSS running and validating each SDK @jonahkaye
  • TS
  • Python
  • Java
• (Fern) Finish including FHIR types to the repository (as a dependency)
• dependent on kill DAPI: https://github.com/metriport/metriport-internal/issues/1411
• (Fern) Allow to dynamically define whether alpha or final version when releasing SDKs - see this PR and thread
• (Fern) Support package's description
• Config the Fern definition so we don't generate FHIR types on each fern generate - contex
  • it takes almost 2min to generate code w/ FHIR defs, so we have a few alternatives to not generate them all the time
• Review repo's config for the default branch @leite08
• Update docs (especially this and SDK snippets) @jonahkaye
  • Add a note indicating DAPI customers should rely on the SDK v7.x
• Document on Notion how to use Fern and release packages (no dash on alpha number, it breaks Python) @jonahkaye
• Add SDK tests to CICD - https://github.com/metriport/metriport-internal/issues/1782

Express Routes

• MAPI only for now
  • create a ticket to migrate DAPI as well
• (Fern) Additional validation through Zod - thread
• Release it under /v2? Use the opportunity to make improvements on the API contract?
  • Maybe related to multi-user account, in case it changes Auth? [Feat]: Dash - Support multi-user accounts #350
• Update the Fern definition and build the services
  • (Fern) Build a Service to serve as a reference for Metriport to build the rest
  • ... (long list of endpoints to map code from route to "Service")
• Can we improve our E2E tests so we have more comprehensive testing of the API before merging it?
• Validate it on staging
  • Full platform testing, this requires a thorough test plan and likely more than one person checking/validating its working as intended
  • ... (long list of endpoint testing)
• WIP - depending on whether we'll release this under /v2 or keep as /v1, finish building this release plan
• ...