Deno 1.0 support

[pierreyves-lebrun]

Deno just got released today, do you have any plan for supporting it?

https://deno.land/v1

[WaseemRakab]

Looking forward to it !!

[AnkurSaini07]

Any update????

[suprsidr]

https://github.com/garronej/denoify

[vegerot]

Waiting with baited breath 🙂

[glasser]

We're not actively working on this, but it's certainly attractive. We do make use of Node-specific APIs in Apollo Server but could probably abstract that out.
graphql/graphql-js#2566 would be a prerequisite.

[vegerot]

We're not actively working on this, but it's certainly attractive. We do make use of Node-specific APIs in Apollo Server but could probably abstract that out.

graphql/graphql-js#2566 would be a prerequisite.

Do you know the cause of graphql/graphql-js#2566 (comment) ?

[glasser]

I don't know, but I do see that the graphql-js issue isn't closed, which suggests it's not supposed to work. @IvanGoncharov would know more.

[danbim]

If I read that comment correctly, graphql-js should work with deno now: graphql/graphql-js#2566 (comment). Maybe that helps?

I'd be really interested in using Apollo Server on deno as compared to graphql_tools and related some things (like caching support) seem to be just better/easier to use in Apollo Server.

[glasser]

It seems like this isn't part of a released version of graphql-js, just a tree? But maybe that's how Deno works (loading from git rather than npm) anyway?

I don't think anyone on the core team here is an expert on Deno. It seems reasonable to make AS support Deno if it's not too invasive, but this probably will need to largely be contributed by Deno users.

[NfNitLoop]

Adding my voice to those requesting this. I'm a big fan of Deno. I was just trying to convince my company to adopt TypeScript (in Deno) because of the awesome TypeScript libraries for GraphQL. I was surprised to find that Apollo doesn't yet support Deno. 😞

I'd add: Without support, there's risk of folks doing this kind of thing, forking to add Deno support, then leaving an unmaintained fork out in the wild.

this probably will need to largely be contributed by Deno users

Hmm, maybe a fun weekend project. I might take a look. @glasser any recommendations for a new contributor?

@ others: Is this not working for you via esm.sh or Deno's new npm compatibility?

[NfNitLoop]

This seems to mostly work for me:

#!/usr/bin/env deno run --allow-net --allow-env --allow-read=.

// Minor problem: Every time I run, Deno (re-)tries downloading 
// https://esm.sh/v115/@types/graphql@14.5.0/graphql~.d.ts
// looking for types, but ESM says they're not found.
// Something to take up w/ the graphql or esm.sh folks.

import { ApolloServer } from "https://esm.sh/@apollo/server@4.6.0"
import { startStandaloneServer } from 'https://esm.sh/@apollo/server@4.6.0/standalone';

// The GraphQL schema
const typeDefs = `#graphql
  type Query {
    hello: String
  }
`;

// A map of functions which return data for the schema.
const resolvers = {
  Query: {
    hello: () => 'world',
  },
};

const server = new ApolloServer({
  typeDefs,
  resolvers,
});

const { url } = await startStandaloneServer(server);
console.log(`🚀 Server ready at ${url}`);

My test:

> curl --request POST --header 'content-type: application/json' --url 'http://0.0.0.0:4000/' --data '{"query":"query { hello }"}'
{"data":{"hello":"world"}}

[trevor-scheer]

@NfNitLoop if implementing this in Apollo Server is interesting to you, take a look at this issue. I think what I've outlined there would be sufficient to enforce support for non-node environments in CI (and provide a list of all errors that a non-node env would encounter in its current state - i.e. a list of things that need replacing if we were to support non-node). I'm willing to offer guidance there if you're interested in handling the implementation.

[NfNitLoop]

@trevor-scheer Unfortunately, I don't have time to take that on. But hopefully the working demo above will at least let others see that it's not far off. (Anybody else want to volunteer? 😊)

Correct me if I'm wrong, but from my quick investigation yesterday, and the ticket you linked, my summary of Deno support would be:

• It mostly works in Deno, by using a third-party ESM bundler. (esm.sh in my example, but others likely work too.)
• But without automated testing, it's not guaranteed to continue working.

[trevor-scheer]

I'm not familiar with the first bullet - but it's definitely possible that using the ESM bundler tree shakes out all of the AS code that requires node builtin libraries (which deno hasn't polyfilled).

I do think that some form of automated enforcement would be both the path to the expected outcome (surfacing existing errors) as well as maintaining it / not regressing or breaking support by accident.