# Developing Microservice-Based Applications Using the Silvera Domain-Specific Language
## 3 Silvera
### Silvera Concrete Syntax
#### 3.3.1 Microservice Declaration  
In Listing 1, we show a simplified grammar rule for a microservice declaration. Some parts are omitted for brevity.  
```
1 ServiceDecl:
2'service'name=ID'{'
3('config_server' '='config_server=FQN)?
4('service_registry' '='service_registry=FQN)?
5(deployment=Deployment)?
6'communication_style' '='comm_style=CommunicationStyle
7(api=APIDDecl)?
8')'
9';
```  
**Listing 1**. An excerpt of the grammar rule for a microservice declaration.  
The ServiceDecl rule starts with the keyword service followed by the attribute name matched by the _textX_ built-in rule ID that further follows the literal string match \"[\" (line 2). The body of the microservice declaration starts with the definition of two optional variables. First, we have a variable that keeps reference towards the configuration server. Its definition starts with the config_server keyword followed by the literal string match \"=\", after which comes the attribute config_server matched by the rule FQN (line 3). Second, we have a similarly defined variable that keeps reference towards the service registry (line 4). Then the optional variable assignment matched by the rule Deployment (line 5) follows. Next, we have the definition of communication style CommunicationStyle (line 6). In the end, another optional attribute api is matched by the rule APIDDecl (line 7). The closing curly brace ends the microservice declaration.  
Listing 2 shows how to define a simple User microservice in Silvera. User microservice is registered within ServiceRegistry (line 3), and it communicates with the rest of the system by using RPC (line 4). This microservice is deployed inside a container, and it listens to HTTP requests on the 8080 HTTP port. Since the host attribute is not defined in the deployment section, its default value will be applied--http://localhost, accessed on 1 June 2022. The API of this microservice consists of the User domain object and several publicly available methods. CRUD methods for the User domain object are generated automatically due to the @crud annotation. This annotation represents a shortcut, and the same effect can be achieved by using @create, @read, @update, and @delete annotations. In addition to the CRUD methods, we have three additional methods listUsers, userExists, and u serEmail. All API methods for this microservice are exposed over REST. URL mapping for each of the methods will be auto-generated based on the microservice URL, method name, and HTTP method defined by the corresponding @rest annotation. For example, the method listUsers can be accessed with the following URL: http://localhost:8080/user/listusers, accessed on 1 June 2022. It is, however, possible to set custom URL mapping for the API method by using the mapping attribute of the annotation: @rest(method=GET,mapping=<user_defined_mapping>). This attribute, however, is not currently available when using CRUD annotations.  
```
1 serviceUser{
2
3 service_registry=ServiceRegistry
4 communication_style=rpc
5
6 deployment{
7 version=\"0.1\"
8 port=8080
9 host=container
10}
11
12 api{
13@crud
14 typedefUser[
15@idstrusername
16@requiredstrpassword
17@required@uniquestremail
18
19 intage//optional
20]
21
22@rest(method=GET)
23 list<User>listUsers()
24
25@rest(method=GET)
26 booluserExists(strusername)
27
28@rest(method=GET)
29 struserEmail(strusername)
30}
31}
```  
Listing 2: An example that shows how to define a service.