Porting from Rust SDK to TS SDK

[sordina]

Since we're already doing 99% of the heavy lifting with Deno, let's see if we can ditch the remainder of the rust and just have a full Deno stack.

Motivation:

• Simpler architecture - No need for a seperate background server
• If the user already has Deno installed then they can run the connector locally with one command for local dev
• Simpler docker image
• Faster build times for connector create
• More battle testing of TS SDK

Limitations:

• Still have to perform vendoring manually
• Tied even more to Deno (double edged sword)

See https://github.com/hasura/ndc-typescript-deno/issues for outstanding issues

Usage has changed slightly. Now the invocation should look as follows for local dev:

> tree
.
├── config.json
├── functions
│   └── index.ts
└── vendor
    ├── deno.land
    │   └── x
    │       └── [email protected]
    │           └── mod.ts
    └── import_map.json

5 directories, 4 files

> cat config.json 
{
  "functions": "./functions/index.ts",
  "vendor": "./vendor",
  "schemaMode": "INFER"
}

> cat functions/index.ts 

import * as doge from 'https://deno.land/x/[email protected]/mod.ts';

export function hello(): string {
  return "hello world";
}

/**
 * @pure
 */
export async function optional_test(a: string, b?: number): Promise<string | number> {
  if(b) {
    return 2;
  }
  return 1
}                                                                                                    

> deno vendor -f functions/index.ts
Vendored 1 module into vendor/ directory.

To use vendored modules, specify the `--import-map vendor/import_map.json` flag when invoking Deno subcommands or add an `"importMap": "<path_to_vendored_import_map>"` entry to a deno.json file.

> deno run --allow-sys --allow-run --allow-net --allow-read --allow-write --allow-env --watch --check 
https://deno.land/x/hasura_typescript_connector/mod.ts serve --configuration ./config.json
Watcher Process started.
Running Connector.start
Inferring schema with map location ./vendor
{"level":30,"time":1696906656996,"pid":78227,"hostname":"spaceship.local","msg":"Server listening at http://0.0.0.0:8100"}

[daniel-chambers]

Looks good, well done! Only minor feedback, nothing to hold up the PR.

[daniel-chambers]

How come there are two readmes?

[sordina]

Yeah this is due to deno.land hosting using the /src subdirectory, so it needs to find a readme in there.

See: https://deno.land/x/[email protected]

I'd like to just have one, but not sure how.

[daniel-chambers]

This ensures that these references will typecheck correctly in infer.ts.

Hrm, I wonder if this is true. Does Deno itself actually give the any type to its entire API, or does it actually have typings for all its functions? That could affect the the typechecker results.

For example, any function called using the below typing will return an any (which will then propagate to anything that uses the return value), but if the Deno tooling actually has real types, then the return type will be whatever it is, and subsequent usages of the return value will typecheck against that type.

Something to investigate later, though, not this PR.

[sordina]

Yeah good point. I guess if you do some kind of utility types on something Deno returns this could be an issue.

It seems to unify simple uses of the API.

[daniel-chambers]

I suspect it just seems to work, but actually doesn't. any is basically disabling the typechecker, so I reckon you could write some code that fails to typecheck in the IDE/normal deno, but passes when run through infer.ts.

Good enough for now, though. For the purposes of infer.ts, so long as the user explicitly specifies the function return type, it probably won't affect our inference results.

[sordina]

Oh yes for sure that's true. But keep in mind this is mainly for deploying already correct code, expecting that the user will have had the Deno tooling already pick up incorrect uses of Deno for them via the LSP. I think for correct Deno use, it shouldn't fail to typecheck.

[sordina]

So yes, let's see if we can use the actual Deno interface in the TS compiler in future. I'll put this in the limitations docs for now.

[sordina]

#37