As your company grows across different geographical regions, one way you can unify your business processes is by implementing a distributed application that talks to a central database. However, this approach requires you to break your application into two separate programs: server software and client software.
The server software should reside in a secure cloud environment such as Vultr's Cloud Compute, Bare Metal, or Vultr Managed Kubernetes (VKE). This is normally referred to as the backend. And in a data-oriented app, your backend must be tied to a relational database server such as MySQL or PostgreSQL. Cloud-based databases are more elastic, scalable, and can handle large workloads.
On the other hand, the client software is the frontend that runs on the users' computers or mobile devices. For instance, the Facebook app on your phone is a client application. You may design frontend apps using any modern programming language, including Java, C#, VB.Net, Swift, Android, and more.
The only major challenge that arises when designing distributed applications is the best approach to link the local client applications (for instance, mobile apps and desktop apps) to the server software(online databases). In this guide, you'll learn two different methods that you can implement as well as the pros and cons of each one of them.
One simple idea that comes into every new cloud-computing programmer's mind when connecting their application's backend to the cloud is changing the database connection string. For instance, if you've locally deployed an application that connects to a local MySQL instance, the database connection string might be similar to the following code snippet.
Server=localhost;Database=sample_database;user=sample_user;password=EXAMPLE_PASSWORD;
Now, to move your application's database to the cloud, you would simply spin up a cloud server, install a MySQL server and change the connection string to the following settings where example.com is the domain name of your cloud server.
Server=example.com;Database=sample_database;user=sample_user;password=EXAMPLE_PASSWORD;
The above approach should work pretty well, and you'd require changing minimal code in the clients' applications. However, it has the following disadvantages and should be avoided at all costs.
The direct connection method requires every copy of your software to have the database credentials hard-coded somewhere. Even if you may try to encrypt the connection string, a single breach of security or vulnerability will make your application worthless. If hackers manage to obtain the connection string, they can hack every user account in your application since they already have direct access to the central database.
Since distributed apps can be accessed by users in different geographic regions, the direct connection method requires you to open your database port to every host. This creates a very good avenue for bots, DDoS, and brute-force attacks.
Tight coupling. Since you've saved the connection string in every software copy that you distribute, a single change in the database credentials would mean locking out all users.
As you can see from the above disadvantages, the direct method for connecting distributed apps to cloud databases is not the best approach. In the next step, you'll see a more robust and almost fail-proof method.
An API stands for Application Programming Interface. This is a middleware that allows your frontend applications to talk to the backend applications in a secure manner.
The API layer should reside in a cloud infrastructure such as Vultr's cloud compute instance or VPS. Basically, the following is the basic procedure for migrating and connecting a distributed app to a cloud database via an API.
Sign up for a cloud computing account.
Then, spin up a Linux server. For instance, Ubuntu 20.04 is a good OS for cloud-computing beginners.
Next, install a database server in the Linux server. For instance, you can install MySQL or deploy a PostgreSQL database server.
Create a new database on your server and import data from your local database.
Next, create an API using your favorite scripting language—for instance, PHP, Golang, Python, and more. Refer to the following guides to learn the basics of creating an API.
Your API should support authentication, authorization, sorting, filtering, pagination, and custom fields selection.
Then, you should place your API source code in the root directory of your web server so that it can be publicly accessible via HTTP methods(GET, POST, PUT, and DELETE).
Next, redesign your application (for instance, desktop software or mobile app) to use the new API endpoints instead of the connection strings. Modern programming languages ship with different libraries that allow you to do this with minimal code. For instance, when coding your application with Android, you can use the Volley library. Similarly, for the .NET application, you can use the WebRequest class to make HTTP requests to your API endpoints.
A typical API endpoint looks like the following URL.
http://www.example.com/api/v1
Finally, publish your app with the new API settings.
The API connection method may take a longer time to implement. Also, it requires you to restructure your frontend apps fully. However, it has the following advantages.
The database credentials are only saved in the API layer. End-users should use their account credentials over HTTPS when connecting to the cloud application. This approach is more secure, and in case there is a man-in-the-middle attack, only a few user accounts are under threat and not the entire database.
Loose coupling. When using the API method, your application has 3 layers. That is, the frontend, the middleware (API), and the backend (database). This means that a change in a single component may not always affect the existence of other components.
Code reuse. The API method promotes code reuse. Multiple client applications can consume the API data. For instance, you can create a single API that connects your corporate portal, mobile apps, desktop applications, web-based software, and more to a central database. This means you'll only maintain one API endpoint, and this dramatically reduces your programming costs and the number of staff required to run your IT infrastructure.
After weighing up both methods, it is apparent that the API method wins and is always the recommended method. Also, large companies like Facebook and Twitter use the API approach since it is highly secure.
If your company is substantially growing to different geographic regions, you should consider designing and hosting distributed apps in the cloud. In the end, you'll have a resilient system that is more secure, stable, and most importantly, you'll have a central database for all your business processes.
For more information about creating a modern API, visit the following resources: