@mazeltov/service v1.0.3

Services (DRAFT)

In the context of this repo, we are refering to the service layer that is often introduced into MVC patterns. Here is an example:

We all know that in MVC:

• The Controller is responsible to passing requested data to model
• Model operates business logic on entities
• Views represent the results/errors of the model or Controller

So where do things like sending an email fall in here?

What about caching results with a remote DB?

Usually the response is to put this logic into the Controller but it can create bloated and unmanageable code, so the best approach is to isolate into a Service and inject this into the Controller.

Another thing to consider is what happens if you tie all your caching/email to a third party API? What if this code is sprinkled everywhere in every controller. Injecting these things into the service and providing a unified API will allow easy changing of third party tools in the future.

This is Presently in Draft

Right now things are plenty isolated but could use reconsideration. For example:

• An email service
  • Could allow either an http api client or smtp client to be injected as driver
• A separate SMS service
  • If we think sendInBlue sucks for SMS we can inject other provider into this service
• A cache service
• Logging?

For each of the above we could use the abstract factory pattern to switch implementations

Each variety of service would share a common interface but could then branch on how it does its thing.

Why is this not pressing

This may become more important when:

• Various applicaitons use different drivers for sending emails, caching, sms