# Developing Microservice-Based Applications Using the Silvera Domain-Specific Language
## 3 Silvera
### Silvera Concrete Syntax
#### 3.3.2 Service Registry Declaration
However, business logic in the case of specific API methods still needs to be implemented manually. Since this is performed on the code level, these changes are not visible on the model level. There are two approaches that we can take to allow the definition of the business logic in the model. First, we could expand Silvera with _action language_--an imperative language used for action definitions. This language should support the usual constructs such as declarations, statements, and expressions. A conventional critique of DSLs is that they require the redesign of such things as statements and expressions, which is hard to get right and complete [32]. Second, we could provide an option to _embed_ the code of the target language in the model. This would give complete access to the full expressivity of the target language but would also hamper portability between different target languages. ### Additional Microservice Design Patterns

In Section 2.2, we descibed most MSA design patterns currently implemented in Silvera. However, the number of implemented design patterns can be increased. In this section, we will discuss the patterns that are arguably missing. _Security._ Although there are many advantages of using MSA in developing distributed systems, security is still one of the biggest challenges [65]. However, several important security properties emerge as side effects of microservice design [66]: (i) microservices usually have a smaller code base, which leads to a smaller attack surface, (ii) malicious changes introduced by an attacker to a specific microservice instance are unlikely to persist past redeployment, if microservice is immutable, (iii) microservices only access the data and services they need, which limits the damage should an individual service be compromised, and (iv) heterogeneity of technologies protects microservices against low-level exploitation. Still, the following security practices are implemented in the industry [66]: (i) Mutual Transport Layer Security (MTLS) with a self-hosted Public Key Infrastructure (PKI) as a method to protect all internal service-to-service communication, and (ii) Security tokens for local authentication. Currently, Silvera generates a code where these practices need to be implemented manually. Users can mitigate this by overriding a built-in code generator or registering a new one; however, we plan to expand Silvera to generate a code with all existing security best practices. _Data management._ Transactions that span multiple microservices need to be implemented manually. This comes as a direct consequence of the inability to express the business logic in Silvera models (see Section 7.3). Once the business logic becomes part of the model, we can implement the support for design patterns such as Saga [30] and Command Query Responsibility Segregation (CQRS) [27], and API composer [27]. Additionally, microservices are designed to be stateless. Stateless microservices facilitate autonomy and isolation. However, distributed applications usually must maintain a global state (as shown by [67]). How a DSL can be used to negotiate a global state and reach a consensus in MSA is shown in [68]. ### Expanding Silvera

A DSL does not attempt to address all types of computational problems, not even large classes of problems from a particular domain [32]. A DSL is very expressive for the problems that fall in the domain and cannot be used for other problems. The language may be inadequate even for the problems that are on the edge of the domain. This gray area typically puts pressure on the DSL to grow beyond its (original) domain [32]. It is challenging to anticipate the set of concepts needed over the lifetime of a programming language since these concepts are often dependent on the new platforms that programs must interact with. Silvera is designed in a way that allows it to grow over time to accommodate the needs of the domain of MSA. New modeling concepts can be added by expanding the grammar and the compiler. However, this can also be a problem.