Organize into Parallel Projects Based on Separation of Concerns

Organize into Parallel Projects Based on Separation of Concerns
A key principles of software engineering is to architect a system into subprojects that can proceed independently. This article describes how
CA Live API Creator
helps your team organize into parallel projects, based on separation of concerns (SoC).
SoC provides important parallelization of development activities:
  • Proper client/server partitioning: Your business logic is properly partitioned to the server, where you can share it and can develop it in parallel with client application development.
  • Interface logic is independent of business logic: You can define resources in parallel with logic development.
The following image shows how
CA Live API Creator
addresses SoC:
In this article:
It is common for client applications to be burdened by providing services like pagination, optimistic locking, or generated key handling. These are properly partitioned to the API Server. Clients interact with service endpoints, which provide the following services:
  • Connectivity.
     Virtually all languages facilitate HTTP/RESTful APIs.
  • Resources that you explicitly define - the database-abstraction layer.
    CA Live API Creator
    facilitates client development through resources that you explicitly define. These resources select the correct columns, alias them, and join multiple objects together so they can be retrieved simply, in one trip. Since re-use of underlying logic is automatic, you can easily define multiple client-specific resources, while being assured of logic re-use.
    For more information about resources that you explicitly define, see Customize your API.
  • Object model.
     Some languages are built around objects. For example, Java Plain Old Java Objects (POJOs) and .NET Plain Old CLR Objects (POCOs). You can create these objects using Swagger SDKs.
    For more information of the JavaScript object model and logic re-use, see Row Objects.
  • Application partitioning (no "fat client").
     Effective applications depend on proper partitioning of logic between the client and server. This is often a source of architectural error, resulting in duplicated / inconsistent logic, poor performance, and unavailability of logic for non-interactive applications. The following services provide meaningfully improved re-use and reduced development time.
  • Pagination.
     Pagination breaks large result sets into page-size chunks, to ensure good performance. This is often part of client database-handling code. API Server provides pagination.
    For more information about pagination, see Architecture.
  • Optimistic locking.
     Optimistic Locking is a commonly accepted approach for increasing concurrency by enabling updates to unlocked data. This requires various mechanisms (timestamps, checksums etc) that often require client code. API Server provides optimistic locking.
    For more information about optimistic locking, see Performance.
  • Logic.
     While it is an anti-pattern, business logic for database integrity is often placed in client applications. This leads to poor performance (multiple trips), redundant / inconsistent code (due to replication), and inability to access logic (for example, for Web Services). API Server provides reactive logic, so that such logic is factored out of client, and significantly more concise.
    For more information about reactive logic, see Declare your Logic.
  • Security.
     Typical applications include substantial logic on the controller buttons to inject security filters into queries, for example, to ensure a sales rep sees only their own orders. Such logic is tedious and difficult to ensure compliance. API Server enforces role-based row/column-level access.
    For more information about security, see Security.
  • Primary key generation.
     Consider creating an order, with a set of line items. If the order has an automatically-generated key, the client could be forced into multiple server interactions:
    • Insert the order and obtain the generated key.
    • Insert the items, having placed the OrderID into each item.
    This is a lot to code, and performs poorly due to multiple server trips. API Server provides services for primary key generation. You define a resource that includes the related data and submit it. This partitions the logic to the server.
  • For more information about how API Server automatically generates primary keys, see Automatic Key Generation.
Service Endpoints
A non-trivial architectural challenge is where to place business logic. Is business logic placed in each service? Is it placed in underlying domain objects? 
CA Live API Creator
factors this logic out of the services. All requests automatically enforce your logic and security.
Reactive Logic
A typical first step for implementing business logic is to create an object model.
CA Live API Creator
creates that automatically.
For more information about the JavaScript object model, see Row Objects.
You can iterate your database with minimal effect on clients, since services hide the underlying data model. When the data model changes, you can verify your API.
CA Live API Creator
 rebuilds the object model and determines which services/logic require re-targeting.
For more information about how to verify APIs, see Database Connectivity.