How local APIs, software libraries, and modules work together
Local APIs allow apps on any device to communicate with the hardware.
Local APIs are like the elves in the Harry Potter series — working hard to do everything, but always invisible. So, elves, err, I mean, local APIs allow apps on any device to communicate with the hardware.
Our devices are programmed in a standard method so they can behave in the way users desire. These ‘standard methods’ can be POSIX — Portable Operating System Interface, more on this later — which establishes a layer of communication that is standard across different operating systems. Or it can be SUS — POSIX, but for macOS.
Now, how do local APIs interact with software libraries and modules?
Let’s say you want to create a desktop application that displays weather data:
- Local APIs: You’ll use OS-level APIs (local APIs based on POSIX or SUS (for macOS)) to manage the application’s window, draw graphics on the screen, and potentially access networking APIs.
- Software Libraries: A graphics library might simplify drawing charts and visualizations of the weather. A networking library would help you fetch weather information from an online service.
- Software Modules: You could use a pre-built module that specifically handles formatting weather data in a visually appealing way.
So, local APIs provide an essential layer of communication with the device/system hardware. Software libraries and modules build upon the work done by local APIs to:
- Software libraries: To add a layer of convenience and higher-level functionality. Software libraries are collections of pre-written code that offer common functionalities across different applications. For example, Java’s standard libraries or Python’s NumPy.
- Software modules: To promote code organization and reusability. Modules are self-contained units of code with well-defined interfaces, often focused on a specific task or set of related functions. For example, modules within Node.js (npm) and Python (PyPI).
What is POSIX?
POSIX gives instructions on how an operating system should be written — how it should provide certain functionalities that are common across devices. Operating systems like Linux, macOS, and others strive to be POSIX-compliant (or partially compliant to POSIX and fully compliant to SUS, in the case of macOS).
When developers create applications, they use programming languages and libraries that are provided by a POSIX-compliant operating system, so that these libraries can interact with the operating system.