janschmidmaier50
commented
1 year ago The question regarding, do we need a YARP is imho not an easy one. In the past the YARP was the authentification engine in the entire system. Now with .net 6, that is not the case anymore. The Web-frontends now already have a bearer token, once they contact the backend. So there is no need for that anymore.
Kind of BFF
The YARP can be maybe seen as a backend for front-end, although it is not really providing cutomized logic for the frontend. It can be more seen as bundeling endpoint from multiple backend services. It could then also do the versioning of the used endpoints - although this is tightly coupling the services again. The question here is, what the difference is between defining the used backend services within the YARP vs defining them in the front end. But defining them in the YARP comes with the costs and risk of having another service, using resources (hardware as well as effort / time). But... keep on reading
Having multiple different frontends
If one has multiple frontends, the YARP might be helpfull, IF the frontends share the same business value. Imagine there is a desktop application (for internal use) and a corresponding web ui (for external use). Then it might be a good idea to bundle multiple backend services in one YARP, to not need to define that in the two applications. But keep in mind - this means an entire new application, that needs to be maintained, deployed etc. versus adding maybe just a couple ! of different hostname to your used endpoints. (Seriously, how many web apis are you normally having in a project?) IF you do have many web apis being used by one frontend, you might think about splitting up that frontend into different business use cases, maybe module, components, whatever. So don't you get a big ball of mud in the YARP? You've spent so much time of thinking, guts and effort to separate things in the backend, just to pile them up in one service again.
If you have multiple front ends for different use cases, there is imho no sense in having the YARP. Imagine a cinema and there is a web ui for the customer to make reservations for a seat of a movie on a specific day. The second frontend is an app (web or desktop does not matter) to get booking statistics and forecasts. The intersection of those services are marginal and therefore a shared YARP would not make much sense. Actually this might be a security issue after all, because you probably don't want that statistic endpoints to be public (even when they are secured by authentification).
To sum things up: imho there is only one scenario (mulitple equal (from businessview) frontends using many backend services) and even then I personally think there are more downsides than advantages.
!! It depends on the requirements !!
The problem is more when we have a 1-1 (1 UI with 1 Service).