Product documentation and training for Shipcode.
The Internet: Clients, Servers, and Requests
Understanding the relationship between a Client and a Server is the first step for responsible building in Shipcode.

The foundation of every digital experience is a simple, continuous communication pattern: asking for information and receiving a response. Understanding this exchange—the relationship between a Client and a Server—is the crucial first step for responsible building in Shipcode.

The Client-Server Exchange

At its heart, the internet is built on devices (Clients) asking powerful computers (Servers) for information. This continuous asking (Request) and providing (Response) forms the basic communication pattern for all online interaction.

  • The Client The Client is the device and software you use, such as your web browser or a mobile app (like the Instagram app). In Shipcode, the visual application you build—the user interface and interactive screens—is the Client side of the interaction. It is the part of the experience that initiates the conversation by sending a Request for data.
  • The Server The Server is a specialized computer that stores, processes, and serves information or services when requested. A Server manages services like a database or an API. In a Shipcode project, the external data sources or services you connect to (often called Integrations) act as the Server.

 

 

When you click a link, tap a button, or search for information (like a Google Search), your Client sends a Request across the internet to a Server. The Server processes that Request, retrieves the data, and sends a Response back to the Client. The response is the data, images, or confirmation that your application then displays.

Data's Journey: From Request to Response

The communication between the Client and Server is never instantaneous. When you interact with an application, your request travels from your device, across the internet, to a server, and back again.

This journey is orchestrated by the Internet Service Provider (ISP), which directs the Request from your Client through the internet backbone to the specific Server hosting the needed information. If a page loads slowly, it is often due to the time it takes for the Server to process the Request and send the full Response back to the Client.

Building with Shipcode: The Client's Bridge

 

Shipcode empowers you to build the visual user interface (the Client) and configure the Request and Response logic.

 

Your job as a builder is to design the visual elements and configure how your Shipcode project intelligently sends requests to, and processes data from, external services (Servers). Understanding this fundamental flow is key to building interactive, data-driven applications that perform efficiently.

Web Experiences vs. App Experiences

Despite their differences in how users access them, both web and app experiences are built on the same core Client-Server principle. Shipcode allows you to design user interfaces that can be deployed as both from a single project.

Web Experience

A Web Experience is platform independent, accessed directly through a standard web browser (like Chrome or Safari) and typically requires no separate installation. Application updates are immediate because they are deployed directly on the Server side, ensuring all users always access the latest version.

App Experience

An App Experience is device-specific, meaning the software is specifically designed for a particular operating system (like iOS or Android) and must be downloaded and installed from an app store. This approach allows the application to take full advantage of native device features such as the camera, GPS, or push notifications, and often offers more robust offline functionality.

Shared Foundations

Regardless of the deployment context, both experiences rely on the Client-Server model for data handling and use the core concepts of structure (HTML) and appearance (CSS) to render the visual elements. Shipcode provides the tools to create a unified design system that ensures shared components can be reused across both web and app contexts.

Did this answer your question?