Plans for the new year! ✨

[sansyrox]

Hey All! 👋

Wishing everyone a very happy new year. I have been on vaccation from 28th December and will be a little afk till 10th Jan. I will be on full throttle after that.

I am a believer of the statement that "Plans are useless but planning is important." and I plan to remain flexible throughout.

However, I do have some targets that I would like to achieve this year.

• [x] Check windows and mac support - Mac support works fine for me on intel macs. Need to check if it works well for arm macs as well.
• [ ] Add a way to release on test pypi before actual pypi
• [x] Add the bases of python stubs
• [x] Add flake8 config for the entire project
• [x] Fix hot reloading
• [ ] Better support for cargo fuzz
• [ ] Use click for better cli parsing
• [ ] Web3 extension
• [x] Middleware support
• [x] Make readme more colorful
• [ ] add the link to the benchmarking scripts.
• [ ] Make better support for ORMs
• [ ] Make a community of plugins
• [ ] Split the branches in stable and main
• [ ] Improve docs website
• [ ] JSON response parsing for the dictionary
• [ ] Better jsonify method
• [x] Response customization More docs / customization on the response should be supported (e.g. headers, status codes, and so on). Is it already implemented?

These are some of the plans that I would want to achieve this year. If the community has any suggestions that you'd like me to include, I'll be happy to take them under consideration.

Happy new year again. Hope this year is better than the last one! 😄

[klaa97]

Very exciting! And super congratulations for this project 👏

A few possible points of improvements are below!

Response customization

More docs / customization on the response should be supported (e.g. headers, status codes, and so on). Is it already implemented?

OpenAPI

Have you considered adding an OpenAPI integration? I think that it is one of the main key points for the success of FastAPI in the Python ecosystem, and it would surely enhance the dev experience a ton.

As for how to do that, I think there have two main routes:

• going the Python way (similarly to FastAPI)
• integrating it directly in Rust with Actix (but it may be more tricky I think, since the parsing will be written in Python, and you'd have to extrapolate it from the pyo3 function signature).

This also means having a standardized way to access requests' parameters and body, so that they can easily be parsed and put in the OpenAPI doc. What do you think?

Mypy

I see a project with Rust and I am very excited thinking about type safety, but there is no Python typing in the current functions; have you considered adding them?

Python communities are going towards type adoption since it helps a lot to identify bugs with static checking. The code is also not big so I think it wouldn't even be very difficult to add 😄

[sansyrox]

Hi @klaa97 ,

Sorry for the late revert( I was travelling back from vacation) and thank you for the great suggestions! 😄

Response customization More docs / customization on the response should be supported (e.g. headers, status codes, and so on). Is it already implemented?

This is definitely in the works. Added to the roadmap!

OpenAPI Have you considered adding an OpenAPI integration? I think that it is one of the main key points for the success of FastAPI in the Python ecosystem, and it would surely enhance the dev experience a ton.

I was considering just Swagger integration but this is much better. However, I do have one question: Do people only use this in dev mode and not in prod? If this is the case then, plain python will not be an issue otherwise we may have to look at the rust integration.

Mypy I see a project with Rust and I am very excited thinking about type safety, but there is no Python typing in the current functions; have you considered adding them?

I am not a big fan of strongly typed languages(sorry but this is just me xD) BUT I found out that the community loves them. So, this is definitely a high priority issue. But, I don't have much experience with it so any help(either docs, resources or code contributions) would be highly appreciated.

Thank you again for the amazing suggestions 😄 ✨

[klaa97]

I was considering just Swagger integration but this is much better. However, I do have one question: Do people only use this in dev mode and not in prod? If this is the case then, plain python will not be an issue otherwise we may have to look at the rust integration.

Usually, an OpenAPI integration that allows having a ReDoc/Swagger documentation is used also in production (obviously not public if the service is not open source)... but there should be no performance drawbacks apart from a small one during server startup: you build the OpenAPI YAML only once from the routes you define, and then you can serve it using Swagger or ReDoc.

[sansyrox]

but there should be no performance drawbacks apart from a small one during server startup: you build the OpenAPI YAML only once from the routes you define, and then you can serve it using Swagger or ReDoc.

The startup doesn't really matter much. I was worried more about request serving. This makes sense. I'll have a look at the docs. Thank you! :D

[sjquant]

Super cool project! I'm looking forward to using it in the future.

[sansyrox]

Thank you @sjquant . It really means a lot. :D

[crypt0miester]

may I suggest using msgspec for json encoding and decoding.

https://github.com/jcrist/msgspec

[sansyrox]

Thanks @crypt0miester . I was not aware about msgspec. Is it faster than the native python json encoding and decoding?

[crypt0miester]

indeed it is. it is rather faster than orjson.

it has amazing functionalities other than jsonifying

[sansyrox]

Ah, perfect then. I will go through the documentation. Thank you! :smile:

[shaohaiyang]

robyn + prisma + jinja + htmx + openapi/swagger = Perfect !

[sansyrox]

@shaohaiyang , that's the plan for this year 😉

[sansyrox]

Also, you might not even need htmx 👀