search

stefanhk31 / personal_blog_flutter

https://stefanhodgeskluck.com
2 stars 0 forks source link

Dart Frog Backend #38

Closed stefanhk31 closed 8 months ago

stefanhk31 commented 9 months ago

Move aws_client and butter_cms_client to dependencies of blog_data_source.

DF endpoints will fetch blogs from data source, which grabs the butter key on init

Advantages:

Simplicity: FE only cares about one endpoint, BE does all the work to get data Security: key is never given to FE in any form

Disadvantages: ...extra middle man? Extra deployment

stefanhk31 commented 9 months ago

...what if we put EVERYTHING backend into AWS?

  1. Flutter app calls DF backend w/auth token
  2. Backend calls AWS API Gateway blogs endpoint, passing the token for the authorizer
  3. If authorized, APIG triggers lambda to fetch secret value AND use that value to grab blog(s) from butter endpoints
  4. Sends blogs back to DF backend, which passes them to app

Butter would have NO interaction w/Dart, and the API Key would never leave AWS Backend is simply a data source that is hooked up to AWS

stefanhk31 commented 9 months ago

If we do it this way, do we need the anonymous auth token? It might help, but maybe we could just make the DF a Cognito user and restrict API access to that backend

stefanhk31 commented 8 months ago

Proposed file structure: App (current FE) API (Dart Frog) Packages

Butter Client Blog Repo (uses DF not Butter) AWS Client(s)

stefanhk31 commented 8 months ago

Or, nesting: 0 (Root): app

  1. API: dart frog w blogs data source
  2. lambda: aws

To start, butter Client will be in DF as a direct dependency of data source, but data source will eventually call AWS client which will interface w butter in lambda

App (or DF?) will need a dedicated blog_api_client for communication bt app and DF

stefanhk31 commented 8 months ago

In-progress work underway. Next big things:

stefanhk31 commented 8 months ago

Some changes: