-
- Private work.
- Remember (cassandra java) (scylla cpp). Both nosql.
- Anthony Jeselnik at Carnegie Hall.
- OpenAI seeking data partnerships: https://openai.com/blog/data-partnerships
- NY map: https://www.nytimes.com/interactive/2023/upshot/extremely-detailed-nyc-neighborhood-map.html
- The longspine urchin ate the molt of the sally lightfoot crab!
- I get so many spam calls nowadays.
- Ordered fresh. Turkeys were anywhere from $2-5/lb at morton williams. $1/lb for butterball on fresh / whole foods.
- Next.js useful reminders. Most are obvious.
- SSR is still valuable if your app is purely a client that hits other servers/APIs you don’t own. SSR runs wherever next.js runs; in my case, the amplify hosted env. That’s where we get the SEO/Perf/Fetching benefits. Not the data server / API server.
- You can host html/css/js in s3. The client browser knows how to render it. You can also return it directly from the api server. Next is much smarter – the client browser requests, the app hosting env is running next/node and can do a bunch of serverside actions. Fetching. Caching. Rendering. Whatever. This speeds up the client.
- App router (new) vs page router (old). It’s filesystem based. You can also have dynamicism (eg `=
[routeFolder]).
- By default everything from
fetch() (server-side only) is stored in a data cache (in amplify, vercel, wherever it’s hosted). If you want to fetch from the client, use Route Handler (or third party libs like swr https://swr.vercel.app/). Try to lean toward doing datafetching serverside though. Then you can store db connections, api tokens, etc, there and not expose to the client. Also, serverside means you can cache responses across users, which you cannot do clientside (single user).
- “Deploying” is pushing the app to that serverside env (not api server, not client). It’s running next and node.
- Remember the browser immediately shows your html (non-interactively) on initial page load, then hydrates everything with js instructions.
- Serverside rendering can occur in a few places. Static rendering is at build time (for pages like docs, feedback forms, etc). Dynamic rendering is at request time (eg for user-specific views). Next will automatically choose the best rendering method for your pages (based on the functions used). There’s also Streaming rendering, which is basically just where the data is chunked.
- Clientside rendering is best for interactivity. You can
useState(), useEffect(), event listeners. I probably don’t need any client components for sbsc. Maybe for something like statistics, where it fetches everything at once then the client chooses the dropdown filters. I might need a client component for the matchups view too, where onClick() is needed for picks.
- Supercontest.
- Looks like most of the amplify cost is in the build time (for my relatively low request service). In steady state, I’ll just have builds on master and staging (not feature branches? or just on pull requests).
- More tinkering in amplify studio.
