Static and Serverless Hosting Runtime Adapters #1008
Description
Overview
Would like to provide Greenwood with the ability to adapt to specific runtimes / platforms for support Serverless and Edge runtimes like:
- Netlify Serverless / Edge Functions - https://github.com/ProjectEvergreen/greenwood-demo-adapter-netlify
- Vercel - https://github.com/thescientist13/greenwood-demo-adapter-vercel
- AWS Lambda (arc?)
- Deno Deploy
- Cloudflare
- others?
In particular, supporting #1007 , which will vary per hosting provider. The goal would be to support the following as Serverless and / or Edge functions:
- API Routes
- SSR Routes (would this need evaluate (remove) use of Workers for SSR and prerendering #1088 )
Details
Main thoughts include
- One off page routes (see SSR and Serverless experiments [DO NOT MERGE] #812)
- Being able to work without a filesystem - Agnostic Runtime #953
- SSR pages will need access to the request object, no?
- Do we need single file bundles (SFBs) for SSR page and API routes #1118 ?
- Consolidate and document build out; manifest.json, resources.json, etc as identified in Enhancement/issue 946 decouple build and serve commands from workspace #1079 including a serializable version of the graph and manifest for SSR (as identified in Enhancement/issue 946 decouple build and serve commands from workspace #1079)
better way to "DI" compilation into generated SSR pages instead of through- completed in evaluate (remove) use of Workers for SSR and prerendering #1088handlerin bundle lifecycle? (As identified in Enhancement/issue 946 decouple build and serve commands from workspace #1079)Should API and SSR pages have chunks, or be entirely self contained and also minified in rollup.config.js? (As identified in Enhancement/issue 946 decouple build and serve commands from workspace #1079 )- deferred to single file bundles (SFBs) for SSR page and API routes #1118- WCC Enhancements
- Maybe a guide self hosting for
greenwood serve? - Rehydrate graph in memory
In concert with #953