Skip to content

ReactPy ASGI App and Middleware #1110

Description

@Archmonger

Current Situation

Currently we perform ASGI routing via backend-specific APIs. However, it is much easier to gain broad compatibility via ASGI middleware. Additionally, we should have a "standalone" mode where ReactPy can run in a production configuration without any backend.

I originally pitched this concept a long time ago during our development of our configure() function.

Proposed Actions

Create a ReactPy ASGI application and middleware.

Interface Design

# This is "standalone mode"
from reactpy.backend import ReactPy

app = ReactPy(my_component)

# This is "middleware mode"
from reactpy.backend import ReactPy
from sanic import Sanic

app = ReactPy(Sanic())

Implementation Draft

import re

from asgiref.compatibility import guarantee_single_callable


class ReactPy:
    def __init__(
        self,
        application=None,
        dispatcher_url="reactpy/stream/${route}${query}",
        modules_url="reactpy/modules",
        static_url="reactpy/assets",
    ) -> None:
        self.user_app = guarantee_single_callable(application)
        self.url_patterns = "|".join((dispatcher_url, modules_url, static_url))

    async def __call__(self, scope, receive, send) -> None:
        """The ASGI callable. This determines whether ReactPy should route the the
        request to ourselves or to the user application."""
        if not self.user_app or re.match(self.url_patterns, scope["path"]):
            await self.reactpy_app(scope, receive, send)
        else:
            await self.user_app(scope, receive, send)

    async def reactpy_app(self, scope, send, receive) -> None:
        """The ASGI application for ReactPy."""
        # This will handle the following: `index.html` view, component dispatcher, web modules, and static files.

Activity

  1. Archmonger commented on Jul 17, 2023

    @Archmonger
    ContributorAuthor

    @rmorshea I can also develop a WSGI variant of this. However, it will only work with WSGI webservers that have official websocket support: werkzeug, gunicorn, eventlet, and gevent.

    The design of this would be largely based on flask-sock.

  2. rmorshea commented on Jul 17, 2023

    @rmorshea
    Collaborator

    If we could take a similar approach to simplifying the flask/tornado backends that would be good too. If not, doesn't seem necessary. Regardless, probably should be done in a separate PR.

  3. Archmonger commented on Jul 17, 2023

    @Archmonger
    ContributorAuthor

    WSGI middleware would grant us compatibility with the following frameworks: https://wsgi.readthedocs.io/en/latest/frameworks.html

    Unfortunately tornado uses its own custom API, so we would either need to drop support for tornado or keep using configure() for it. To be honest, I'm leaning towards dropping support because tornado does not have built-in integration with Jinja template tags.

  4. Archmonger commented on Aug 26, 2023

    @Archmonger
    ContributorAuthor

    I'm realizing that tornado support should almost certainly be spun off into its own package, similar to ReactPy-Django.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions