• ✅ Linting
• ✅ TypeScript
• ✅ Tailwind
• ✅ SCSS
• ✅ Embedded Google Fonts
• ✅ Lucide Icons
• ✅ ShadCn
• ✅ Modern scrollbars
• ✅ Markdown
  • ✅ Rendering
  • Processing frontmatter
• Content management
  • List of all articles
• Images
  • Optimization
  • Static optimization
• ✅ Drizzle
• ✅ tRPC
• ✅ Cloudflare
  • ✅ D1
  • 🚧 R2
  • ✅ Turnstile
  • ✅ Workers Analytics Engine
  • ✅ Caching
  • ✅ Geocodes
  • 🍭 Cache
  • 🍭 Fingerprint
  • 🍭 Cron
  • 🍭 Queue
• ✅ Emails
  • ✅ Email Rendering
  • ✅ AWS SES
• Crypto
• ✅ Deployment
  • ⚠️ No static calls getRequestContext
  • ⚠️ Check if process.env is ok

Specifically under Next 15 is not possible to use renderToReadableStream under any route, rendering impossible the creation of functionalities like rendering emails from React components. This may also be an issue during automated OG image creation. The related issues are:

• Next.js 15 renderToReadableStream
• Missing function H error
• React Email Issue
• Astro patching with react-dom/server -> react-tom/server.edge

This project has many moving parts and require careful configuration and attention not to expose secrets. Here is a complete part of all parts involved into a complete deployment.

Create a CloudFlare pages project

wrangler pages project create svara-test-next --production-branch main --compatibility-date 2025-01-15 --compatibility-flag nodejs_compat

For testing purposes build for Cloudflare pages (use Ubuntu)

npm run pages:build

Then run the application in a production environment (use your OS to prevent Sqlite C++ read errors)

npm run pages:preview

Application is backed by a CloudFlare D1 database with a Drizzle orm connection that enables the system to run a full Sqlite database on edge. Connection and schema configuration is done in lib/db.

Create a migration

drizzle-kit generate --name=...

Apply migrations to the local dev database

wrangler d1 migrations apply database --local

When your wrangler file contains the correct database_name and database_id you can use this command to migrate the stage/production environment.

wrangler d1 migrations apply svara-test-next --remote

The project support R2 Read & Write via Worker wit additional support to upload and download files via custom route.ts APIs, that will limit the possible MIME types and the file size to 1MB.

The system supports direct file upload via PUT request (like S3 API) without any conversion to form encoding. This is easier to validate on the backend and should be easier to extend in the future. Stream API does not support stream reading FormData and therefore it is not an efficient method to use prefer direct file uploads. The system fully supports streaming of upload requests when FormData is not used. Note that due to a bug in wrangler requests must be materialized when in development mode.

The fileDownload function supports caching, and can be enabled via cacheMaxAge and cachePublic which will expose a standard cache-control: max-age=N, public header to be then handled by any front proxy or CDN. It is also possible to enable different cache logics like cacheNoStore and cacheMustRevalidate.

Temporary uploads can be implemented by uploading all files to a fixed prefix key (like tmp/) and then moved to the final key after the user confirms the operation. To properly achieve so an Object Lifecycle Rule should be added to the R2 configuration to properly clean the files after they have been abandoned for some time.

To protect unauthenticated endpoints/actions from DDOS and abuse use Cloudflare Turnstile. To enable the system just create a Turnstile widget via the interface and provide:

• NEXT_PUBLIC_TURNSTILE_SITE_KEY secret to the GitHub action (embedded at build time)
• TURNSTILE_SECRET_KEY secret to Cloudflare Pages Functions

Emails are sent via a separate AWS SES client which should be authenticated providing the following environment variables to the CloudFlare pages function:

• AWS_REGION
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Emails are rendered from React templates using @react-email/components which imposes us to use Next 14. All email templates are created as React components and automatically rendered to HTML (and plain TXT) on edge via the send email function.

await sendMail(TemplateOtp, input.to, { /* ... data ... */})

This system supports Worker Analytics for system analysis and to display data to the user. Cloudflare provides write and read wia two separate systems, the first is a binding that should be configured via the dashboard (and wrangler) and the second is a public API that requires an API token.

For writing create a AYD binding to an Analytics Dataset and then use the aed?.writeDataPoint() function. THIS BINDING IS NOT AVAILABLE VIA THE LOCAL DEVELOPMENT ENVIRONMENT AND THE aed OBJECT MAY BE undefined. With this functionality both system and application metrics can be logged.

In case of application metrics the metrics should also be read by the Worker which is achieved directly via fetch using the public API. The following environment variables to the CloudFlare pages function:

• AED_ACCOUNT_ID CloudFlare account it
• AED_API_TOKEN a generic Token with Account Analytics Read permissions (yes CloudFlare has no granularity on this one)
• AED_DATASET not required, but used by this project to not hardcode the dataset

Data can be then read via their unofficial SQL language. Here are some query examples.

Collect all data from a dataset:

SELECT * FROM svara_test_next

Collect all data of the last day divided by action and aggregate it for each hour. The result is a sparse dataset that may have holes and should still be reorganized by action (see waeTranspose).

SELECT
    intDiv(toUInt32(timestamp), 3600) * 3600 AS t,
    blob1 AS a,
    SUM(double1) as c
FROM svara_test_next
WHERE toUInt32(timestamp) > toUInt32(NOW()) - 5184000
GROUP BY t, a

The analytics result is then converted from sparse matrix to a dense time-series matrix using waeTranspose and rendered to the user via ShadCN Charts. This process supports up to 90 days in the past as this is the retention limit imposed by CloudFlare.

It is important to note that by default Cloudflare does only cache some file extensions and does so by actual extension and not MIME type. This implies that the application despite serving cacheable MIME types and/or correctly formed cache-control headers, unless the URL ends with an explicit extension like .jpg the cache will always be skipped (inspect the cf-cache-status header).

To properly setup caching explicit Caching Rules should be set up in Cloudflare. Such rules explains to Cloudflare how to behave under various caching conditions. For this setup the following rules have been created, to support the desired application behaviour:

• test_next_cdn_cache: This rule cache all requests served by cdnext.svara.io for 2 hours as this is not done by default. As an additional improvement the query keys are ignored (they are not used by R2) preventing cache punching attacks and de existence of many copies of the same asset.
• test_next_files_cache: This rule marks as eligible for caching all the next.svara.io/files/* endpoints by respecting the provided cache-control header or using the default 4 hours caching period if the header is absent. Note that Browser TTL should be set to Respect original TTL to forward through the server issued cache-control otherwise Cloudflare will override it to the default 2 hours

CloudFlare provides the cf property inside Workers which include various useful properties.

This feature has been integrated in Next.js on Pages in this commit rendering some properties available in the request.geo property of Next. The final mapping is available here The lookup is:

The geo, cf and ip parameters have been rendered available to all tRPC requests via the default context.