If you’re anything like me, you’ve spent an unhealthy amount of time perusing adorable cat GIFs on your phone, tablet, computer, tv and anything else that will let you get your fix of cuteness.
In addition to browsing cat GIFs on every device I own, I can also check my email, listen to my collection of music, chat with my friends and even write blog posts! On every device I own I can access the same emails, the same music, the same chats, and the same text documents.
In a world where seemingly everything is connected, it is almost unheard of for a web app to exist without an associated mobile app, and vice versa.
Build Once, Use Anywhere
To reach so many diverse platforms, it is crucial to initially develop with the “Build Once, Use Anywhere” mentality. What do I mean?
Let’s say you want to create a program that lets you browse adorable cat GIFs (if you do end up doing this, definitely let me know!). You decide you want to build a website and an iPhone app, but also want to be able to add iPad and Android apps in the future. To “build once, use anywhere” in this case means building one API that knows how to talk to all of the apps, current and future, that you create, rather than creating an API for each app.
API
An API allows one program to interact with another. In this case, you would create an API that communicates between your cat GIF storage and the mobile and web apps people are using to view and upload cat GIFs. So, let’s come up with a few API commands you’ll want:
- Create – Allows user to upload a GIF (Technical term: POST)
- Delete – Allows user to delete a GIF (Technical term: DELETE)
- Update – Allows user to change the name of a GIF (Technical term: PATCH)
For reference on the technical terms listed above, check out this article.
Now that we’ve defined our API commands, we need to create a way for apps to interact with the API. Both the device running the apps and the device running the API must be connected to the Internet. In this case, the API is part of a program that runs on a computer called a “server” which is connected to the internet.
Server
In computer science jargon, this project structure can be referred to as a “client-server model”, where one server (a program that runs your API) knows how to communicate with many clients (iPhone, Android, desktop, laptop, etc). If you want to learn more about the details of how a client-server model works, check out this article.
In reality, the server is just a computer in “the cloud,” which means it is just a computer connected to the open internet!
https://cdn.techterms.com/img/lg/client-server_model_1253.png
Storage
Now that your API connects your server with your apps, you need a database to store the cat GIFs that are uploaded. A database can either be hosted on a server of its own or the same server as the API. To keep it simple for this example, we’ll just say the database is hosted on the same server as the API.
The goal of the database is to keep it isolated so that only the web server framework running the API knows how to access the data. This keeps the data secure and abstracted in a way that only one device (the server) has to know how to access it instead of all the devices users have.
Takeaways
- If you’re looking to have a mobile app built, make sure the API is being developed with the “build once, use anywhere” mindset. This is one of the easiest money and time-saving decisions in modern programming.
- Whether you’re on a phone, tablet, computer or other device, if you’re using the same service (e.g. Google, Spotify, etc.) then you’re likely interacting with the same API to access that service on all devices!
- “Build Once, Use Anywhere” allows you to build the logic behind a service once and allow use of that logic from as many devices as you want (or can afford).
- If you build an awesome cat GIF app, make sure to let us know!
