Search code examples
architecturefrontendbackend

Design of an application

Our team is working with airflow integration.
We want to use airflow API ( airflow api ) for triggering DAGs.
For that we will create our Frontend/Backed web application.
Now the question would be from where DAGs need to be triggered. For example in some form in Frontend I will choose configuration for the DAG, which DAG I will run, etc. Then I will submit Form.
And here is a question. Then I will submit the form I can directly trigger the DAG from Frontend. Or I post to backend and the backend can trigger the DAG.
An answer would be good with some explanation why with pros/cons.

Solution

  • In light of the Single Responsibility Principle, Separation of Concerns, Modularity, and a few more principles I can think of - I believe your front-end should call a back-end which triggers the AirFlow DAGs. In my humble opinion, this approach leads to several good things in the design:

    1. You'll have 3 cohesive components with very clear responsibility for each - front-end shows the data, back-end serves the data to the front-end, and AirFlow does all data gathering/manipulations. This architecture enables better testability & deployability.
    2. You won't have coupling between presentation layer and data layer - in future you might decide that you want to replace AirFlow with something else, with this approach - the back-end is your abstraction and you'll only need to do the adaptations there, without touching/re-deploying the front-end (what might cause bugs, especially after years when there are new developers in the team who are not familiar with the old code).

    Having said that, in software architecture usually there is no "perfect" solution, it's all about trade-offs. I believe that given the scenario you presented, there are more advantages to the back-end approach.

    In addition, if you're interested, there is a book I recommend regarding these stuff Fundamentals of Software Architecture .