In this app I want to try a bunch of new things:
- Vercel for frontend hosting
- v0 for AI-supported UI design
- Automated releases with github actions
- Appsync javascript resolvers
- Appsync subscriptions for real-time updates everywhere
- Playwright frontend tests
- HTMX instead of react & appsync -> astro-party
- Even though I can get nice types, the whole thing should be much easier
- Isnt there a service out there which I can just give my graphql schema and it will provision the api? the cdk setup including CI/CD seems kind of big for a relatively simple thing
- Trying a bunch of new technologies while trying to be fast at the same time is contradictory. For speed it might be better to use a known tool to reduce complexity instead of getting familiar with many new things
Vercel provides CI/CD jobs out of the box. Played around with overriding the jobs (https://vercel.com/guides/how-can-i-use-github-actions-with-vercel) before finding out these jobs can be customized in the vercel project settings (not a file in this repo).
E2E tests.
Easily record tests (docs):
npx playwright codegen --viewport-size=800,600 http://localhost:3000
Because I am using localstorage to store the username, nextjs goes crazy: https://nextjs.org/docs/messages/react-hydration-error
Should I use more SSR for my app?
- Would be nice to have an auto-increment id for the participants
- Is it annoying that the participants have the partyId as the PK? Maybe in some hypothetical support cases, but there could be work-arounds for these
- To use it with apollo a certain package is needed
- This package has a pending issue for which there is a patch
- Could also be solved by delaying the init
- This package has a missing dependency on "uuid", which is why I added it as a frontend project dependency: hint
- This package has a pending issue for which there is a patch
Might be cool to have the IDs include their keytype (i.e. party#123123 instead of just 123123) like prescribed here. Will have to be hidden in the URL though because this id would be kind of ugly to have in the url.
Should this app be a single page application? Probably yes, but it doesnt seem straightforward with Next.js (blog). Sharing data between states could make it so I fetch all party data once, and then only rely on subscriptions for subsequent data updates. A potentially bigger bundle sice with the SPA is counterweighed by optimal network requests for the application data.