Git Product home page Git Product logo

Comments (2)

tomchristie avatar tomchristie commented on August 28, 2024 1

I don't think we need to put too much focus on it, early on.

Sure. To me it's super important, because it's potentially the difference between "let's design monolithic frameworks that have to completely own the space to succeed" vs. "let's build a better ecosystem, throughout".

I think ASGI has a tremendous opportunity here to build a more collaborative ecosystem, and establish patterns whereby high-level frameworks are composed of nicely isolated units.

For example, if responder designs it's request and response models like so...

class Request:
    def __init__(self, scope, receive):
        ...
class Response
    def __init__(self, scope):
        ...

    async def __call__(self, receive, send):
        ...

Then they become nicely reusable in any ASGI app. You can drop all the way down to writing a simple "hello, world" ASGI application, without any of the rest of responder, but using a Responder request and/or response classes, and automatically getting it's content negotiated behavior etc.. as a result.

from responder.models import Request, Response

# I'm a standard ASGI app, you can run me directly with `daphne`, `uvicorn`, or `hypercorn`.
# You can test me with any standard ASGI TestClient.
# You can wrap me in middleware, or dispatch to me from any ASGI framework's routing.
class HelloWorld:
    def __init__(self, scope):
        self.scope = scope

    async def __call__(self, receive, send):
        request = Request(self.scope, receive)
        response = Response(self.scope)
        ...  # Do stuff
        await response(receive, send)

Working at those lower levels of abstraction isn't necessarily what most of us would be doing day-to-day, most of the time, but being able to is super important, and breaks down the "I need to understand how the complete framework functions in order to understand one of it's components"

I think it's important to start thinking about at least reasonably early on, otherwise you start introducing points of coupling that later become entrenched.

(I'll park these thoughts for now)

from responder.

kennethreitz avatar kennethreitz commented on August 28, 2024

I like this as a goal, but I don't think we need to put too much focus on it, early on.

from responder.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.