[arc.codes] Documentation Outline

[macdonst]

Notes:

• New document structure:
  • Top-level docs
  • Category
  • Category-level docs
  • Group
    • Group-level docs
    • Hidden group-level docs (see: Setting up a domain sub-docs)
• about/mission doc to be subsumed by The Architect Way

---

• [ ] Home (not in the nav)
  • [ ] > Welcome
  • [ ] > Installation

  • [ ] > Get started

    Side Navigation

• [x] Introduction

• [ ] The Architect Way
  • [ ] > Excellent developer experience
  • [ ] > Cloud function-centric development
  • [ ] > Local, offline development // note: possible to work online with real infra
  • [ ] > Code sharing across functions
  • [ ] > Automated dependency management
  • [ ] > Discrete environments
  • [ ] > Declarative deployment
  • [ ] > Runtime resource discovery
  • [ ] > Optional helpers
  • [ ] > Secured to least privilege by default
  • [ ] > Incremental enhancement? development?
  • [ ] > Open source and open governance
  • [ ] > ¿Comparison to other frameworks?

    Get started

• [ ] Quickstart // link to AWS tutorial
• [ ] Project manifest format
  • [ ] > Overview
  • [ ] > Architect format
  • [ ] > JSON
  • [ ] > YAML
  • [ ] > TOML
• [ ] Project files & folders
  • [ ] > Overview
  • [ ] > Creating new resources & files
  • [ ] > Special files & folders
  • [ ] > Custom paths

App development // alt name: App development guides

• [ ] Developing with cloud functions
  • [ ] > Overview
  • [ ] > Principles & key concepts
  • [ ] > Using cloud function middleware // how & why
• [ ] Function dependencies
  • [ ] > Overview
  • [ ] > Updating dependencies
  • [ ] > Hydrating dependencies
  • [ ] > Dependency management
• [ ] Code sharing across functions
  • [ ] > Principles
  • [ ] > Shared
  • [ ] > Views
• [ ] Building HTTP & WebSocket routes
  • [ ] > Overview
  • [ ] > HTTP routes
  • [ ] > WebSocket routes // should probably include / have a section for connecting to WS
• [ ] Using HTTP & WebSocket sessions
  • [ ] > Overview
  • [ ] > HTTP sessions
  • [ ] > WebSocket sessions
• [ ] Building async events & queues // aka background tasks
• [ ] Building scheduled tasks // cron should be in the metadata
• [ ] Managing environment variables
  • [ ] > Overview
  • [ ] > Architect environments // testing, staging, production
  • [ ] > Local environment variables // prefs.arc + .env; when they are synced vs. not synced
• [ ] Using static assets
  • from #427 ${STATIC('file.png')} and ${arc.static('file.png')}
• [ ] Working locally / offline
  • [ ] > Overview
  • [ ] > Initializing new functions // arc init, preferences
  • [ ] > Environment variables // prefs.arc + .env
  • [ ] > Previewing // localhost:3333
  • [ ] > Testing HTTP routes & endpoints
  • [ ] > Testing events & queues // future: add queues, scheduled
  • [ ] > Testing database tables & indexes
• [ ] Debugging your app

• [ ] Logging & monitoring your app

  Tutorials

• [ ] Going beyond "Hello World"
  • [ ] > Static assets + CNDs
  • [ ] > Database tables
  • [ ] > Environment variables
  • [ ] > CI/CD
  • [ ] > Event functions
  • [ ] > Scheduled Functions
  • [ ] > Queue functions
  • [ ] > Macros
• [x] Setting up a domain
  • [x] > Overview
  • [x] Route53
  • [x] Route53 & CloudFront
  • [x] Dreamhost
  • [x] Godaddy
  • [x] One
  • [x] Namecheap
• [ ] Configuring AWS
  • [x] > Get AWS IAM credentials
  • [ ] > Minimum viable permissions
  • [x] > Configure AWS CLI
  • [x] > Working with multiple profiles
  • [x] > Credentials file vs. environment variables
  • [ ] > Deploy buckets
  • [x] > Default runtime
• [ ] Using Architect plugins // metadata: macros!
  • [ ] > Overview
  • [ ] > Installation
  • [ ] > Plugin API
  • [ ] > Helper methods
  • [ ] > Examples
  • [soon!] [ ] Modeling & persisting data
  • [soon!] [ ] Building single page apps (SPAs); include aliasing

  • [soon!] [ ] Implementing CORS

    Reference

    Project manifest

• [x] @app
• [x] @aws
• [x] @events
• [x] @http
• [x] @indexes
• [x] @plugins
• [x] @proxy
• [x] @queues
• [x] @scheduled
• [x] @shared
• [x] @static
• [x] @tables
• [x] @views
• [x] @ws

  Configuration

• [x] Function config
  • [x] > runtime
  • [x] > memory
  • [x] > timeout
  • [x] > concurrency
  • [x] > layers
  • [x] > policies
  • [x] > architecture
• [x] Local preferences
  • [x] > @create
  • [x] > @env
  • [x] > @sandbox
  • [x] > @sandbox-startup

    CLI

• [x] deploy
• [x] destroy
• [x] env
• [x] hydrate
• [x] init
• [x] logs
• [x] sandbox

  Runtime helpers

• [x] Node.js (@architect/functions) // I can see this doc being broken up into a series of arc fns docs a level deeper, wdyt?
  • [x] > Set up @architect/functions
  • [x] > arc.events
  • [x] > arc.http
  • [x] > arc.http.async
  • [x] > arc.http.express
  • [x] > arc.http.session
  • [x] > arc.queues
  • [x] > arc.services
  • [x] > arc.static
  • [x] > arc.tables
  • [x] > arc.ws
  • [x] > Set up @architect/asap
  • [x] > API
  • [x] > Examples
• [x] Deno
• [x] Python

• [x] Ruby

• [ ] Upgrade guide
• [ ] App limits // should this be automated?

• [ ] FAQ

  About

• [x] Mission
• [ ] Community & governance
• [ ] Contributor guide
• [x] Playground

[tbeseda]

Do we have any plans for redirects for the large swath of URLs we are about to change? I'm all about the better naming and organization, but it might cause 404s from places we don't control.

We already have a redirect map with ~60 paths that we could expand. Or maybe we could make a "smarter" system that looks for a similar doc name? Or maybe there's a way to pass a search term to the search widget on the front end? At the least we need a real view for 404s.

[tbeseda]

We already have a redirect map with ~60 paths that we could expand.

For sure going to add to the existing map for known deprecated paths. Also going to add some 404 to catchalls that don't resolve to a doc. Could be a cool place for an embedded search.