35.1

From:

• ^i

To:

---

Implement the schedulable Django Views registration API

---

The steps to implement this are as follows:

1. Research existing View registration
2. Formalise registration of Schedulable Views
3. Create register_schedulable_views django-admin command

Research Existing View Registration

Django uses a lazy loading strategy whereupon the first request it receives it builds the URLResolver tree, which is made up of URLPatterns and URLResolvers which is how it recurses.

I think I am now equipped to move onto the next stage.

Formalise “registration” of Schedulable Views

classDiagram
class EndpointDefinition {
	name
	url
	method
	headers
}

• must accept and return application/json
• name is Django name
• url is Django route + root
• method is fixed to one
• headers are space for additional meta
• url must also support Django-style URL variable patterns RoutePattern: <int:$VAR_NAME> etc, as this is a key mechanism of Django to variablise views.

This is a key missing ocmponent of the current EndpointDefinitions and ScheduledRequest design as they only support args as URL params: ?a=1&b=2... or as a json body: {"a": 1, "b": 2}.

Formalising EndpointDefinition.url

Django provides _route_to_regex which translates the django RoutePattern into a regular expression. I think this can be used to populate it on the other end.

Given _route_to_regex is protected, storing the route and using _route_to_regex function indirectly is preferred. Looking around, I don’t think converting to a regex is the way to go. The route is a form of template string.

Template string population is effectively provided via the reverse function, but this cannot be operated directly as it requires the URL patterns to be configured in the urlconf.

Another approach to this API would be to treat the tasks as a router and let Django handle the reversing itself.

We could then just provide a fixed api_router endpoint which would resolve a view by its name and return the result of that view.

This side-steps the need to store a list of “registered” endpoints and leaves the routing (other than to the service) up to the service itself.

Thus, all we are implementing is a “Service-level Reverse”, a powerful concept indeed.

---

This eliminates the need for a “Task Registry” altogether.