Proposal: Making Django Microservice-Ready for Federations and GraphQL

Django Internals
1

Dear Django Developers and Community,

django-microserives
django-microserives1920Ă—1975 122 KB

I hope this email finds you well. My name is Jackson Bakari a Senior Programmer at Gov. Tanzania working with Django for six years. I am writing to propose an exciting enhancement to Django that I believe will benefit the community and align with the evolving needs of modern web development.

Proposal Overview: I suggest making Django microservice-ready by incorporating features that support federations and GraphQL seamlessly. This enhancement aims to address the growing demand for scalable and flexible architectures in web development.

Key Points:

  1. Microservice Architecture: Enable Django to be more conducive to a microservices architecture, allowing developers to build and deploy independent services that can work together cohesively.
  2. GraphQL Support: Integrate native support for GraphQL within Django, empowering developers to take advantage of this powerful query language for APIs.
  3. Federation Support: Extend Django’s capabilities to seamlessly participate in GraphQL federations, facilitating the composition of services into a unified graph.

Potential Benefits:

  • Improved scalability by embracing a microservices approach.
  • Enhanced flexibility for developers to choose between traditional REST and GraphQL APIs.
  • Better integration with the broader GraphQL ecosystem through federation.

Discussion: I would love to hear the community’s thoughts on this proposal. Please share your insights, concerns, or suggestions for further refinement. Additionally, if you have experience with similar implementations or use cases, your input would be invaluable.

Next Steps: If there is positive community interest and support for this proposal, I am willing to contribute to the development effort. I believe this enhancement aligns with Django’s commitment to providing a robust and adaptable framework for web developers.

Thank you for your time and consideration. I look forward to a constructive discussion on how we can make Django even more powerful for the ever-evolving landscape of web development.

Best regards,

2

Hey there!
Before something goes to the core of Django, it would be nice to have this functionality as a thirdy-party package. Within this package it’s possible to measure how much traction the project receives from the community, and if you receive a lot of traction (users, issues, feature requests) then it would be much easier for this feature to be in the core of Django.
On my opinion: GraphQL would be in the same state as REST APIs is today for Django, having a separate package that adds funcionality to Django, like: django-rest-framework that has been around for years, and new ones arising like django-ninja.

1 Like
3

I think this link could be useful for you to propose features to django deps/final/0001-dep-process.rst at main · django/deps · GitHub

4

There are many GraphQL packages for Django already, such as Graphene and Ariadne. So they fit your needs? The advantages of merging such functionality into Django itself would be small compared to the cost, and typically Django cares only about core web technologies (HTTP, HTML, CSS, JS, RSS, etc.) not the abstractions built on top.

5

<opinion>

  1. Django is already microservices-ready through multiple mechanisms including Channels and Celery. I am not aware of any use-case or requirement that cannot be easily handled through existing solutions.

  2. I am one of those that have reached the conclusion that GraphQL is an anti-pattern. Personally, I hope that for Django’s sake it never becomes part of core. (Nor am I the only person reaching this conclusion - a web search for “graphql is an antipattern” will return multiple blog posts of people’s experiences with it.)
    That’s not to say that there aren’t situations where it may be beneficial - it does exist for a reason. However, I believe that more than 99% of all websites would never see a real benefit from its adoption.
    (Side note: I basically hold this same opinion regarding async views in Django, but that’s a different issue.)

  3. Similar to #2, and in contrast to #1, I believe that attempting a microservices implementation is, in general, also an anti-pattern in 99+% of all websites. Yes, in theory, scalability may be able to be improved by it - but the cross-over point it a lot higher than a lot of people would guess.
    What this means in practice is that you can start with a more traditional structure and look to alter your architecture later when/if it truly becomes necessary.

<opinion>

1 Like