Do you use Swagger, or document your API?

Not sure if it is needed for GraphQL as well, as you already have GraphQL playground.

Swagger is a way of documenting REST API.

Recently, I have been using fastify (which validates schema with ajv), and integrate with OpenAPI v3 via fastify-oas. Still, I feel that it needs some more validation layers.

• Frontend layer
• Database layer -- I had better use SQL / ODM (on top of NoSQL)?

Comments

[Stefan van de Vooren]

GraphQL comes out of the box with a shema graphql.org/learn/schema/. This schema can both be used in your playground as for contract based testing. So I don't see the need combine Swagger when you have GraphQL. Otherwise think Swagger is outstanding. You can generate stubs from you api swagger.io/tools/swagger-codegen/ and generate Typescript definitions from you swagger files

[aRtoo]

I use swagger to document my API. What do you mean by validation? OpenAPI has a security tag that you can use.

[Pacharapol Withayasakpunt]

JSON validation means that the server will not accept any wrong JSON schema.

Also, I have to make sure my database, especially if it is NoSQL, will not break with bad data.

Never trust user inputs.

[aRtoo]

if its a public API you can use ajv I guess. But if it's within a team OpenAPI will do because the team will have to create the payload from frontend to backend.

[Franco Riberi]

What about github.com/tiangolo/fastapi?

[Pacharapol Withayasakpunt]

Yes, that is how I learnt about easy-to-make Swagger in the first place.

But Python is not always compatible with WebView Desktop Applications...

Also, I love TypeScript, and I feel it is better than Python for IDE.