How the amazing type system feature will be integrated with other frameworks after v0.6?

[tongda]

I like the type system very much, but it seems there will be no server side support since v0.6. What is the future plan of this amazing feature?

[tomchristie]

Yup good question, so...

Previously in API Star the intent was to use types in the function signature to build up the API description. Actually I think that's a bit awkward because:

• It completely changes the kind of interface that we expect from the handlers - that's potentially okay, but it does mean that it doesn't adapt well to other frameworks.
• It doesn't play too well with decorators.
• It's not obvious how to differentiate between query parameters and body parameters etc...

I think a sensible pattern to bring API Star to a range of frameworks would be to eg. use decorators instead to annotate the expected inputs and outputs of different routes.

@query_params(
    search=String(max_length=100),
    score=Integer(min_value=0, max_value=10)
)
@response_body(MyType)

The decorators there could both apply the validation, and annotate the route in such a way that a schema generator is able to pick out the descriptions.

That sort of thing we could far more easily apply to a while bunch of different frameworks, and eg. allow users to use API Star together with Flask or whatever.

That's not necessarily the only style we could use to achieve that (eg. we could dig into docstrings and infer stuff from that content) but it'd be one of them. Other alternatives to this approach would be:

• Just use the typesystem stand-alone, eg. as an alternative to libraries like marshmallow, and don't include any particular support for automagically building a schema out of that.
• Use the typesystem stand-alone, and support having that generate schema definitions for the types, but don't automagically infer anything else.
• Build adaptations to existing frameworks to add apistar's previous DI style on top of them (not esp. keen on this)

This comment is related: https://discuss.apistar.org/t/api-star-as-a-framework-independant-tool/614/4

[tongda]

I understand.

I think I would prefer to 2nd option:

Use the typesystem stand-alone, and support having that generate schema definitions for the types, but don't automagically infer anything else.

From my perspective, type validation and auto schema generation seems to be a must-have feature and it would be very cool to be framework agnostic. On the other hand, DI is a nice-to-have feature to make code looks clean and fancy.

[auvipy]

I would be really happy to see them in with starlette...

[lucianoratamero]

there's already this ongoing effort to couple it with starlette, so give it a look :] https://github.com/PeRDy/starlette-api

[tiangolo]

Hey guys, I built something based on Starlette, heavily inspired by APIStar (I like to consider it a "spiritual successor" to APIStar).

You can define path, query, cookie and header parameters using types. The same for body requests, including deeply nested schemas, using Pydantic models. All is based on Python type hints, so you get autocomplete everywhere.

It has a dependency injection system, several security tools, all based on OpenAPI 3 (with automatic schema generation), including 2 different interactive API documentation web UIs, etc.

You might want to check it: https://github.com/tiangolo/fastapi

[tomchristie]

Closing, given https://github.com/encode/apistar/pull/649 - The type system is now a properly independant package.