The 0.4 Release


#1

I’ve pushed ahead with making the 0.4 release. I know it’s a significantly smaller framework now, no we don’t have the API docs back in yet, no we don’t have command routing, etc… but we need to do this.

Everything’s looking so much nicer, and you should expect to see some of the other core bits of functionality such as the API docs coming back in soon enough.

We’ve finally got some proper documentation too: http://www.encode.io/apistar/

I’m really pleased that it’s now properly an ASGI framework. There’s also tons of foundational work in the API schema stuff that’ll come through nicely. We have OpenAPI support as the default now. And we’ll also be getting much nicer client libraries, and more functional API docs, once I’ve addressed the JavaScript side.

The event hooks are one thing I’m not sure is quite right yet. It’s possible that actually we ought to run on_response for any APIException subclass, and only run on_error for anything else (ie. unhandled exceptions.) but I’m way more in favor of getting the new release and documentation out the door, and prioritizing what comes next based on that.


#2

:tada: Yay for 0.4 release and for documentation! Thank you for the hard work.

Are you going to add a guide for component usage and creation? I think I have a better understanding now from reading the source but when I first came to the framework I relied on the README.md for the first few components I wrote. For example I am looking at how dependency injection identifies which component to bring in. If I want to have two SQLAlchemy Session components accessing different databases then how would I create the appropriate identity to differentiate them? Those are the kind of questions I hope the documentation can answer in the future for new people to the framework.


#3

One answer to this is to just stop using components in that way. The framework had gotten a bit carried away along those lines previously. We don’t necessarily need to add in extra layers when you could just be using the packages directly. For now I’d probably suggest a bit more explicit behavior.

Having said that, yes it would certainly be worth having an example at least of using components and event hooks together provide for automatically handled commit/rollback against SQLALchemy sessions.

Also the components documentation is a generally bit thin at the moment.