The Pydiator is an in-app communication method.

ozgurkara ozgurkara Last update: Jun 30, 2022

example event parameter Coverage Status

Installation

https://pypi.org/project/pydiator-core/

add your requirements.txt pydiator-core or run the pip install pydiator-core command

Examples

Directly : https://github.com/ozgurkara/pydiator-core/blob/master/examples/main.py

Fastapi : https://github.com/ozgurkara/fastapi-pydiator

What is the pydiator?

Pydiator is an in-app communication method.

It provides that developing the code as an aspect. Also, it supports clean architecture infrastructure

It is using design patterns such as chain of responsibility, mediator, singleton.

Pydiator provides which advantages to developers and project?

  • Testable
  • Use case support
  • Aspect programming (Authorization, Validation, Cache, Logging, Tracer etc.) support
  • Clean architecture
  • Expandable architecture via pipeline
  • Independent framework
  • SOLID principles
  • Has publisher subscriber infrastructure

pydiator

How it works?

Pydiator knows 4 object types.These are;

1- Request object

  • Is used for calling the use case.
  • It should be inherited from BaseRequest
 class GetSampleByIdRequest(BaseRequest):     def __init__(self, id: int):         self.id = id

2- Response object

  • Is used for returning from use case
  • It should be inherited from BaseResponse
class GetSampleByIdResponse(BaseResponse):     def __init__(self, id: int, title: str):         self.id = id         self.title = title 

3- Use Case

  • Includes logic codes
  • It should be inherited from BaseHandler
  • It takes one parameter to handle. The parameter should be inherited BaseRequest
class GetSampleByIdUseCase(BaseHandler):     async def handle(self, req: GetSampleByIdRequest):         # related codes are here such as business         return GetSampleByIdResponse(id=req.id, title="hello pydiatr")     

What is the relation between these 3 object types?

Every use case object only knows a request object

Every request object is only used by one use case object


How is the use case run?

Should be had a particular map between the request object and the use case object.

Mapping example;

    def set_up_pydiator():        container = MediatrContainer()        container.register_request(GetSampleByIdRequest, GetSampleByIdUseCase())        #container.register_request(xRequest, xUseCase())        pydiator.ready(container=container)

Calling example;

    await pydiator.send(GetByIdRequest(id=1))

or

    loop = asyncio.new_event_loop()    response: GetByIdResponse = loop.run_until_complete(pydiator.send(GetByIdRequest(id=1)))    loop.close()    print(response.to_json())

4- Pipeline

The purpose of the pipeline is to manage the code as an aspect.For instance, you want to write a log for the request and the response of every use case. You can do it via a pipeline easily. You can see the sample log pipeline at this link.

You can create a lot of pipelines such as cache pipeline, validation pipeline, tracer pipeline, authorization pipeline etc.

Also, you can create the pipeline much as you want but you should not forget that every use case will be used in this pipeline.


You can add the pipeline to pipelines such as;

    def set_up_pydiator():        container = MediatrContainer()                container.register_pipeline(LogPipeline())        #container.register_pipeline(xPipeline())        pydiator.ready(container=container)

How can you write a custom pipeline?

  • Every pipeline should be inherited BasePipeline
  • Sample pipeline
    class SamplePipeline(BasePipeline):        def __init__(self):            pass            async def handle(self, req: BaseRequest) -> object:                        # before executed pipeline and uce case            response = await self.next().handle(req)                # after executed next pipeline and use case                        return response

How to use the notification-subscriber feature

What is the notification-subscriber feature?

This feature runs as pub-sub design pattern.

What is the pub-sub pattern?

publish-subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead, categorize published messages into classes without knowledge of which subscribers if any, there may be. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are.

How to use this pattern with the pydiator?

You can see the details that via this link https://github.com/ozgurkara/pydiator-core/blob/master/examples/notification.py

def set_up_pydiator():    container = MediatrContainer()    container.register_notification(SampleNotification, [Sample1Subscriber(), Sample2Subscriber(),                                                             Sample3Subscriber()])    pydiator.ready(container=container)if __name__ == "__main__":    set_up_pydiator()    loop = asyncio.new_event_loop()    loop.run_until_complete(pydiator.publish(SamplePublisherRequest(id=1)))    loop.close()

How to run the Unit Tests

install tests/requirements.txt

pytest tests/

Subscribe to our newsletter