# Developing Microservice-Based Applications Using the Silvera Domain-Specific Language
## 3 Silvera
### Silvera Concrete Syntax
#### 3.3.2 Service Registry Declaration
_A service registry is not part of the model._ In this case, the service registry is inside another model or implemented manually. Microservices that are defined in the model where the service registry is not defined cannot be automatically registered within the service registry. Because of this, the code for the registration of the microservice needs to be added manually. _An API gateway is not part of the model._ In this case, the API gateway configuration needs to be updated manually in case of API changes of a microservice developed in Silvera. _Incomplete API gateway definition._ In this case, the API gateway and some microservices are in separate models, or some of them are implemented manually. Microservices that are defined in other models or manually are not visible to the API gateway. Because of this, the API gateway configuration needs to be updated manually in case of API changes. _Missing message definitions._ If there are multiple Silvera models or some microservices are implemented manually, each part of the system may have only a small subset of the complete message set. Due to Silvera's validation, it is impossible to define the message producer or consumer if the message is not defined within the model's message pool. Because of this, each message pool needs to be updated with the missing messages. Since each model has its own message pool, one team is in charge of one model/message pool. Teams could communicate which messages are used through the documentation. While this approach solves the problem of missing messages, it may create another problem where the same message, due to redundancy, needs to be updated in multiple message pools. While we have workarounds for the problems mentioned above, in the future, we plan to investigate how we can solve these problems systematically. For example, if the application is implemented via multiple Silvera models, we could add a mechanism for importing declarations (microservices, service registries, and others) from other models. This mechanism must work in cases where models are on remote machines and should not deteriorate the performance. ### Lack of IDE Support

DSLs are most effective when supported by specialized tooling including, but not limited to, an integrated development environment (IDE) with editors tailored for the language. Silvera currently lacks an IDE support. In case of complex models, this can significantly affect the user experience. Adding features such as auto-complete, go to definition, or documentation on hover for a programming language takes significant effort. Traditionally, this work had to be repeated for each development tool, as each tool provides different APIs for implementing the same feature. To support multiple IDEs, we plan to add support for the Language Server Protocol (LSP) (The Language Server Protocol--[[https://microsoft.github.io/language-server-protocol/overviews/lsp/overview/](https://microsoft.github.io/language-server-protocol/overviews/lsp/overview/)]([https://microsoft.github.io/language-server-protocol/overviews/lsp/overview/](https://microsoft.github.io/language-server-protocol/overviews/lsp/overview/)) (accessed on 18 May 2022)). The LSP standardizes the way in which a _language server_, which provides language data, and development tools communicate. For all _textX_-based DSLs, the language server is provided through _text-LS_ (textX-LS--[[https://github.com/textX/textX-LS](https://github.com/textX/textX-LS)]([https://github.com/textX/textX-LS](https://github.com/textX/textX-LS)) (accessed on 18 May 2022)) open-source project, and LSP support only needs to be added on the client side (text editor or IDE). ### Business Logic Not Part of the Model

Due to its pluggable compiler back-end, Silvera can support an arbitrary number of code generators. Each code generator can produce the code for a specific target language. This allows users to quickly switch the implementation of a microservice from one target language to another (e.g., from Java to Python).