Release Pre-cms and remix separation · mplibunao/payload-custom-website

Full Changelog: v0.4.0...v0.5.0

Release before separating payload and remix

Will stay in express and this repo
~~Will be multi-tenant so we only have to keep one payload instance warm instead of multiple instances~~
- I mean we can technically deploy one instance of payload per project and would make sharing the types easier and makes easier to move client data since each client is a separate database even if they are in the same cluster
- However, successfully implementing multi-tenant cms will make devops much easier as we don't have to deploy a cms and imagor instance for every client as well as create a new database inside the cluster. As long as the client fits in the cms, then we only have to deploy the remix app
- This makes metering more difficult especially around images but we can evently implement something like open-meter or just increase prices
Update 1: Not making payload multi-tenant anymore as versioning apis is non-existant with payload. We can create custom endpoints and generate openapi spec using that but the rest API uses a lot of params like where, depth, locale as well as needing to take things like cookieAuth and response schemas into consideration.
- At that point, we may as well create our own API which is a lot more work than running terraform apply

~~For the types, we use https://github.com/teunmooij/payload-tools/tree/main/packages/swagger to expose swagger endpoints that our different remix apps can use to generate the open API~~
For versioning we can create separate custom endpoints per version. But we'd have to attach the response schema manually like https://github.com/teunmooij/payload-tools/blob/main/packages/openapi/test/integration/custom-endpoints.config.ts#L21 since using the payload collection will result in types with versioning to not work correctly

~~We can use redis upstash to be able to keep using the in-memory cache in payload~~
But using cloudflare kv would probably be better fit with cloudflare workers since it has more regions than upstash. Costs are lower than upstash as well
For invalidating the cache, the most scalable way I can think of is storing a callback URL of the remix app in the cms. Somewhere like the site collection/globals. Even if we have to make a separate query for that, it's probably okay. Then we make a post request to the URL with collection and cache key and let cloudflare invalidate the cache itself similar to isr. The nice thing about this is this doesn't restrict caching to our own cloudflare account. We can deploy other remix apps including their kv cache in their cloudflare accounts and still be able to invalidate.
Instead of adding a field for the callback URL, let's just use cloudflare kv in payload since we're coupling them anyway

Moving remix to honojs running on cloudflare would allow us to avoid the need for warming since there are no cold starts
Also running on edge is a nice side-effect for the sites we're building. It's like an extra selling point
Since each client will have a separate remix app, we can move the remix app outside of the monorepo. This is a big change and honestly unideal but makes sense since we don't want to have all the remix apps inside a monorepo
We can also use esm now since payload is separate from remix which can result in better tree-shaking
Also since we will remove payload from remix, our bundle size and packages running on client is also reduced. If we need to add backend stuff, we can just create an API on the multi-tenant cms to keep cold-starts on remix low
Finally, the issue that initially prompted this whole mess. We can finally use early-hints to preload more stuff
Also hono in general is very light weight especially compared to fastify and express. So in a BFF client and API server architecture, it really makes more sense to use cloudflare and hono for the bff and keep it as light and distributed as possible