workers-types VS relay-starter-kit

Not yet. The current in-worker api is described at https://github.com/cloudflare/workers-types/blob/master/inde...

This recently bit me. No automated testing, so it broke production code.

You can brag about your automation, when it is well tested.

https://github.com/cloudflare/workers-types/issues/116

There’s an issue open at https://github.com/cloudflare/workers-types/issues/84 for this, as well as an example you could grab temporarily.

https://github.com/kriasoft/react-starter-kit (or, relay-starter-kit)

GitHub

It also helps to have a REPL shell for Knex.js — https://i.imgur.com/P5bVdoC.gif

I generate TypeScript enums and types from the actual database schema using knex-types as part of the yarn db:reset script that used during local development (after making changes to the db schema migration files). See example project.

I tried to take advantage of TypeORM in a couple of projects, but then reverted back to knex + knex-types — just a PostgreSQL client with query builder works great, IMO, especially for GraphQL API development.

GraphQL API and Relay Starter Kit— an example of implementing GraphQL API optimized for the serverless environment (Google Cloud Functions) + a reverse proxy using Cloudflare Workers

It helps to have a monorepo setup with packages/projects such as "api", "worker" (cron job) etc. all consuming the same environment variables (db connection settings etc.), when the cron job "serverless" function is deployed, it just picks the required environment variables from the shared "env" folder/package.