nodejs-api-starter VS rushstack

(1) React + API monorepo VS (2) React + API as separate repositories

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

https://github.com/kriasoft/graphql-starter - See web/relay.config.js, run: yarn relay

Your first example is the code-first development approach (example), while the latter one is schema-first, popularized by Apollo.

Source code (example): https://github.com/kriasoft/graphql-starter

Here is yet another example of a Node.js (Express) middleware that encodes/decodes JWT (OAuth) token into a session cookie: https://github.com/kriasoft/graphql-starter/blob/main/api/session.ts

Details: It's going to be a Reddit-like community but for books. Just started working on this idea last week (solo) by branching out from graphql-starter open source template. Looking for feedback and feature requests.

Yes, for example:

If you're looking to recreate the ease of a monorepo with eslint/prettier, I've used the rushstack eslint patch to ship an eslint package which is almost fully self-contained, not just config, but dependencies as well: https://github.com/microsoft/rushstack/tree/main/eslint/eslint-patch

I highly recommend rushstack. It’s a suite of tools for managing TypeScript monorepos. I use it at work and never want to go back to working without it.

https://rushjs.io/ and https://rushstack.io/

Rush Stack. It’s an opinionated, batteries-included toolset for working with large monorepos. It’s highly extensible and pluggable, and has built-in support for a lot of common tasks. My team uses it at work to support a couple dozen projects and at this point I can’t imagine managing a monorepo without it. It has significant adoption within and support from Microsoft, and monthly public dev meetings with contributors from a number of other companies, so I really don’t think it’s going to disappear any time soon. From what I’ve seen, it’s a very healthy project that’s continuing to grow in support and adoption.

Tools like Lerna, Bazel, Nx, Rush, Turborepo, to name a few. Lerna is probably the grand daddy of all monorepo tools. CRA, Babel, Jest are a few projects that use it. Bazel has been refined and tested for years at Google to build heavy-duty, mission-critical infrastructure, services, and applications. Turborepo is the monorepo for Vercel, the leading platform for frontend frameworks. These tools can help keep your monorepo workspaces fast, understandable and manageable.

We don’t use backend node, I work in a big typescript monorepo and use Typescript to build plugins for compiling, packing, and testing, leveraging Rush and Heft on the client side (https://github.com/microsoft/rushstack) run via node

I guess I'm not alone wishing that rush uses commit messages for change log generation. It's actually not so difficult (once it's done 😎).

See: ONNX/ONNX Runtime, VSCode, Rush, & countless others

To late to edit or delete my comment above but just to set it straight I just learned that the whole lerna debacle linked above was a nothing-burger aka “fake news”.

https://github.com/microsoft/rushstack/issues/673#issuecomme...