# Getting Started
# Introduction
We provide GUI environment in our desktop software to make it easy due creating your API's or managing your databases without any line of code. Also we designed a sections for our built-in services.
Mobile / Web apps are meaningless without the data, processes, and systems that connect users with the information they need. But building those connections can be a challenge. As much as 50% of an app’s development time is spent on back-end services & integrations, slowing down time to market and cannibalizing developers’ time, and those integrations don’t always work the way they should.
Right-now every tech companies, agencies and developers around the world build and maintenance their back-end services by a lot of codes and integrations with external services for managing x\` assets and codes. Also build and maintenance back-end services always have too much costs for developers and companies in time and money. Hormo Studio built for solving these kind of problems that every developers has around back-end services and our technology will made whole process easy, fast and most cheaper.
We provide desktop enterprise software which helps developers and data scientist to design and build their back-end services like API’s and assets without any code. You can build your whole back-end services by your basic knowledges about models and databases in very short time and then your back-end services will be generated less than a few minutes for you based on your requirements of your project.
Follow the next step to figure out how our software works and then you can start your first project.
# How it works ?
We have core product for building models and database management. Every models has a lot of configurations and properties. Core product has a duty to do for two types of responsibility. First building and managing the models with needed configurations and second it should be generating services based on models design.
We provide GUI environment in our desktop software to make it easy due creating your models or managing your databases without any line of code. Also we designed a sections for our built-in services like API’S, Admin dashboard, Monitoring and so on in our software which helps developers to work with their services in our software. We bring these all services together in our application alongside of our core technology and this combination make it so fast to build your services easy and super fast. Here is our software screenshot to find out more about our software workspace environment.
We have workflow for building every project with our platform and workspace.
* **Models**: Design and Build your models based on your needs by configs and properties like designing your database. Each model has some configs and properties with a lot of options.
* **Configurations**: Before starting to checkout your services you should configure your services. Hormo Studio has some configurations in platform for managing databases and your whole services configurations.
* **Deliver Services**: After model definition, Hormo Studio will automatically generate the services for you. You can run your project now and start to test, manage, develop, and deploy your services.
# Create Project
To create your first project after installation you should press new project big button in the Hormo Studio intro window. after that you will reach to bellow page that force you to fill the project name and destination.
Destination would be your project resources and assets address in your computer. after named your project you all set to start your blank project. After that step we have an options to select your default model. Hormo Studio has built-in models which helps you to start your project based on our built-in models. For example if you want to create back-end for company website you can start with our company built-in model and then you just have to customize your models.
After that step you should wait sometimes to complete loading. At the end you will reach to the playground of your project page. To figured out how playground works and the tricks you should go to the next section ;)
# Playground
As you can see we have onboarding section contain your route and brief information about services as below:
We have toolbar includes stop and start buttons to **run your project**. In the center we have **status bar** which show your project state real time. Also settings page prepared for set your project configurations.
In side menu we separated core (models and databases) technologies and services. Almost the whole services generating every time based on your models modifications. for any modifications in core concepts you should restart your project.
{% content-ref url="/pages/-Lz7-hWHYOTp70BMwpBC" %}
[Models](/models)
{% endcontent-ref %}
# Models
Models are main core technology that make a lot of restful API endpoints based on properties, options. All services like docs and admin dashboard generating based on your models informations.
Before start your project and creating your models you have to prepare your models with their properties, validations or relations. Then you can create your own models by our GUI environment easily with lots of options and configurations for API's or admin dashboard.
So lets try your first model to figure out how our models works.
{% content-ref url="/pages/-Lz7-hWRtdZF8oWPi\_XN" %}
[Create model](/models/create-model)
{% endcontent-ref %}
# Create model
In models section first of all you are gonna have users model as default but you can customize this model by your own ideas simply. We will talk about specific [built-in user model](/models/built-in-user-model) in next articles. Before that we want to create new model from scratch and check out all properties and options behind that.
As you can see in top image by press on blue plus button you will create blank model. We have some fields at the top and list of properties at the bottom.
You have to design your models like creating your database tables and fields. for example every tables need some properties with configurations or relations. In our model designer each model have **Name, Type** and **database**. You have to configure and setup your database anytime and assign it to any model you want.
When you finished with your model informations you should press check button at top to save and publish your model.
At next step we have to know how model properties works.
# Properties
You can easily add new property or delete it by trash icon button anytime. You have to know about each prop and options and how they works with below tables and instruction.
There are several props you can fill for each field that we can describe them all at the below table
| Key | Required | Type | Description |
| ---------- | -------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| Name | yes | String | Name of your field |
| default | No | any\* | Default value for the property. The type must match that specified by `type`. |
| index | No | Boolean | Whether the property represents a column (field) that is a database index. |
| required | No | Boolean | Whether a value for the property is required. If true, then adding or updating a model instance requires a value for the property.Default is false. |
| type | Yes | String | Property type. Can be any type described in [Field Types](/models/field-types) |
| uiType | No | String | Choose your field ui component type described in UI Field Types |
| initial | No | Boolean | Property can be default column in admin dashboard model list |
| hidden | No | Boolean | Hidden model from admin dashboard |
| Validation | No | - | Set validations to the field. [validations instruction](/models/validations) |
| Relation | No | - | Set relation to the field. [relations instruction](/models/relations) |
# Field types
The following table summarizes Hormo Studio data types. Each property in your model should have data field type. for example when your property contains date or times you have to select date or DateString type for your property
| Type | Description | Example |
| ---------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| any | Any type, including array, object, Date, or GeoPoint | Any of: `true`, `123`, `"foo"`, `[ "one", 2, true ]` |
| array | JSON array | \[ “one”, 2, true ] |
| Boolean | JSON Boolean | true |
| buffer | Node.js [Buffer object](http://nodejs.org/api/buffer.html) | new Buffer(42); |
| date | JavaScript [Date object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date) | new Date(“December 17, 2003 03:24:00”); |
| GeoPoint | LoopBack GeoPoint | new GeoPoint({lat: 10.32424, lng: 5.84978}); |
| DateString | LoopBack DateString | "2000-01-01T00:00:00.000Z""2000-01-01"
"2000-01-01 12:00:00"
|
| null | JSON null | null |
| number | JSON number | 422 |
| Object | JSON object or any type | { “firstName”: “John”, “lastName”: “Smith”, “age”: 25 } |
| String | JSON string | “flashboard” |
{% content-ref url="/pages/-Lz7-hWWnPaqlAAQQk83" %}
[UI Types](/models/ui-types)
{% endcontent-ref %}
# UI Types
The following table summarizes Hormo Studio user interface component types for admin dashboard service. For example when you define a property by boolean field type you have to select boolean as your UI type to show switch button for this prop in your generated admin dashboard
| Type | Description |
| ------------ | -------------------------------------------------------------- |
| String | Displayed as a input text in the Admin UI |
| Boolean | Displayed as a checkbox in the Admin UI |
| Date | Displayed as a date picker in the Admin UI |
| DateTime | Displayed as a date and time picker in the Admin UI |
| Email | Displayed as a text field in the Admin UI |
| Money | Displayed as a number field in the Admin UI |
| Url | Displayed as a text field in the Admin UI. |
| Text | Displayed as a input text in the Admin UI |
| Textarea | Displayed as a textarea field in the Admin UI |
| Number | Displayed as a number field in the Admin UI |
| Password | Displayed as a password field in the Admin UI |
| Code | Displayed with CodeMirror in the Admin UI. |
| Color | Displayed as a text field with a color picker |
| Html | Displayed as a text field or WYSIWYG Editor in the Admin UI. |
| GeoPoint | Displayed as a combination of fields (lat,lng) in the Admin UI |
| Slider | Displayed as a slider component to pick value |
| Select | Displayed as a select field in the Admin UI |
| Relationship | Displayed as an auto-suggest field in the Admin UI |
| File | Displayed as a file upload field in the Admin UI |
{% hint style="warning" %}
If you are using File as ui admin type you have to set your field type to object because file responses are objects.
{% endhint %}
{% content-ref url="/pages/-Lz7-hWYL4Yz8AkU5wbu" %}
[Options](/models/options)
{% endcontent-ref %}
# Options
We have some kind of options for each model that you can set by checkboxes in the top section
| Property | Type | Description |
| ------------------ | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| validateUpsert | Boolean | Set this property to true to ensure that returns an error when validation fails. Set this property to false to prevent from calling any validators at all. |
| allowEternalTokens | Boolean | Allow access tokens that never expire. |
| Generate Id | Boolean | Prevent Clients from setting the auto-generated ID value manually. |
| Id injection | Boolean | Whether to automatically add an id property to the model. |
We have more options when you click on setting button for each property. Below modal shows additional options.
| Key | Required | Type | Description |
| ------------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| default | No | String | Default value is field name. |
| hidden | No | Boolean | Hidden model from admin dashboard and API. |
| defaultColumn | No | Boolean | Property can be default column in admin dashboard model list |
| Admin options | - | - | For each ui types you can set extra options based on your need. for example when you set your property ui type to slider we prepare range slider options you need and so on. |
{% content-ref url="/pages/-Lz7-hW\_mfzFz0uXqxPZ" %}
[Validations](/models/validations)
{% endcontent-ref %}
# Validations
Hormo Studio managing validations of your models so easily by set options as validations. Then your model props will be validate in restful API endpoints and also in your admin dashboard create or edit forms. When you click on validation configure button you can reach to the below popover.
The following table summarizes Hormo Studio validations for each model.
{% hint style="info" %}
We do not have required option for validation part because **initial** prop works like required validation which described on [properties](/models/properties)
{% endhint %}
| Key | Type | Descripion |
| ------- | ------- | ------------------------------------------------------------ |
| initial | Boolean | Whether the property is required. |
| pattern | String | Regular expression pattern that a string should match |
| max | Number | Maximum length for string types. |
| min | Number | Minimum length for string types. |
| length | Number | Maximum size of a specific type, for example for CHAR types. |
{% content-ref url="/pages/-Lz7-hWZqPdEeG2XAgE9" %}
[Relations](/models/relations)
{% endcontent-ref %}
# Relations
The `relations` key defines relationships between models. Hormo Studio managing relations in you back-end services by set options as relations configs easily as below:
| Key | Type | Description |
| ---------- | --------------- | ----------------------------------------------------------------------------------------------------------------- |
| foreignKey | String | Optional foreign key used to find related model instances. |
| ref(model) | String | Name of the related model. Required. |
| type | String | Relation type. Required
hasMany
hasManyThrough and belongsTo
|
| Filter | Object/Function | You can filter a relationship field using the filters option. `{ "type": "user" }` |
{% content-ref url="/pages/-Lz7-hWbuZz4HAVvUyuY" %}
[Built-in User model](/models/built-in-user-model)
{% endcontent-ref %}
# Built-in User model
The User model represents users of the application or API. You must create your own custom model (named something other than “User,” for example “Customer” or “Client”) that extends the built-in User model rather than use the built-in User model directly. The built-in User model provides a great deal of commonly-used functionality that you can use via your custom model.
Here is list of generated API endpoints for built-in user model as below:
| Method | URL | Description |
| ---------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------- |
| **PATCH** | **/Users** | Patch an existing model instance or insert a new one into the data source. |
| **GET** | **/Users** | Find all instances of the model matched by filter from the data source. |
| **PUT** | **/Users** | Replace an existing model instance or insert a new one into the data source. |
| **POST** | **/Users** | Create a new instance of the model and persist it into the data source |
| **PATCH** | **/Users/{id}** | Patch attributes for a model instance and persist it into the data source. |
| **GET** | **/Users/{id}** | Find a model instance by {{id}} from the data source. |
| **HEAD** | **/Users/{id}** | Check whether a model instance exists in the data source. |
| **PUT** | **/Users/{id}** | Replace attributes for a model instance and persist it into the data source. |
| **DELETE** | **/Users/{id}** | Delete a model instance by {{id}} from the data source. |
| **GET** | /Users/{id}/
accessTokens
| Queries accessTokens of User. |
| **POST** | /Users/{id}/
accessTokens
| Creates a new instance in accessTokens of this model. |
| **DELETE** | /Users/{id}/
accessTokens
| Deletes all accessTokens of this model. |
| **GET** | /Users/{id}/
accessTokens/{fk}
| Find a related item by id for accessTokens. |
| **PUT** | /Users/{id}/
accessTokens/{fk}
| Update a related item by id for accessTokens. |
| **DELETE** | /Users/{id}/
accessTokens/{fk}
| Delete a related item by id for accessTokens. |
| **GET** | /Users/{id}/
accessTokens/count
| Counts accessTokens of User. |
| **GET** | **/Users/{id}/exists** | Check whether a model instance exists in the data source. |
| **POST** | **/Users/{id}/replace** | Replace attributes for a model instance and persist it into the data source. |
| **POST** | **/Users/{id}/verify** | Trigger user's identity verification with configured verifyOptions |
| **POST** | **/Users/change-password** | Change a user's password. |
| **GET** | **/Users/change-stream** | Create a change stream. |
| **POST** | **/Users/change-stream** | Create a change stream. |
| **GET** | **/Users/confirm** | Confirm a user registration with identity verification token. |
| **GET** | **/Users/count** | Count instances of the model matched by where from the data source. |
| **GET** | **/Users/findOne** | Find first instance of the model matched by filter from the data source. |
| **POST** | **/Users/login** | Login a user with username/email and password. |
| **POST** | **/Users/logout** | Logout a user with access token. |
| **POST** | **/Users/replaceOrCreate** | Replace an existing model instance or insert a new one into the data source. |
| **POST** | **/Users/reset** | Reset password for a user with email. |
| **POST** | **/Users/reset-password** | Reset user's password via a password-reset token. |
| **POST** | **/Users/update** | Update instances of the model matched by {{where}} from the data source. |
| **POST** | **/Users/upsertWithWhere** | Update an existing model instance or insert a new one into the data source based on the where criteria. |
{% hint style="info" %}
Hormo Studio does not support multiple models based on the User model in a single application. That is, you cannot have more than one model derived from the built-in User model in a single app.
{% endhint %}
{% content-ref url="/pages/-Lz7-hWJNM1H5hEnV6BZ" %}
[Database](/database)
{% endcontent-ref %}
# Database
Any back-end services need database storages and Hormo Studio has almost whole databases type driver to connect your database to your models and projects.
First of all you have to prepare your requirement database on localhost or your server and then start out to connect your database by [instruction](/database/create-database).
For example when you want to store your data on mongodb you have to install and setup mongodb in your client and Hormo Studio not gonna handle or host your database by itself.
# Create Database
Hormo Studio models are connect to the backend services by databases via *data sources* that provide create, retrieve, update, and delete (CRUD) functions. Hormo Studio also generalizes other backend services, such as REST APIs, SOAP web services, storage services, and so on, as data sources. Data sources are backed by *connectors* that implement the data exchange logic using database drivers or other client APIs.
So let's start by connect your first database to your back-end services. Below is create database section in Hormo Studio:
As default we create memory type database for your models but you can connect another types of databases such as **mongodb, mysql, postgressql, oracle and redis** by fill out your database configurations**.**
As you can see in the picture we have to set some information to connect our database like **Name, Host address (localhost/server), Port, Username and Password** for your database security if exist.
When you click on check icon, your database gonna save to your Hormo Studio back-end services and you can assign your db to each model your want that we gonna explain that in next step.
{% content-ref url="/pages/-Lz7-hWc4wZ-e5UaEn9n" %}
[Connect to model](/database/connect-to-model)
{% endcontent-ref %}
# Connect to model
After create your database now you can set your db to any model you want in models section. If your database has any problem in connections, you should read the Haska logs to figure out the problem.
{% hint style="info" %}
Its so important that you make sure about your database connections and health and then connect it to your models
{% endhint %}
You almost finished with connecting your database. Now you can checkout how our generated services based on models works.
{% content-ref url="/pages/-Lz7-hWK7Z25t95gljBP" %}
[Restful API](/restful-api)
{% endcontent-ref %}
# Restful API
After designing your models you can run and test your project. We generate complete list of restful APIs based on your models properties automatically without any code.
Once you have defined a model, then you can use create, read, update, and delete (CRUD) operations to add data to the model, manipulate the data, and query it. All Hormo Studio models that are connected to persistent data stores (such as a database) automatically have the create, retrieve, update, and delete operations of the PersistedModel class
For each model we generate a lot of endpoints that you can make query for them and test your API's endpoints in our playground. Before start your restful API service you have to run project first.
Let's explore playground and learn how to works with that ;)
{% content-ref url="/pages/-Lz7-hWdVEQsmWiT40dK" %}
[Playground](/restful-api/playground)
{% endcontent-ref %}
# Playground
API playground has some sections that we should first know about them. As you can see in the below picture, We have set token access in the top and the list of whole generated endpoints API for each model. :
We will talk about [access token](/restful-api/access-token) and how you should work with that at the next steps. Let's focus on endpoints and as you can see we first generating whole CRUD endpoints and some extra endpoints for another purposes. You can reach whole generating endpoints and their duties, request and response status by overview of each endpoint in our playground.
For each endpoint you have some information as below image shown you can reach to request model data object and types and ability to send query and test your endpoint. We have filter option for your queries to reach to your specific data's in your database. We will explain more about how [filters](/restful-api/filters) works in next step
Try request your API's to figure out that you can reach to specific data's and make sure to everything with your endpoint responses and health before deploy on production.
{% hint style="info" %}
**POST** or **PUT** have to send data to them and in our playground you can just create your own object manually and try your test easily**.**
{% endhint %}
Let's try out random default endpoints and see what gonna be our result. Also you can set your desired parameter content type.
**Curl**
```
curl -X PUT --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{ \
"city": "London", \
"email": "test%40gmail.com", \
"name": "VT", \
"id": 1 \
}' 'http://127.0.0.1:8080/api/CoffeeShops'
```
**Request URL**
```
http://127.0.0.1:8080/api/CoffeeShops
```
**Response Body**
```
{
"city": "London",
"email": "test@gmail.com",
"name": "VT",
"id": 1
}
```
**Response Code**
```
200
```
**Response Headers**
```
{
"date": "Tue, 04 Sep 2018 10:09:51 GMT",
"x-content-type-options": "nosniff",
"etag": "W/\"3d-sUksLqWJj9l6vsFAgSc58jMxC18\"",
"x-download-options": "noopen",
"x-frame-options": "SAMEORIGIN",
"content-type": "application/json; charset=utf-8",
"access-control-allow-origin": "http://127.0.0.1:8080",
"access-control-allow-credentials": "true",
"strict-transport-security": "max-age=0; includeSubDomains",
"vary": "Origin, Accept-Encoding",
"content-length": "61",
"x-xss-protection": "1; mode=block",
"keep-alive": "timeout=38"
}
```
We send our requests by CURL and first of all you will see curl url in responses section. `Request Url` contains your endpoint address and you can try this url in other platforms too. Your response body contains response from server and you can see your `responses body` and `response code` right after send request. We also collect all your `response headers` at the end.
{% content-ref url="/pages/-Lz7-hWfOK5hoexEdjXR" %}
[Filters](/restful-api/filters)
{% endcontent-ref %}
# Filters
Hormo Studio supports a specific filter syntax: it’s a lot like SQL, but designed specifically to serialize safely without injection and to be native to JavaScript. The following table describes Hormo Stuiod's filter types:
| Filter type | Type | Description |
| ------------- | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| fields | Object, Array, or String | Specify fields to include in or exclude from the response. See [Fields filter](https://loopback.io/doc/en/lb2/Fields-filter.html). |
| include | String, Object, or Array | Include results from related models, for relations such as belongsTo and hasMany.
See Include filter.
|
| limit | Number | Limit the number of instances to return.
See Limit filter.
|
| order | String | Specify sort order: ascending or descending. See [Order filter](https://loopback.io/doc/en/lb2/Order-filter.html). |
| skip (offset) | Number | Skip the specified number of instances.See [Skip filter](https://loopback.io/doc/en/lb2/Skip-filter.html). |
| where | Object | Specify search criteria; similar to a WHERE clause in SQL. See [Where filter](https://loopback.io/doc/en/lb2/Where-filter.html). |
**Fields filter**
A *fields* filter specifies properties (fields) to include or exclude from the results.
```
filter[fields][_propertyName_]=&filter[fields][propertyName]=...
```
You can also use stringified JSON format in a REST query
## Include filter
An *include* filter enables you to include results from related models in a query, for example models that have belongsTo or hasMany relations, to optimize the number of requests. See [Creating model relations](/models/relations) for more information. The value of the include filter can be a string, an array, or an object.
`filter[include][`*`relatedModel`*`]=`*`propertyName`*
These examples assume a customer model with a hasMany relationship to a reviews model. Return all customers including their reviews:
```
/customers?filter[include]=reviews
```
Return all customers including their reviews which also includes the author:
```
/customers?filter[include][reviews]=author
```
Return all customers whose age is 21, including their reviews which also includes the author:
```
/customers?filter[include][reviews]=author&filter[where][age]=21
```
Return first two customers including their reviews which also includes the author
```
/customers?filter[include][reviews]=author&filter[limit]=2
```
Return all customers including their reviews and orders
```
/customers?filter[include]=reviews&filter[include]=orders
```
## Limit filter
A *limit* filter limits the number of records returned to the specified number (or less).
Return only the first five query results:
## Order filter
An *order* filter specifies how to sort the results: ascending (ASC) or descending (DESC) based on the specified property. Order by one property:
```
filter[order]=propertyName
```
Order by two or more properties:
```
filter[order][0]=propertyName &filter[order][1][propertyName]=...
```
Return the three loudest three weapons, sorted by the `audibleRange` property:
```
/weapons?filter[order]=audibleRange%20DESC&filter[limit]=3
```
## Skip filter
A skip filter omits the specified number of returned records. This is useful, for example, to paginate responses. Use `offset` as an alias for `skip`.
This REST request skips the first 50 records returned:
**Pagination Example** The following REST requests illustrate how to paginate a query result. Each request request returns ten records: the first returns the first ten, the second returns the 11th through the 20th, and so on…
```
/cars?filter[limit]=10&filter[skip]=0 /cars?filter[limit]=10&filter[skip]=10 /cars?filter[limit]=10&filter[skip]=20 ...
```
## Where filter
A *where* filter specifies a set of logical conditions to match, similar to a WHERE clause in a SQL query.
In the first form below, the condition is equivalence, that is, it tests whether *property* equals *value*. The second form below is for all other conditions.
```
filter[where][property]=value filter[where][property][op]=value
```
For example, if there is a cars model with an `odo` property, the following query finds instances where the `odo` is greater than 5000:
```
/cars?filter[where][odo][gt]=5000
```
For example, here is a query to find cars with `odo` is less than 30,000:
```
/cars?filter[where][odo][lt]=30000
```
Encode the large filter object as “stringified JSON.”
**Encode filter object as JSON**
```
http://localhost:3000/api/Books?filter={"where":{"or":[{"id":1},{"id":2},...,{"id":20"},{"id":21}]}}
```
## Operators
This table describes the operators available in “where” filters. See Examples below.
| Operator | Description |
| ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| = | Equivalence |
| and | Logical AND operator |
| or | Logical OR operator |
| gt, gte | Numerical greater than (>); greater than or equal (>=). Valid only for numerical and date values. |
| lt, lte | Numerical less than (<); less than or equal (<=). Valid only for numerical and date values.For geolocation values, the units are in miles by default. |
| between | True if the value is between the two specified values: greater than or equal to first value and less than or equal to second value. |
| inq, nin | In / not in an array of values. |
| near | For geolocations, return the closest points, sorted in order of distance. Use with `limit` to return the *n* closest points. |
| neq | Not equal (!=) |
| like, nlike | LIKE / NOT LIKE operators for use with regular expressions. The regular expression format depends on the backend data source. |
| ilike, nilike | ILIKE / NOT ILIKE operators for use with regular expressions. The regular expression format depends on the backend data source. |
| regexp | Regular expression. |
**AND and OR operators** \
Use the AND and OR operators to create compound logical filters based on simple where filter conditions, using the following syntax.
```
[where][][0]condition1&[where][]condition2...
```
Where *condition1* and *condition2* are a filter conditions.
**Regular expressions** \
You can use regular expressions in a where filter, with the following syntax. You can use a regular expression in a where clause for updates and deletes, as well as queries. Essentially, `regexp` is just like an operator in which you provide a regular expression value as the comparison value.
**Tip:** A regular expression value can also include one or more [flags](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions#Advanced_searching_with_flags). For example, append `/i` to the regular expression to perform a case-insensitive match.
Where `` can be a:
* String defining a regular expression (for example, `'^foo'` ).
* Regular expression literal (for example, `/^foo/` ).
* Regular expression object (for example, `new RegExp(/John/)`).
Or, in a simpler format:
```
{where: {property: }}}
```
Where `` can be a:
* Regular expression literal (for example, `/^foo/` ).
* Regular expression object (for example, `new RegExp(/John/)`).
For more information on JavaScript regular expressions, see [Regular Expressions (Mozilla Developer Network)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions).
```
filter[where][property][regexp]=expression
```
Where:
* *property* is the name of a property (field) in the model being queried.
* *expression* is the JavaScript regular expression string. See [Regular Expressions (Mozilla Developer Network)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions).
The following REST query returns all cars for which the model starts with a capital “T”::
```
/api/cars?filter[where][model][regexp]=^T
```
The following REST query returns all models that start with either an uppercase “T” or lowercase “t”:
```
/api/cars?filter[where][model][regexp]=/^t/i
```
Note that since the regular expression includes a flag, it is preceded by a slash (`/`).
## Examples
**Equivalence** Weapons with name M1911:
```
/weapons?filter[where][name]=M1911
```
Cars where carClass is “fullsize”:
```
/api/cars?filter[where][carClass]=fullsize
```
**gt and lt**
For example, the following query returns all instances of the employee model using a *where* filter that specifies a date property after (greater than) the specified date:
```
/employees?filter[where][date][gt]=2014-04-01T18:30:00.000Z
```
The top three weapons with a range over 900 meters:
```
/weapons?filter[where][effectiveRange][gt]=900&filter[limit]=3
```
Weapons with audibleRange less than 10:
```
/weapons?filter[where][audibleRange][lt]=10
```
**and / or** The following code is an example of using the “and” operator to find posts where the title is “My Post” and content is “Hello”.
```
?filter[where][and][0][title]=My%20Post&filter[where][and][1][content]=Hello
```
**between** Example of between operator:
```
filter[where][price][between][0]=0&filter[where][price][between][1]=7
```
**near** The `where..near` filter is different from other where filters: most where filters **limit** the number of records returned, whereas `near` **orders** them, making it more like a SQL `order by`clause. By combining it with `[limit](https://loopback.io/doc/en/lb2/Limit-filter.html)`, you can create a query to get, for example, the **three records nearest to a given location**. For example:
```
/locations?filter[where][geo][near]=153.536,-28.1&filter[limit]=3
```
**Inq** The inq operator checks whether the value of the specified property matches any of the values provided in an array. The general syntax is:
```
{where: { property: { inq: [val1, val2, ...]}}}
```
Where:
* *property* is the name of a property (field) in the model being queried.
* *val1, val2*, and so on, are literal values in an array.
Example of inq operator:
```
/medias?filter[where][keywords][inq]=foo&filter[where][keywords][inq]=bar
```
Or
```
?filter={"where": {"keywords": {"inq": ["foo", "bar"]}}}
```
{% content-ref url="/pages/-Lz7-hWemHrg01kb-0pu" %}
[Access Token](/restful-api/access-token)
{% endcontent-ref %}
# Access Token
If you enabled your authentication on your project you have to test your API endpoints by send authentication token to each request. We prepared token input in top of API playground as you can see below:
By built-in user generated API's you can get your token or manage your access tokens easily. Here are whole access token endpoint available in user model built-in endpoints\
\
**Quick reference**
| URI Pattern | HTTP Verb | Default Permission | Description | Arguments |
| ------------------------------- | --------- | ------------------ | -------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| `/accessTokens` | POST | Allow | Add access token instance and persist to data source. | JSON object (in request body) |
| `/accessTokens` | GET | Deny | Find instances of accessTokens that match specified filter. | One or more filters in query parameters:whereincludeorderlimitskip / offsetfields |
| `/accessTokens` | PUT | Deny | Update / insert access token instance and persist to data source. | JSON object (in request body) |
| `/accessTokens/`*`id`* | GET | Deny | Find access token by ID: Return data for the specified access token instance ID. | *id*, the access token instance ID (in URI path) |
| `/accessTokens/`*`id`* | PUT | Deny | Update attributes for specified access token ID and persist. | Query parameters:data - An object containing property name/value pairs*id* - The model id |
| `/accessTokens/`*`id`* | DELETE | Deny | Delete access token with specified instance ID. | *id*, access token ID (in URI path) |
| `/accessTokens/`*`id`*`/exists` | GET | Deny | Check instance existence: Return true if specified access token ID exists. | URI path:*id* - Model instance ID |
| `/accessTokens/count` | GET | Deny | Return the number of access token instances that matches specified where clause. | Where filter specified in query parameter |
| `/accessTokens/findOne` | GET | Deny | Find first access token instance that matches specified filter. | Same as Find matching instances. |
# Dashboard
Admin dashboard generating based on models definition to prepare place as back-end service for managing your data. After deploy your services you can serve your admin dashboard.
When you run and start your project in local or on your server you can reach to your automated served admin dashboard
{% hint style="info" %}
By default admin dashboard serve on port **`3006`** but you can change it in your exported codes or in Hormo Studio settings section.
{% endhint %}
When you start to enter dashboard you will see login page at the first. Default username and password for login are as below and you can change them in settings section for production.
* Username: `admin@hormo.studio`
* Password: `qwertyuiop`
{% hint style="info" %}
If you set your brand image in settings you will have your own brand in the admin dashboard user interface.
{% endhint %}
So after you login successfully, you gonna reach to admin dashboard overview which contains your models and data counts. lets figure out to work with data's at the next step.
{% content-ref url="/pages/-Lz7-hWgBGpD2moCNQrq" %}
[Usage](/dashboard/usage)
{% endcontent-ref %}
# Usage
When you reach to each model in admin dashboard like Users you will see whole data's table list in your services in user model. It works directly with your database connected resources.
In each list you can reach:
* Create new entry for your model by manually
* Update existing entries
* Delete specific entry
* Download data's as JSON and CSV file
* Search on your data's
* Add and manage list columns based on your model props
You can insert some new entries for test or manage whole data's behind your production services by Hormo Studio admin dashboard so simply as administrator. Also we have feature for having multi admin user in your admin dashboard. let's try in next step
{% content-ref url="/pages/-Lz7-hWhiSaoq2k3wdHt" %}
[Manage users](/dashboard/manage-users)
{% endcontent-ref %}
# Manage users
By Hotmo Studio admin dashboard you can having multi admin user by below instruction. Also you can manage your regular users by delete or modify their informations.
1. First go to User model section and click on create entry button
2\. Second fill out the form by new information and set type to Administrator. Then save that user to add new admin user to your collection
{% hint style="info" %}
Default user authentication for admin dashboard type is an admin and you should not remove that when you have not any admin type user.
{% endhint %}
{% content-ref url="/pages/-Lz7-hWj2Acw8IOMd2di" %}
[Change Authentication](/dashboard/change-authentication)
{% endcontent-ref %}
# Change Authentication
In settings page we have some configurations for admin dashboard tab. you can change your default authentication for admin dashboard from here. Also you can enable or disable authentication in your services by below switch button
{% content-ref url="/pages/-Lz7-hWL-SWWNxEhHEi7" %}
[Monitoring](/monitoring)
{% endcontent-ref %}
# Monitoring
We provide powerful monitoring system for each project that you built with our platform. You can monitoring your services like errors, progresses, CPU usages and several awesome reports.
We provide a lot of statistics and reports about your back-end services which helps you to having a vision to your services in GUI panel. A lot of useful information about your API's and so on
{% content-ref url="/pages/-Lz7-hWiBhtieCCMOlPM" %}
[List of reports](/monitoring/list-of-reports)
{% endcontent-ref %}
# List of reports
Hormo Studio monitoring and reports contains:
* **Summary** reports and overview contains total requests amount, CPU usage, Memory usage, Request rates and Apdex Score
* **Requests** section contains some reports and charts for your whole request status based on types, Errors By Method, Average Handle Time, Requests in processing live chart, Request Rate By Method live chart and Error Rate By Method**.**
* **Errors** section contains list of each errors which happened in your requests by internal and external users based on Errors by Status Code, Top 404 Not Found Path Count, Top 500 Internal Server Error Path Count and more.
* **Longest Requests** section contains list of whole requests which took time more than normal and helps you to improve your endpoints and models.
* **Rates & Durations** section contains the whole rate and durations reports for your requests and errors and live chart for requests and errors Rate Trend.
* **Payload** section contains your request and responses payload reports and rates and live chart for requests and responses payload.
* **API Calls** section contains list of your latest API requests which helps you to get sever detail information and statistics about each of requests.
* **API Operation Details** gives you easy access to filter your recent API calls with a lot of live charts and list of params.
Let's get start to learn how should handle your errors in monitoring ;)
{% content-ref url="/pages/-Lz7-hWkHAIfYYTqVYk4" %}
[Watch requests](/monitoring/watch-requests)
{% endcontent-ref %}
# Watch requests
**API Calls** section contains list of your latest API requests which helps you to get sever detail information and statistics about each of requests. By filter your each API calls and request you can reach to a lot of useful information and reports around specific request
Also we provide some extra chart contains:
* Handle Time Histogram chart shows requests handle time histogram based on mili second which gives you overview and vision in each month for any calls.
* Request Size Histogram chart shows requests size histogram based on bytes which gives you vision about your request sizes for optimization your models.
* Response Size Histogram chart shows responses size histogram based on bytes which gives you vision about your response sizes for optimization your models like request size chart.
* Response Codes: We collect each API calls responses code and show them as chart to get you vision about your errors and successful requests.
* Request Parameters: We provide list of parameters based on each request to inform you about API calls parameters which send to the endpoint.
Let's play with monitoring and reports sections to find out how amazing you can monitor you services and API's.
{% content-ref url="/pages/-Lz7-hWN9PUKIoVtJQfX" %}
[Documentation](/documentation)
{% endcontent-ref %}
# Documentation
Hormo Studio automatically generate documentation based on your API's and services. You can have an access to the documentations in your folder project and in your Hormo Studio project dashboard menu.
Every back-end services and rest-ful API' need documentations resource which client developers have to work with them. In rest-ful API service we had some brief description for each endpoint contains what our endpoints need as data and model and so on. In documentations service we create extra full documentations around any endpoint and schema Definitions as web page that you can export any time you want to share with your developers
Let's see how we can export our generated documentations in next step ;)
{% content-ref url="/pages/-Lz7OxS6p8cYRYwxSwLc" %}
[Export generated docs](/documentation/export-generated-docs)
{% endcontent-ref %}
# Export generated docs
At the end of project, after test and finalize your endpoints and services you have to share full documentation with your team-mates. Haska generate documentation as web page file which located in your project destination folder
In deployment process you can find out how to access your final project sources. When you creating new project you can set your project destination directory. So lets go to that directory that you selected before and you will see this structure directories as below:
So as you can see you have to share public folder which contains documentations web page and the other assets. before deploy you have to upload your own logo to set your desired image in each project services.
{% content-ref url="/pages/-Lz7-hWOyuyzGAbpoXFe" %}
[Deployment](/deployment)
{% endcontent-ref %}
# Deployment
Hormo Studio handle whole project in localhost environment until next version and we have instruction to deploy your project manually in your localhost and production.
When you finished with your back-end services and endpoints you have to start to deploy and test your project in production. At first for localhost or production environment you have to follow the manual instruction which shows as below in deployment section:
**Requirements**:
You just have to Install [node.js](https://nodejs.org/en/download/) for your desired client as requirement :) and also you have to setup your desired database in your client or server.
**Instructions**:
Go to your project directory which exist in deployment section by terminal.
```
$ cd HelloWorld
```
Install all dependencies for your whole services by:
```
$ npm install
```
{% hint style="warning" %}
You have to do second step in dashboard directory that exists in root project directory to install and setup admin dashboard dependencies.
{% endhint %}
To start rest-ful API services run below script in root directory:
```
$ node .
```
To start admin dashboard service run below script in dashboard directory:
```
$ npm start
```
Whole services after running your project gonna serve as below URL's:
**API BASE URL:**
```
HTTP://127.0.0.1:8000/api
```
**API EXPLORER URL:**
```
HTTP://127.0.0.1:8000/explorer
```
**ADMIN DASHBOARD URL:**
```
HTTP://127.0.0.1:3006
```
**MONITORING SYSTEM URL:**
```
HTTP://127.0.0.1:8080/swagger-status/ui
```
{% hint style="info" %}
Before deploy you have to setup your database and set your production database configs in your project locally and assign all models to production database
{% endhint %}
{% hint style="danger" %}
We don't support automation integrations in this version and you have to create your own deployment methods. We will support docker as automation tool as soon as possible.
{% endhint %}
# Licence
(The MIT License) Copyright (c) 2020 HORMO STUDIO LTD. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.