New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
tongda opened this Issue Sep 26, 2018 · 6 comments

Comments

Projects
None yet
6 participants
@tongda
Copy link

tongda commented Sep 26, 2018

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

This comment has been minimized.

Copy link
Member

tomchristie commented Sep 26, 2018

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

This comment has been minimized.

Copy link

tongda commented Sep 26, 2018

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

This comment has been minimized.

Copy link

auvipy commented Sep 30, 2018

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

@Dopebiz6Dime

This comment has been minimized.

Copy link

Dopebiz6Dime commented Oct 8, 2018

I think I might have a solution with this .. I’m working on something very similar now

@lucianoratamero

This comment has been minimized.

Copy link

lucianoratamero commented Oct 9, 2018

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

@tiangolo

This comment has been minimized.

Copy link

tiangolo commented Dec 27, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment