Apollo-server: Typescript

[TimMikeladze]

Since the client is written in Typescript, I think it makes sense for server to be as well.

[helfer]

@TimMikeladze Yeah, we have an issue open on graphql-tools (which originally contained apollo server) https://github.com/apollostack/graphql-tools/issues/6

Would be great to use Typescript for apollo-server as well, and should be less work than for graphql-tools, because there's less code. Do you want to take a stab at it and work on a PR? I'm sure @jbaxleyiii would be happy to give guidance.

[TimMikeladze]

Yep, going through the code now. Will send a PR.

[helfer]

Awesome!

[helfer]

@nnance also expressed interest in working on this. We could do this rewrite in conjunction with adding Hapi support. Let's use this issue thread to talk about the typescript implementation, and how we can factor out the core parts of Apollo server so it's easy to write bindings for Hapi, Express and Koa!

[bkinsey808]

Hi folks, I'm interested in possibly helping with this. I like typescript and I like graphql, so what will it take to get these two playing nicely together on the server?

[nnance]

I have started a prototype of the architecture I would recommend based on TypeScript. You can find it here. I will try to have it working with Express and Hapi by the end of the day. This is a super naive implementation but represents the architecture I would recommend. Apollo server should be a wrapper / extension of the core Graphql JS library and completely separated from the web frameworks like Express, Hapi, Koa, etc. In fact the Apollo server should have an API that doesn't interact with the aspects of HTTP (Request, Response) at all. To this point I think we should start a conversation of what the API for Apollo Server should be. From there we can divid up the work with someone building the Apollo Server core and others building the web framework wrappers. To start the conversation I would recommend the following:

1. Apollo Server would be a class that would be instantiated with a schema and validation rules
2. It would have a method called fulfillQuery that would parse, validate and execute the query returning an object that would contain an errors and or data

This matches my prototype. However, we could change the api to separate the calls to parse, validate and execute much like the Graphql api. I prefer a simple api.

Thoughts?

[HriBB]

I use Koa and would love to help. Will check out your implementation soon

[helfer]

I will try to do start a rewrite today, and do #11 at the same time.

[nnance]

@helfer I am interested in helping if you can think of a plan to divid up the work. just let me know.

[helfer]

@nnance Yes, we can definitely split it up. I think the easiest way is if I write the core, and you write the bindings for express and HAPI.

@HriBB would you be interested in writing the bindings for Koa?

[HriBB]

@helfer sure, I can give it a try. Will do some research ...

[helfer]

Closing this in favor of #11, which is implemented in typescript.