# Developing Microservice-Based Applications Using the Silvera Domain-Specific Language
## 3 Silvera
### Silvera Concrete Syntax
#### 3.3.2 Service Registry Declaration
Since Silvera is IDE-independent, errors are detected only during the compilation time. Syntax errors are detected early on, during parsing, by _textX_, which comes with extensive error reporting and debugging support [52]. Before the _Model_ object is passed to the compiler's back-end, it is processed by the _communication resolving processor_ (CRP) and the _architecture evaluation processor_ (AEP). Since microservices created in Silvera can have multiple communication styles, the primary purpose of the CRP is to validate the Silvera model according to the corresponding communication style and enrich the model with communication-style-specific information needed by the compiler's back-end. Each communication style comes with a specific CRP. The purpose of the AEP is to provide a metrics-based evaluation of the microservices-based system implemented in Silvera. Evaluation metrics applicable to microservice-based systems are defined by [PERSON] et al. [46]. Even though the AEP is an independent module, by utilizing it in the front-end, we are implementing the _AVOPT_ pattern (see Section 3.1). This way, evaluation results can be used by the back-end to generate optimized applications. For the evaluation, the AEP is using the following metrics: _Weighted Service Interface Count (WSIC)_, _Number of Versions per Service (NVS)_, _Services Interdependence in the System (S1Y)_, _Absolute Importance of the Service (AIS)_, _Absolute Dependence of the Service (ADS)_, and _Absolute Criticality of the Service (ACS)_. \(WSIC(S)\)[53] is the number of exposed API functions of microservice \(S\). Lower values for \(WSIC\) are more favorable for the maintainability of a microservice. As absolute values for this metric are not conclusive on their own [46], the system-wide average \(WSIC_{AVG}\) is calculated. By comparing values with the average, the largest microservices in the system can be identified and potentially split. \(NVS(S)\)[53] is the number of versions of microservice \(S\) currently used in the system. A large \(NVS_{AVG}\) value indicates high complexity and bears down on the maintainability [46]. \(S1Y\)[54] is the number of microservice pairs that are bi-directionally dependent on each other. According to [54], interdependent pairs should be avoided as they attest to poor services' design. If such pairs exist, it can be a feasible solution to merge each of them into a single microservice [46]. \(AIS(S)\)[54] is the number of consumer microservices that depend on the microservice \(S\). \(AIS\) of every microservice is compared to a system-wide \(AIS_{AVG}\), which can be used to identify very important microservices in the system. \(ADS(S)\)[54] is the number of microservices that microservice \(S\) depends on. Again, \(ADS_{AVG}\) is calculated and can be used for comparison. \(ACS(S)\) combines \(AIS(S)\) and \(ADS(S)\) to find the most critical and potentially problematic parts of the system. According to [54], the most critical microservices are those that are called from many different clients as well as those that invoke a lot of other microservices. Evaluation is performed during the model compilation or on command (silvera ev aluate <path_to_model_dir>). At the end of the evaluation, the AEP creates a detailed report file that contains calculated values for each microservice. If needed, Silvera allows developers to register custom AEPs as plugins (see Section 3.4.3). #### 3.4.2 Back-End

After the front-end processes the _Model_ object, the object is being passed to the compiler's back end as an input. The back-end of the Silvera compiler iterates over each module in the model and passes declarations (_Decl_ objects) to code generators. The number of code generators is not limited. The Silvera compiler offers a possibility to register custom code generators as plugins. For every REST-based microservice, the back-end generates an OpenAPI document named openapi.json. OpenAPI files provide information about where to reach an API, which operations are available, what are the expected inputs and outputs, etc.