Custom dynamic endpoints

[vddesai1871]

I'm submitting a

• [ ] bug report.
• [x] feature request.

Current Behaviour:

Right now, hydrus only serves static data and provides standard CRUD operations over that data, it doesn’t allow the user to define some logic to process incoming data and provide generated output.

Expected Behaviour:

hydrus should provide some way to define dynamic endpoints, and thus let users define logic to process incoming data.

The Command Dispatcher Pattern and can be used. The developer can create a Command_dispatcher class having commands(extra logic) as methods ( following some protocol), then it can be passed to hydrus where hydrus will form commands according to the protocol and check whether the given (command_dispatcher) object has that attribute or not, if yes then get that attribute (method) and execute it.

Steps to reproduce:

Do you want to work on this issue?

Yes

[Mec-iS]

Are you talking about a Falcon/Flask-like pre_request and post_response hooks? This can be done programmatically using the Flask interface.

[vddesai1871]

Are you talking about a Falcon/Flask-like pre_request and post_response hooks?

Yes, something very similar to that.

This can be done programmatically using the Flask interface.

I don't know exactly how. But if we are talking about before_request method provided by Flask, then it applies to all requests. Which we do not want. Even if we find inbuilt support for having pre-request hook for individuals responders(like Item/get), it wouldn't work as Item/get is responsible for all hydra resources(Drone, State, etc.), and the developer might want to have pre-request functioning only for Drone class. You can find more details about it in the corresponding section of my proposal https://docs.google.com/document/d/1xh7j4RtipN1XolYdNu4edhxNWEcfqu2C8UVevi4ZQUg/edit?usp=sharing

maybe @chrizandr can better explain what we actually want

[Mec-iS]

IMHO we need to consolidate the existing functionalities before getting into improving the developer experience. Please run a double-check (a checklist maybe) about what it is currently usable in hydrus and what it is in the spec. I feel we still have something else to do before starting with adding features to improve the developer experience. We need a comparative overview of the current state and what we can provide to developers, for example:

• [ ] ...
• [X] pagination
• [X] hypermedia (we have hyperlinks covering all the use-cases in our responses?)
• etc.

[chrizandr]

What I meant by dynamic endpoints was for developers to be able to decide how the incoming data is to be processed. Right now, the only functionality that hydrus provides is for developers to be able to store data in a database without being able to control how the data is processed at the server end. There is nowhere that a developer can insert custom code to be able to create a full fledged server for their needs. I had something like Django's class based views in mind. We agree on a common input/output format(Hydra in our case) to be served using REST based HTTP, but also provide developers an option to introduce their own code to process the incoming data as per their own use cases.

A few examples I could think of is are cases where updates in the API data/resources need to be communicated to another service, custom function calls when certain type of data is inserted into the server, etc. These things are too broad for us to generalise and it would be good if we allow developers to use hydrus as a stack, which is what our ultimate goal is. I feel that what we have now allows for very little modification from developers and they need to us it as is, out of the box. This would make it hard for others to integrate Hydra into their existing APIs with hydrus.

[Mec-iS]

Is this something similar to use before_request and after_request decorators in Flask? Developer can just declare those hooks.

[chrizandr]

Is this something similar to use before_request and after_request decorators in Flask

Yes but those are more general to be done after every request. What if the processing needs to be done specific to an endpoint?

We are offering hydrus as a library to developers, where they only use a small script(the demo script in the docs) to create a hydra enabled server. What I had in mind was a full scale stack that allows developers to add hydra to their existing applications with minimal effort. There is custom code that needs to be added on every specific endpoint. Right now, there is no mechanism that allows people to do that, other than changing the hydrus source code for their needs. We need an interface for people to insert functionality wherever they need it.

This is a much more complicated and broader task, but I figure that we need to start working towards this.