# Developing Microservice-Based Applications Using the Silvera Domain-Specific Language
## 3 Silvera
### Silvera Abstract Syntax
RPC-based communication is synchronous by default, but Silvera supports asynchronous RPC communication as well. Since microservices can fail at any time, MSAs must be designed to cope with failures [1]. The failure of one microservice should not take down the whole system. One of the design patterns that helps in mitigating such problems is the _Circuit Breaker_ pattern (see Section 2.2), which is directly supported in Silvera. Failure recovery must be defined for every API function that the _start_ microservice calls from the _end_ microservice. Table 9 shows failure recovery strategies supported by Silvera. When using a messaging-based communication style, microservices communicate asynchronously (via passing messages). Every message type (_Message_) used within the system is defined in the message pool (_MessagePool_). The Message pool is globally available and can be referenced from any module. Messages are delivered to their destinations by message brokers (_MessageBroker_). Every message broker contains one or more message channels (_MessageChannel_). The message broker creates message channels, and each channel can have multiple consumers and/or producers. The consumer is every microservice that reads messages from a channel. Analogously, the producer is a microservice that puts messages inside the channel. Message channels in Silvera are typed, which means that each channel is dedicated to a specific message type. Messages can only be consumed or produced by API methods. For a microservice to send a message, its API method must be registered as a publisher to a channel whose specific purpose is to communicate that kind of message. Likewise, to receive a message of a particular type, its API method must be registered as a consumer of a channel that contains a given message type. The method can be registered as a consumer with an _@consumer_ annotation and as a publisher with an _@producer_ annotation. The method can, at the same time, be both consumer and producer. \begin{table}
\begin{tabular}{l l} \hline \hline
**Strategy Name** & **Description** \\ \hline _fail\_fast_ & An exception will be raised in the client if an API call fails (default behavior) \\ \hline _fail\_silent_ & Returns an empty response \\ \hline _fallback\_static_ & Returns default values \\ \hline _fallback\_stubbed_ & Response is a compound object where each field has either a default value or a value determined from the request state \\ \hline _fallback\_cache_ & Returns a cached version of response if present, otherwise returns an empty response such as _fail\_silent_ \\ \hline _fallback\_method_ & Defines a method that will be called in case the original method fails \\ \hline \hline \end{tabular}
\end{table} 
Table 9: Failure recovery strategies supported by Silvera. Message channels are logical addresses in the messaging system; how they are actually implemented depends on the messaging system product and its implementation. In MSA, client applications usually need to collect data from more than one microservice. If the communication is direct, the client needs to communicate with multiple microservices to collect the data. Such communication is inefficient and increases the coupling between the client and the microservices [27]. An alternative is to implement an _API Gateway_. An API gateway represents a single entry point for all clients, and it can handle requests in one of two ways: (a) requests are routed to the appropriate service, and (b) requests are fanned out to multiple microservices. In Silvera, an API gateway is a special service implemented in the form of an _APIGateway_ object. Its attribute _gateway_for_ determines which microservices will be put behind the gateway. In the current implementation of Silvera, the API gateway only serves as a router of requests. In the future, we plan to expand on this implementation by providing security features, implementing the _API Composition_[27] pattern and adding the option to restrict services' APIs to a certain set of operations.