node-starter-kit VS jssm

Here is link number 1 - Previous text "API"

I'm deploying by either manually by running yarn deploy script or firing it via GitHub Actions when a PR is created, updated, or merged to the main branch.

Example: github.com/kriasoft/node-starter-kit

Nope. Just plain GraphQL.js + Knex.js (example), often typed manually since it's not where most of the time spend on when building an API server (though it can be automated via a scaffolding script if there are too many db tables). Generating TypeScript definitions off the actual db schema using knex-types (example).

Examples: - https://github.com/kriasoft/node-starter-kit - basic Node.js API starter kit - https://github.com/kriasoft/graphql-starter - monorepo template with GraphQL, React, Relay

I can help you developing a (GraphQL API) server for your web and/or mobile app as well as CI/CD workflows, optimized for serverless infrastructure in Google Cloud Platform. The initial version (first iteration) will be ready and live in under three days! Code examples:

https://github.com/kriasoft/node-starter-kit

You may want to browse through https://github.com/kriasoft/node-starter-kit to pick up some common patterns (e.g. transactional emails, OAuth 2.0 authentication, user sessions, views, db migrations, etc.).

https://github.com/StoneCypher/jssm

I find the DSL much easier to wrap my head around than the json format of Xstate.

By example, my hobby library JSSM has currently 4904 unit tests that get run in 14 different contexts, and 1.3 million unicode tests that get run in eight contexts.

I use tsc to compile and rollup to bundle

Javascript State Machine

By the way, this is written in Typescript, and type protections are used extensively.

Here's the test directory for one of my things.

This is my general approach