Will I hit a wall when developing?
Table of contents
- Extending all layers with your own code
- Expressiveness of the OutSystems visual language
- Avoiding the pitfalls of rapid application development
When people ask us this question, they have often just experienced our visual application development model or seen a demo and are concerned whether they will be able to include their own code. They worry that they will encounter platform limitations later in the development process that will prevent them from building enterprise-grade applications, designing rich and complex mobile and web user interfaces or integrating with the myriad of systems and databases that exist in their environment.
OutSystems is open by design to allow all layers of applications to be extended with your own code: front-end, back-end, database and integration. In addition, OutSystems offers an expressive visual language for developing your applications and avoiding rapid application development pitfalls.´
Extending all layers with your own code
This diagram shows the extensibility of OutSystems across all layers:
- Extending the back-end: Libraries, integration components and any custom code can be published and managed by OutSystems. Methods exposed by custom code are made available as visual elements in the OutSystems IDE and are an integral part of the application once it is deployed and run.
- Integrating external databases: OutSystems connects out-of-the-box to SQL Server, Oracle, MySQL and DB2. In addition, the database SDK can be used to implement a database connector to any database. An example of a connector built for PostgreSQL can be found on GitHub.
- Integrating to existing systems: OutSystems integrates out-of-the box with SAP and with other mission-critical systems through REST or SOAP. It is also possible to reuse existing integration components or build your own.
In OutSystems Forge, there is a repository of open source extensions, including wrappers to the overall public open source (or occasionally commercial) libraries or plugins, which are then reused as if they belong to OutSystems itself. Our strategy is to allow our community of developers to collaborate and continuously extend OutSystems with new reusable elements that end up supporting our entire customer base.
Expressiveness of the OutSystems visual language
In OutSystems, a visual Domain Specific Language is used to design business logic (write procedural code). This can be done at the page level (with full access to the scope of the page UI element) or users can define a set of methods/functions to reuse for pages and workflows.
Even though this is done visually and for several (mostly domain-driven) actions at a higher abstraction level, the visual DSL is built on top of the basic third generation language (3GL) programming elements (assignments, conditions, loops, exceptions and more). As a result, any kind of complex logic can be written visually. There is broad support from the IDE with a visual interactive debugger, visual merge and more.
Because enterprise applications are very data driven, the DSL also has a set of data-related elements and is expanded with data related actions as users include an external database model or define their own.
We also know that writing code reuses code frameworks and code snippets that are used to compose specific business needs. Therefore, the platform allows for several extension points at the visual DSL level.
Avoiding the pitfalls of rapid application development
The OutSystems architecture avoids the pitfalls of old fourth-generation language (4GL) technologies. The visual DSL was defined to be expressive enough for the broad scope of logic required for complex enterprise applications. It was also designed to be open and extensible, allowing developers to plug in custom code or pre-built extensions.