Interact in Service
When an order comes in, you need to inform the staff so that they can make ice cream, and when the ice cream is made, you need to notify the customer. Also, if the ice cream melts, you need to notify the customer again if they don't pick it up for a long time.
To achieve this, you need to add a service that sends periodic warnings if a served order is not finished, and a service that sends an alert message to the customer to remind them to pick up the order.
Declare Adapter
First, let's start by connecting an external API or module like an alert. You can connect an api that sends messages or emails, but in this tutorial, we'll create an api that simply prints to the console and connect it.
Modules like service, signal, document should not be directly connected to external systems, but rather created as adapters that are injected. First, let's create an adapter in the /srvkit folder with adapt(). An adapter gets its own logger as this.logger.
apps/koyo/srvkit/alarmApi.ts
Why use the adapter pattern? By injecting external dependencies as adapters rather than directly importing them in services, you gain several benefits:
(1) Testability - you can easily mock or replace the adapter in tests without modifying the service code
(2) Flexibility - you can swap implementations (e.g., switch from console logging to email notifications) without changing the service logic
(3) Separation of Concerns - the service focuses on business logic while adapters handle external interactions
(4) Reusability - the same adapter can be injected and shared across multiple services
Use External API
adapt() registers the adapter by itself, so there is nothing to add to option.ts. Inject it into icecreamOrderService with plug():
apps/koyo/lib/icecreamOrder/icecreamOrder.service.ts
Query in Document
A served order that nobody picks up should raise a warning. First give the document a query that selects orders by status, so the service can ask for the served ones.
Apply the query on the document.
apps/koyo/lib/icecreamOrder/icecreamOrder.document.ts
By declaring the byStatuses query in IcecreamOrderFilter, you can use list, find, count, exists, insight and other functions according to the given query conditions. For example, you can use listByStatuses, countByStatuses, and insightByStatuses functions. countByStatuses returns a number, and insightByStatuses returns db.IcecreamOrderInsight.
Why do we receive an array of statuses instead of a single status? This is useful when we need to query multiple statuses at once. If we think there is a possibility of querying multiple statuses, it is better to receive them as an array and process them.
Now add a service function that uses listByStatuses. For easy testing, it warns 15 seconds after the order was served.
apps/koyo/lib/icecreamOrder/icecreamOrder.service.ts
Use Interval
Now, let's use interval to execute the service every 10 seconds. The interval trigger is a trigger that works internally, and can be declared in IcecreamOrderInternal.
apps/koyo/lib/icecreamOrder/icecreamOrder.signal.ts
Now, you can see the warning message printed to the console if the order is served for more than 15 seconds.
Signal file is a file that declares triggers for executing service functions, and Signal has Internal, Endpoint, Slice classes.
Internal is a class that declares triggers for executing service functions, and has init, interval, cron, queue, etc. triggers.