Starlite updates March ‘23

litestar-org

Recap

What’s Starlite?

Starlite is a flexible and highly performant ASGI framework, focused on building APIs while delivering great developer experience by offering ready-built solutions for common tasks such as ORM integration, caching, session management, key/value stores, OpenAPI-schema generation and interactive API docs, type safety and much more.

You can read more about Starlite’s features in our documentation!

So what’s new?

Starlite 2.0 is on the horizon

It’s been over two months since we announced Starlite 2.0, more as a side note than major news, so it’s about time to see how things are going!

Firstly, as with any proper project, there has been a slight feature creep, and the 2.0 update will be a bit more involved as initially expected. But we have it under control. We can stop at any time. I promise.

Jokes aside, the announcement still holds true: Starlite 2.0 retains most of its core functionality, and from a user perspective, not a lot has to change when upgrading your app from 1.x to 2.0; If you don’t want to make use of new features, the upgrade path will mostly consist of changing some import paths and slightly adjusting a few configuration values.

But let’s take a look at what has changed, and what is yet to come.

Adieu Pydantic

Starting with the release of 2.0.0alpha1, Starlite replaced most of its internal models that relied on Pydantic (mostly with data- or plain classes). In the following releases leading up to`2.0, we will remove the last dependencies on Pydantic, and you can use Starlite completely Pydantic-free.

But why?

The main motivations behind this were performance improvements and flexibility:

Performance

Pydantic is a great library, but being fast is not one of its strengths. Its performance will likely increase drastically in version 2.0, with the core validation logic written in Rust, but early tests indicate that it will likely still be slower than other libraries when it comes to (de)serialization.

In many cases this might not be an issue, but having the option to switch to an alternative if desired is still a valuable option, and can have significant impact on the overall performance of an application.

Flexibility

Pydantic is by far not the only library of its kind, with prominent members of the same class being attrs, cattrs or even plain dataclasses for some use cases.

Starlite currently only supports modelling data with Pydantic, which means this will necessarily force an integration of Pydantic into the rest of the application’s layers, be it by directly using Pydantic models there, or simply the need of an additional “translation layer”.

By removing Starlite’s reliance on Pydantic, we’re opening doors to a new, more flexible type of integration, which will ultimately allow to plugin in arbitrary modelling libraries.

Does this mean I won’t be able to use Starlite with Pydantic anymore?

No. Starlite will continue to support Pydantic modelling of any kind, and you’ll be able to keep using Pydantic models everywhere you’ve used them before.

Pydantic will be removed as a core dependency eventually, which means Starlite will be able to run without it, but there are no plans to stop supporting it.

All new DTOs

DTOs will become more integral in Starlite 2.0, taking care of most of the data conversion between various types of models.

This feature is yet to be released, but it will allow you to seamlessly use data modeled with for example Pydantic, SQLAlchemy, msgspec or dataclasses in your route handlers, without the need for an intermediary model; The conversion will be handled by the specific DTO “backend” implementation. This new paradigm also makes it trivial to add support for any such modelling library, by simply implementing an appropriate backend.

emit(“we have an event bus now”)

Starting with the first alpha release — 2.0.0alpha1 -, Starlite includes a simple event bus that can be used to emit and receive events, supporting both synchronous and asynchronous listeners. Currently only a basic in-memory, per-process backend is included, but future versions will add support for inter-process communication by adding backends for Redis, RabbitMQ and others.

This is an exciting new feature, as it allows powerful patterns such as websocket broadcasting, or can, in combination with background tasks,
eliminate the need for external task queues such as celery or arq.

Data stores

Another exciting new feature coming in 2.0 are the all new, fully integrated
data stores. They are simple key/value stores, including backends for the file system, memory, or common key/value databases like Redis.

These stores are managed centrally by a registry, providing easy configuration, isolation and a hierarchical structure via namespacing, and
integration with third parties such as plugins. Via the registry it’s possible to easily access stores used by various built-in features such as rate-limiting or request.

What else is new?

To keep this post (relatively) brief I won’t mention all the changes going into 2.0, so if you want to know everything that’s changed until now, you can take a look at the detailed 2.x changelog, which includes all the currently released changes, features (and bugfixes).

What’s left to do

There are a few more things that have to be done before Starlite 2.0 will be released. Yesterday the second alpha version (2.0.0alpha2) has been released, but it won’t be the last development release before 2.0.0.

A few major items on the 2.0 todo-list currently are:

  • Finishing new DTO implementation
  • Adding signature modelling backend using attrs
  • Remove the remaining parts that rely on Pydantic
  • Writing a migration guide for 1.x > 2.0
  • Writing tutorials / prose documentation for the SQLAlchemy repository

and of course lots of minor issue that need taking care of.

There is no set release date for 2.0, but as things are currently going, I expect one more alpha release before the first beta version comes out. At this point, no more breaking changes will be introduced, allowing the beta to be tested for a while before it can be considered stable and ready for the final release.

And as always, if you want to get involved or in touch, check out Starlite on GitHub or join our Discord!