Most apps bring value by giving access to the Internet and providing the user with real-time feedback on their questions and actions. Few, if any, enterprise apps are standalone and don’t require Internet connection. Those are just mere displays for static information. This is the reason why it is worth thinking about the backend and APIs to enrich enterprise app functionality.
Understanding the Dark World of the Backend
For an app developer, the backend can be intimidating since it requires a different set of skills to deal with servers and databases which are governed by cryptography and security rules. When working with Big Data, there are even more requirements, like those related to handling the Hadoop framework.
Delegate to Server
Since mobile devices have limited resources compared to servers, it’s best to move all the computational work to a powerful machine and only communicate the result to the user. For the developer, this helps to build the app for different platforms and just integrate it at the end.
Plan for Offline Back-up
Users can have low signal problems or no Internet connection at all while using the app. A well-designed piece of software can create local back-ups of data and resync with the server once a link is available. In case the app works with Big Data, it is essential that the volume of data stored offline is not larger than the device’s capacity.
Address Synchronization Issues
In Big Data projects, due to the “velocity” dimension, synchronization drives quality and helps to solve data conflicts. The rule of thumb is to give priority to the latest version of a dataset based on a timestamp and ensure time zone differences are addressed.
The in-house experts in enterprise mobile app development from Itranstion stated that sync for mobile apps should take into consideration the inherent limitations of devices, such as battery life, cost of data transfer and signal power. Also, the operation should only be performed when certain thresholds are met to avoid power drainage during sync or losing signal.
Selecting the Right Query Tool: SQL vs. NoSQL
In the last 40 years, SQL became the standard when it comes to database query since it allows numerous interrogations of the same information set, adapted to the user’s needs. It has a long history, and it is already integrated into multiple tools. This is a relational tool, and the main downside is that it scales vertically by adding more resources to the server.
On the other hand, NoSQL has become popular due to Big Data and Internet giants like Facebook and LinkedIn. NoSQL is excellent for flexibility, as it has no fixed schema behind it, but can just evolve and get new properties as needed. It was designed for semi-structured data; thus, it can be easily scaled horizontally by distributing data across servers.
SQL is declarative, the only thing the user need to do is to ask for the right information, and it will get it in the form already existing in the system. By contrast, NoSQL, as a procedural query, demands from the user to specify the final type of the answer. Since in the procedural approach the programmer has to redesign the system each time, it is more costly and less user-friendly.
To overcome this problem, there are SQL implementations that can query HDFS systems, apart from Hive, which was the original query tool of Hadoop.
Fixing Security Issues
It’s true an app is as secure as its code, but it’s also as secure as its backend, sometimes entirely controlled by the vendor. A recent study has shown that over 43TB of enterprise data coming from over 1,000 apps were exposed and prone to personal data theft. This problem was nicknamed “The Hospital Gown” vulnerability. The problem is made worse by the fact that companies can’t detect a breach until it’s too late, as signaled by ransomware and phishing tentative.
The report highlighted that the primary problem was the lack of security items between the vendor of the data storage and the Internet, although there were proper firewalls set between the app and the data storage.
Solutions to Security Issues
The first step is to create an inventory of all the apps used in your company and the permissions each has. A simple spreadsheet will do. Update to the latest versions and remove all apps that are no longer necessary.
Secondly, make sure you agree with your vendors on the way your data is stored and protected. It’s mandatory that the backend is secured, and the information encrypted using the latest standards. Lastly, make sure that the data from the server is recent and has not been compromised.
Is Backend as a Service (BaaS) a Viable Solution?
If the developer doesn’t want to deal with the problems posed by the backend, BaaS means that you outsource the implementation and connect to the environment provided by the vendor through APIs and SDKs. In this case, you delegate entirely the responsibility for architecture, speed and security to your vendor to give you time to focus on your core abilities.
The good news is that most of these services are built on the freemium model, and you can scale as you grow your own client base. On the downside, BaaS can limit your options and offer too low customization options. The recent case of Parse discontinuing its services is also a noteworthy alarm sign. Switching providers can be costly, involve redesign, possible downtime and client loss.
Final Thoughts
Building a fast, secure and reliable enterprise mobile app requires more than design and UI/UX skills. The powerhouse able to process Big Data is the backend, which should be built for scalability, following best practices of security and data protection. The architecture must address the query type, synchronization issues and be adapted to accommodate different types of data, including semi-structured and unstructured ones.
Due to the sensitive nature of enterprise information, data security should be on top of the developer’s priority list. Blind trust in the vendors’ systems can have unwanted consequences.
Top comments (1)
The most fundamental challenge is to actually have all that data. It's much harder than it seems.