This is going to be a recurring question over the coming months.
It might seem counter-intuitive to have started working on an entirely new API framework, given that Django REST framework already exists, has a huge community, and has some wonderful sponsors backing it’s continued development.
- Django is, and may well always be, a syncronous framework. Granted it can be run behind an asyncronous gateway, using Channels, but it doesn’t (attempt to) compete in the same type of space as Node or Go. For most businesses Django tends to sit in the important space, but there is still a very valid market for super-high-throughput services. Ideally I’d like API Star to become an incredibly productive alternative to the type of services that you might typically use Node or Go for.
- Django is, and may well always be coupled to the Django ORM. For anything that doesn’t integrate with a relational database it’s likely not a great choice. API Star isn’t coupled to any particular backend.
- The view abstraction in Django doesn’t fit with API Star’s annotation style. We could crowbar it in, but we’d still be loosing eg. the lightweight nature of API Star where each view only pull in exactly what it needs, if we were running within Django’s middleware stack, and database transaction wrapping.
- There’s no way we could change REST framework serializers into API Star’s schema types without breaking huge amounts of existing user code. We could add them in alongside the existing serialization as an alternative, but that’d be kinda weird, and add yet another way around for folks to do things in REST framework.
So, upshot is that at least for now, these are two separate projects. Where they are like to tie in is this:
- Supporting Django’s ORM and Migrations as an optional backend in API Star is absolutely do-able. That’d be wonderful, as the ORM & migrations are a super productive choice for developers.
In the future there’s some possibility of closer integration. We could certainly build full Django / API Star compatibility, where API Star really does run inside a Django request/response cycle. That feels like a bit of a fuzzy option tho, being not quite one thing, and not quite the other.
Important thing in all this is going to be to make sure we’re keeping our users and our sponsors happy. I’m dead certain that it’s really important for us to be working on API Star alongside the existing work on Django REST framework. This is about us trying to look ahead at what the next 10 years might bring, and making sure we’re building the things that developers need, rather than getting stuck into a single comfortable spot.