iPaaS for Mobile Developers
Thinking of building the next big mobile application? In this article, we take a look at how an iPaaS solution can be effectively used in mobile development.
Join the DZone community and get the full member experience.Join For Free
Thinking of building the next big mobile application? The time to market of a mobile application is critical in the current fast-paced industry. Deciding if it’s an Android or an iOS application is just one part of the problem. Most of today’s applications need a backend system to carry out their operations. Features like remote data storage/syncing, authentication, and user communication require a set of backend services to be available.
So, how can we develop these backend systems for mobile applications? There are two main patterns for doing this. The first is to do direct integration.
In this approach, the mobile application directly communicates to a web server, which hosts a set of web services that serve the required requests. This is good enough for simple applications, where all the business logic is independent of other external services, and the functionality is self-contained. But what if we have many other external services that are required for functions in the mobile app? This is where we use the mediated pattern for mobile development.
A mediation layer can effectively perform typical operations that are required when integrating with multiple services, such as data mapping, routing, and transformation. In today’s cloud computing shift, almost all mainstream functions are available as software as a service (SaaS) products. There are services from messaging, databases, to identity management that are provided as cloud services.
If most of the services integrated are available in the cloud, the next logical step would be to provide the mediation layer functionality in the cloud as well. This is where an integration platform as a service (iPaaS) comes into play. An iPaaS can effectively integrate cloud and on-premises services with hybrid cloud features, in order to provide front-end mobile applications clean API interfaces to work with.
Let’s take a deeper look at the typical requirements of a modern iPaaS in relation to mobile application development.
In mobile development, the most often used approach for communication is JSON over HTTP. So, it’s essential that an iPaaS has rich support for JSON data handling, validation, and transformation capabilities. Also, HTTP/2 support is a plus when providing full-duplex persistent connections, which allows us to do much more efficient concurrent request handling, which results in lower latency for applications. Alongside HTTP APIs, support for API definitions is critical with technology such as OpenAPI. This way, an API can be properly described for applications to use.
WebSocket is a communication protocol that allows us to have full-duplex communication using a TCP connection. This is used mainly in a web application context, where an established HTTP connection is used to upgrade itself to a WebSocket connection. Afterward, the client and the server can perform bi-directional communication without the overhead of the HTTP protocol. Practically, in the context of mobile application development, if the mobile application is based on a web browser technology, WebSocket will be essential in having efficient communication with the server.
Server-Side Events (SSE)
In the case where we cannot use WebSocket effectively, for example, due to usage complexities in load balancing and HTTP proxy servers, and if the majority of the events are occurring from the server to the client, SSE is an option for providing a server-side notification mechanism.
This has the benefit over polling mechanisms, where multiple messages will be sent over a single established connection, compared to dedicated requests and HTTP header overhead incurred in other approaches. In SSE, the client to server communication will still be done with general HTTP requests, given that these requests are not as high in frequency compared to server-push events. This is a critical use case in mobile development as well and should be supported in an iPaaS geared towards supporting this communication pattern.
WebHooks are basically used as a callback mechanism for remote APIs. This is not for communication between a mobile application and a server, but rather for services integrated into the backend system with other external systems. For example, for checking for updates in your issue tracking system, or to get notified when someone edits your document; these events will be notified to the backend using WebHooks, and these messages can be forwarded to the mobile application. In modern services, WebHooks is an often-used technology in implementing a callback mechanism, and thus, should be supported in an iPaaS.
If OpenAPI is for synchronous HTTP APIs, AsyncAPI is for event-driven communication. AsyncAPI fulfills the requirement of the long-standing void of defining the messaging endpoints, protocols, and message schemas in a formal manner. Thus, alongside the supported event-based communication mechanism supported in an iPaaS, AsyncAPI should be supported as well to advertise their capabilities.
In a mobile application, responsiveness is critical to have a good user experience. In the event of a user action triggering a network request, the response should be expected in a reasonable amount of time. So, we must make sure the network request payload is as small as possible, and, more importantly, the number of requests themselves must be kept to a minimum. A network request is mainly expensive due to the network round-trip time it takes; so we must make sure this overhead is as small as possible.
The above scenario is solved with GraphQL. GraphQL allows you to model all the data you need to expose as a single object-graph structure. And the GraphQL query language can be used to craft a single query, which extracts data from multiple points from the object graph. Applications do not have to execute multiple queries, but rather, can fetch all the data in a single query. Also, it makes sure we get only the data fields we require in a query, thus avoiding the over-fetching scenario we see in typical data services.
Some legacy services can still be using technologies such as XML data sets and SOAP WS-* standards-based communication. So, it’s important to support these protocols and data formats also in our mediation layer.
A graphical modeling system is desirable in a rapid development environment. This enforces self-documenting integration flows, where the graphical user interface represents a clear picture of the operations that are defined. This approach also reduces common bugs and inefficiencies that people may experience in a code-only environment. It especially attracts novice developers, who would prefer to work on a higher abstraction, compared to low-level code. Overall, this results in better productivity for all developers.
Low-code development itself has its own downsides. Sometimes direct code can be more productive due to its flexibility in customizing your logic. You may want to add a custom validation logic or a complex transformation with custom rules. These are best implemented in code. This may not arise often, but when it comes up, it can become a blocker or considerable amount of work in a low-code/no-code only environment. A possible solution is to provide a hybrid solution of having a low-code and a code solution at the same time for the developer. Developers can choose to select the mode they are working in and do the switch accordingly; this way, we have the best of both worlds.
AI-Based Developer Assistance
Many integrations and codes we write contain certain patterns we often follow. By looking at existing integrations and user behavior, we can assist the developer in helping complete programming operations.
- Data Mapping: The platform can help developers quickly do data mapping operations by understanding source and target data schemas. This will save much time in manual data transformation and conversion operations.
- Smart Connections: Offer connectors in a toolkit that is compatible at a certain stage in an integration flow. This allows the user to quickly and easily discover which connectors are compatible in a certain scenario. After selecting a compatible connector, possible data mapping operations can be automatically presented to the user by the system.
- Performance Analyzer: Provide development-time performance predictions on the integration flows to understand the performance characteristics of future executions and make necessary adjustments as required. This allows developers to make decisions that were not possible earlier until a solution is put into production.
- Predictive Maintenance: By analyzing observability data, alert the users on possible impending failures, performance degradations, etc. In the case of detected issues, provide possible causes and suggestions for the developers to quickly diagnose and fix the issues.
Integration Patterns and Templates
There are certain integration flows that naturally occur more frequently. Due to this, developers will end up creating much similar integration flows in their projects. We can eliminate this situation by providing developers templates of frequently used and compatible integration scenarios. This allows developers to concentrate on simply providing a set of parameters to a template and adding any additional customizations as and when needed.
This approach will make sure that developers get instant solutions to work with and will not be wasting time re-implementing a scenario that was already implemented earlier. Also, this makes sure these templates are well tested and already used in production by many others.
This is a critical aspect in managing your software development process and resulting artifacts. A proper governance process makes sure that the code and other artifacts are tracked properly with a version control system, and that the exposed services are managed and tracked properly in a centralized manner.
An API management system should be available for creating managed APIs which fronts the internal integration flows and other external services used by the system. We make sure the available APIs are properly documented and discoverable by any front-end applications. Also, this allows further operations such as API monitoring, throttling, and security policies to be defined and engaged from a centralized location.
In this article, we looked at the requirements of typical mobile application development—specifically regarding handling backend business logic. The usage of an iPaaS greatly reduces the burden put on the front-end developer by providing a mediation layer to integrate and orchestrate the typical operations that need to be carried out.
Published at DZone with permission of Anjana Fernando. See the original article here.
Opinions expressed by DZone contributors are their own.