# Developing Microservice-Based Applications Using the Silvera Domain-Specific Language
## 3 Silvera
### Silvera Concrete Syntax
#### 3.3.2 Service Registry Declaration
By introducing a large number of new concepts, the language may become bloated which can significantly affect its learnability and maintainability. Still, adding support for a specific technology or framework on the compiler level is easier as code generators can be registered as plugins (see Section 3.4.3). ### The Built-In Code Generator

_Model-to-text transformations._ The built-in code generator (see Section 3.4.2) uses template-based model-to-text transformations to produce the Java applications based on the Spring Boot framework. A significant drawback of template-based code generation is that syntax checks can only be performed after generating a complete output file [12]. In addition, the generator does not have access to the structure of the generated code. This makes it impossible to apply transformations, e.g., instrumentation, to the generated code [32]. We chose the template-based approach because it allowed us to have a working code generator quickly. However, this is not the only approach. Users can use whatever approach suits their needs to implement generators and register them as plugins (see Section 3.4.3). _A feature not implemented for a target platform._ There is always a possibility that the built-in code generator does not cover some of the features available in the Spring Boot framework. In this case, users can expand the existing generator or implement a new code generator. ### Architecture Evaluation Metrics

Silvera uses specifically designed service-based systems metrics [46] to evaluate the modeled architecture. These metrics can be applied to microservices also [46]. To the best of our knowledge, these metrics have not been empirically evaluated across multiple industrial use-cases to determine if they are complete and appropriate for MSA. \(WSIC(S)\) and \(NVS(S)\) were evaluated in only one use-case but in the context of SOA [53]. \(AIS(S)\), \(ADS(S)\), and \(ACS(S)\) metrics roughly correspond to \"class coupling\" and \"object coupling\" metrics from the _Object-oriented programming_. There are several empirical studies where \"class coupling\" and \"object coupling\" metrics are evaluated [69]. Several other sets of metrics that were either designed for MSA or are applicable to the style [70; 71; 72] could be used during the evaluation. Additionally, experienced developers may disregard the evaluation results on purpose. For example, a microservice can depend on many other microservices because it contains the implementation of the main business logic. Developers may even invent their own set of metrics that are applied in their projects. To enable usage of a different set of evaluation metrics, Silvera allows developers to register custom AEPs as plugins (see Section 3.4.3). ### Unit Tests

Having unit tests is crucial when developing software. Writing or updating the unit tests can be tedious work if the microservice is frequently changed. In the current implementation, Silvera is not generating unit tests. By generating unit tests, Silvera could further reduce the need for manual intervention. ## 8 Conclusions and Future Work

In this paper, we have presented _Silvera_ --a domain-specific language for modeling distributed systems based on microservices. When creating Silvera, we had several goals in mind. The first goal was to provide a simple notation for writing microservice specifications that is easy to learn, use, and comprehend for both experienced and inexperienced developers. A simple but semantically rich notation would provide a faster way to develop MSA systems. The second goal was to support heterogeneous technology stacks. Our aim was to allow developers to use the best tool for the job and also encourage experimentation. Frequent changes in MSA systems often lead to obsolete documentation. Hence, our third goal was to provide automatic generation of documentation. Finally, our fourth goal was to provide a mechanism for users to evaluate the architecture of the created systems. We have accomplished our goals.