Better Simple Logo

Informal Django Roadmap Ideas for 2024

Don’t forget to check out other folks ideas!

My shortlist is not in any specific order.

  1. Django Announcements Via The CLI
  2. Django Developer Certification / Path
  3. Database Backed Media Storage For Simple Deployments
  4. Common Table Expressions Support
  5. Advanced Tutorials
  6. Community Tutorial Repository
  7. Third-party Package Recommendations
  8. Recommend Classy Class Base Views

Django Announcements Via The CLI

One challenge facing Django as a community or an organization is reaching Django developers. One common trait amongst all of them is that they have Django installed in their environment. I would like to see Django publish specific messages to Django developers in their terminal. Such messages would announce DjangoCons, the Django Devs survey or major community initiatives. This could also pave the way for third-party packages to post announcements.

Django Developer Certification / Path

Many people join the Django Discord server and ask, what do I need to know to get a job? That’s a reasonable question. We have many authors in our community and even more folks who mentor others professionally. It feels like we could start with an official guide, then iterate until we have a certification.

The best I’ve come up with is my post about skills a professional Djangonaut has. It falls short of what these people need because it only lists skills and technologies. It lacks details on what to know and how to learn it.

Database Backed Media Storage For Simple Deployments

A frequent challenge for new Django developers is getting Django deployed. I believe there’s a path forward where we can help a developer get a project deployed and running on a server while also providing a path to configuring it for robust use. Supporting media files from the database is one way to simplify the production configuration of a Django app.

While this approach will encourage an inefficient setup for new developers, it will allow them to more quickly get a complex web app running. If we create tooling that evaluates a setup for what’s “production ready”, we can reduce the number of developers who try to use this initial setup for an actual application (see Advanced Tutorials about CI examples).

A DB-backed media storage along with Whitenoise eliminates two painful first-time deployment hurdles.

Common Table Expressions Support

Common Table Expressions (CTE) are frequently used in database queries with hierarchical data. Categories are such a data model. Django has a long-standing issue to add CTE support. I hope that this will add to the ORMs querying flexibility and achieve greater parity with DB functionality. CTE support in Django will provide a delayed benefit as developers discover different ways to use CTEs.

Advanced Tutorials

I would like to see more advanced tutorials tailored for beginners. Some suggestions are:

Testing an application A common question for newer developers is, what should I be testing? I think it’s reasonable for us to show a form view, then write out the typical tests for it. We could also show how to write tests that highlight some subtler bugs, such as the common N+1 problem.

I’d also love to see an end to end test example in our tutorials. This is a testing technique that is extremely useful, but requires consideration and planning.

CI/CD examples This should show the Django specific characteristics of a CI/CD integration, such as collectstatic, a production check and/or a smoke test. It shouldn’t focus heavily on the CI platform or the hosting provider.

Formset factory management The formset factory feature supports adding and removing forms on the client side, but doesn’t include any of the JS to make it work. This is a common feature of web apps. There’s enough functionality in vanilla JavaScript to implement this.

Advancing and reversing migrations Every Django developer has declared migration bankruptcy at some point in their journey. I’ve already written a lengthy post on this subject. I believe a tutorial that walks a developer through the following would be useful:

  1. Create schema migration
  2. Create data migration
  3. Migrate forwards
  4. Make a model change that requires recreating the schema migration
  5. Migrate backwards
  6. Replace file
  7. Update data migration
  8. Migrate forwards

While tedious, there’s valuable knowledge gained from such an exercise.

Community Tutorial Repository

I’d like to see a community tutorial repository created. These tutorials should undergo peer review and include automated tests to confirm which version(s) of Django they support. The peer review and tests will allow others to trust that the code works, that it’s reasonable and that it’s relevant.

This would require a project template for tutorials, an established level of expected testing and coverage, a system to run the test suite, and a code review process. Plus, this could eliminate the need for advanced tutorials in the documentation altogether.

Third-party Package Recommendations

As Carlton pointed out on Django Chat with Matt Layman, one of Django’s strengths is the third-party ecosystem, but we don’t announce which are the de facto standards. We leave it up to developers to determine which to use. Adam Johnson has a great post on this, it’s even in the docs, but do we really need to tell ask those 12 questions of django-anymail or django-allauth?

A tricky part is who decides what gets recommended? I don’t expect our Fellows to be the arbiter here. Which leads me to thinking this is best as a community driven metric. Perhaps we can pull PyPI statistics to show recent downloads vs historic. Or maybe even allow people to identify what packages they’re using on active sites?

Recommend Classy Class Base Views

Django’s class based views (CBVs) are difficult to understand all the various nooks and crannies. However, Classy CBV makes this much more manageable. This is a resource that should reference in Django’s documentation. I believe each of the CBVs should link to its respective page on https://ccbv.co.uk. We should make it easier for developers to make sense of CBVs.