Startup GraphQL-Mesh when GraphQL handler is unavailable

[csuriano23]

Hi everyone,
I have a graphQL mesh server orchestrating a bunch of graphQL services with the proper handler.
Is there a way to startup mesh before the services are ready and available? Maybe using some static fallback graphQL schema collection.

Thank you

[ardatan]

When you build the artifacts, Mesh saves all the data needed for startup so following startups don't need those services to be up.

[ardatan]

Are the files driving this process all contained under the .mesh folder?
Yes
When mounting the folder as a volume in a simple docker-compose with graphql-mesh I still se a ping for rebuilding the schema
I need a clear and minimal reproduction :)

[csuriano23]

I think I got your point, it is the mesh build command that fetches the schemas in the .mesh folder, so when the build has run the mesh start won't fetch the schema anymore.

Anyhow my configuration is:

• The compose file

version: '3.8'

services:
  mesh:
    build:
      context: .
      dockerfile: Dockerfile
    restart: unless-stopped
    volumes:
      - ./config/mesh/:/app/config/
    command: npm run start

• The Dockerfile

FROM node:18.9

WORKDIR /app

COPY ./config/mesh/package*.json .

RUN npm ci

EXPOSE 4000

• The package.json

{
  "name": "sample",
  "main": "index.js",
  "scripts": {
    "start": "mesh dev --dir /app/config"
  },
  "dependencies": {
    "@graphql-mesh/cli": "^0.78.25",
    "@graphql-mesh/graphql": "^0.31.18",
    "graphql": "^16.6.0"
  }
}

• The mesh configuration file

sources:
  - name: my-service
    handler:
      graphql:
        endpoint: http://my-service:4000/graphql

If I understand correctly the mesh dev never skips the build phase, while deploying to production (switching to mesh build && mesh start) the two steps are clearly identified.
Unfortunately even if I skip the build after the first time, I have run build&start for fetching changes from schema, since I don't see a way to do hot schema switch.

[ardatan]

yarn dev is for dev apparently, not recommended for production.
Let's see what you want; you want to fetch changes but you also want to start the gateway while the service is down :) :)
Everytime schema changes, you have to rebuild and start again. That's how it works currently.

[csuriano23]

They are two distinct needs in fact :) I'd like to restart the service without re-checking the sources and this can be done avoiding the build, but I'd like also to have a way to re-fetching the schema when sources change and for doing this the only way is build & start, so I need two different entrypoints in fact (or I have to keep doing always build&start like I do now)

[csuriano23]

Thank you for the support @ardatan