Typescript bindings

[web3d0]

I like the idea of GraphQL without the overhead of typing. As Typescript implements definition files, I'm wondering if interfaces can be specified for type checking messages. On both the client and server, the same definition file would be the reference interface.

So NextQL may achieve an opt-in typing safety same as GraphQL, without the overhead or complexity?

[giapnguyen74]

Well, we could discuss about type safe. Basically, client and server communication could be abstracted as
F(input) => output
With REST, we have no type checking both input and output.
With GraphQL, we're forced to define both input and output types.
NextQL same with REST have no type checking, but you could use nextql-validate or any verification framework which is both type and business logic checking.
My opinions:

1. Input verification is most important - it is for security and business logic.
2. GraphQL's input type checking cannot compare with any verification framework like joi or json schema (not yet)
3. Output type checking is not important - In fact, even GraphQL query don't use Output type . GraphQL use Output type to check server-side not client-side.
4. GraphQL server-side output type checking make integrate with internal services is complexity. Different with client-side, we have a ton of different technologies in server-side. They are SQL, non-SQL, micro-services, Key value so on.
5. Most value of GraphQL type checking is for development or static type checking. Another benefit is self document APIs, but I don't buy it. It could work with small APIs not complex systems. I working on Azure APIs, even with extensive documentation it is still hard to understand.

So I prefer:

• Input verification framework is your choice. It should be better than GraphQL input type checking. You could use both definition for client and server verifications (json schema or joi definition or anything else).
• Output type checking is omit for easy integrate with any kind of data/service on server-side. https://github.com/giapnguyen74/nextql-configuration is example for complex systems.
• GraphQL's static type checking rely on completely client-side: IDE plugin , eslint plugin or ts. I thinking about NextQL plugin at least checking for correct query shape.

If you have other opinions, I'm all ears.

[web3d0]

The interesting thing about Typescript is that the types can be in a definition file rather than inlined into the source code. Since the definition file is separate, it could be used to define an interface that both the client and server would use, and this file would be shared by the client code and the server code.

As Typescript removes the definitions and typing at compile time, the type information is not used in run-time, but the code will have been checked by this point already. In other words, there is no change to your existing NextQL code, it is more of a technique that can be used while writing interfaces.

Have a look at DefinitelyTyped repository for thousands of projects that have been typed.

[giapnguyen74]

Yes, I understands how typescript working. I just want figure out how to apply into NextQL. I takes GraphQL as example:

1. GraphQL is all about runtime type checking - typescript is static type checking. Yes, we could take advantage ts for opt-in type checking
2. GraphQL input type checking: I still prefer using input validation, again ts is nice to have.
3. GraphQL output type checking in server-side: in my opinion, it is useless. Ts is opt-in/opt-out type checking is more flexible.
4. GraphQL output shape (no type) checking in client-side over introspection query. It is cool for development but useless for production. Again Ts is opt-in/opt-out is better solution.

Currently, I busy on a sister project gstate. I hope it could help solve the problem of cache and real time support for nextql. I will back to ts after complete it.

[web3d0]

Yes, I am watching gstate as well. I have client/server through WebSocket and want some communications protocol between them. Server has a large database, the client queries for what it needs. But the client might be offline, so the client side also needs to implement the database too.

This is why I find NextQL and gstate so interesting. The client can store updates in the local database, then send the queued updates to the server when it's next online.