Getting started

Glossary

Ycodify Language, or YCL

One language capable of helping you to specify your data domain and, also, capable of defining the operation plan of our platform services to, by it, serve your application as a backend as a service (BaaS).

YCL Schema

An account in ycodify.com gives you, the Ycodify platform user, the chance to specify (or model) the data domain of your application. This specification (or model), at the end, is used as such and, also, as an operation plan for our platform to be able to deliver backend resources for your application.

We call this specification, or model, YCL Schema. This schema defines a set of data entities that completely describe the set of data that you can demand from the service, in addition to operation aspects that pass, for example, by employing distributed transactions between entities between different schemas, access control based on the tuple {user role, user} or authorization hash, concurrent access control to data, data representation class {relational, non-relational}, business rules injection, etc.

YCL Modeler

This is a tool of our platform, present in our web console, that helps you in the task of modeling (or specification) of the data domain of your application. Still under development, it can express more intuitively the information that is present in this domain by means of the use of diagrams such as ER, Class, and (our) Types (Typescript). These diagrams can be automatically generated from what is in the specification in text mode of your data domain, made with YCL, or it can be generated by means of the paradigm click-drag-drop.

Types (Typescript)

Once your model is diagrammed with YCL, either graphically or textually, you can automatically generate the Types, according to the Typescript language, and use them freely in your web applications.

Data Request Type of a YCL Schema

As requisições à base de dados oriunda da implantação de um Schema YCL implicam quatro tipos:

The requests to the database resulting from the implementation of a YCL Schema imply four types:

  • CREATE, whose use will result in the creation of one or more new data records in one or more entities of the schema;
  • READ, whose use will result in the list of data expression of the application of a query filter to the database represented by the schema;
  • UPDATE, whose use will result in the update of one or more data records in one or more entities of the schema;
  • DELETE, whose use will result in the removal of one or more data records already existing in one or more entities of the schema;

Schema Administrator Account

An account in ycodify.com gives you, the Ycodify platform user, the chance to specify (or model) the data domain of your application. This account, naturally, assumes the condition of being responsible for the creation and maintenance of all schemas specified in the platform by that account.

Application Administrator Account

This account can be created by you when creating a YCL Schema. Each schema created in the Ycodify platform, can have attached to it an account responsible for managing the data generated by the use of its application, not only the data but the creation and management of user accounts and user roles for your software application.

Application User Account

This account is identified as being the account of the users of our customers' applications. These accounts are created at the moment when the users of these applications register in the applications, automatically or manually, by the Backend Admin account, in the context of our web console.

YCL Engine

Represents a set of microservices responsible for performing the tasks related to the backend services available in the Ycodify platform, for your software applications, for example, performing the tasks of data persistence and recovery.

Ycodify Entry Point, or YEP

It is our universal entry point in the Ycodify platform, for all our customers. This entry point is given in the URL: https://api.ycodify.com/v0/baas/

Ycodify Project

In our web console, in order to specify a YCL Schema for your application, you will be requested before to create a Ycodify Project. To that project your schema will be permanently associated. Each project will have a schema associated with it, necessarily.

In addition, each project/schema will have associated with it two keys:

  • X-TenantID: in the headers of your HTTP requests, this key (and its respective value) must always exist. It will indicate to which schema the data of the payload of the request (body) is associated.

  • X-TenantAC: in the headers of your HTTP requests, if the service of authentication and authorization based on roles is not being used, this authorization key (and its respective value) must always exist. This key, in the absence of the JSON Web Token, serves to authorize the platform to perform the types of data requests (see Data Request Type of a YCL Schema, defined previously).

JSON Web Token, JWT

For our platform, this will be the token that carries the information that describes the username and its roles in the context of an Application/Schema YCL. It is obtained through the use of our services of user authentication, the Auth, based on the OAuth2.0 protocol. For this, the user who tries to perform the task of authentication, will need to have been registered through the ID service. The ID service can be used in a more friendly way in our console, in Dashboard > Project > Users & Roles. It can also be used by a set of endpoints in our API (see documentation).

Tenant

Here, a Tenant, is an instance of our customer's application in execution. Each instance needs to have and inform its existence through a Hash that is informed at the time of creating a project in our platform. See X-TenantID in the definition of Ycodify Project.

Previous
How it works