NameSilo

How do domains play in backend of mobile app?

Labeled as discuss in General Domain Discussion started by Kassey Lee, Nov 10, 2018.

Replies:
6
Views:
282

  1. Kassey Lee

    Kassey Lee 域名世界 VIP

    Posts:
    1,604
    Likes Received:
    4,982
    Just want to have some basic understanding of how domains are used in backend of mobile apps. As I have read somewhere, Progressive Web App (PWA) goes through the web, thus allowing analytics to analyze traffic but mobile app goes to http. Using Facebook.com as an example, how does the Facebook mobile app interact with Facebook.com? A rough idea will suffice. Thanks.
     
    The views expressed on this page by users and staff are their own, not those of NamePros.
  2. Paul Buonopane

    Paul Buonopane CTO, NamePros CTO VIP

    Posts:
    1,238
    Likes Received:
    2,064
    The process varies widely, but I'll explain a typical configuration--the same that Facebook uses.

    Networking is complicated, especially when we're talking about a network as large as the internet--the biggest network in existence. Network-base communication between devices is divided into seven layers in what's called the OSI model:
    1. Physical layer
    2. Data link layer
    3. Network layer
    4. Transport layer
    5. Session layer
    6. Presentation layer
    7. Application layer
    As we work our way toward higher layers, we move away from the physical hardware, such as wires, Wi-Fi, and 4G LTE, toward more abstract, more "friendly" protocols, like HTTP. At the lower layers, protocols are highly technical and involve working with raw 1's and 0's, if even that. At higher layers, we start to see more human-friendly concepts appear, like legible text.

    Typically, the purpose of the physical layer would be transferring data between two nearby devices: for example, getting data from your phone to a cell tower, and vice versa. At this layer, devices are typically identified by unfriendly numeric addresses, such as MAC addresses, which look like 00:14:a5:41:61:6b. These aren't very friendly or easy to remember, and they're only useful within a small logical area--to actually get data across the internet, information has to hop between many different devices located within numerous companies, each of which has a different physical address.

    This is where IP addresses come in. IP addresses are still unfriendly numbers, but they tell networking equipment were data is ultimately headed. A router at one ISP might know to send all IP addresses beginning with a certain sequence of digits to a specific router at another ISP, which gets the data closer to its final destination. Routers at different ISPs keep handing off the data to each other, passing it along until it reaches its intended destination. Each router only needs to worry about the next "hop"--who to hand the data to next--rather than needing to determine the entire path of the data. The routers know who their neighbors are--the other routers to which they're directly connected.

    Let's say you're sending a package from Boston to San Francisco. You write the address on the package--that's the IP address. You give it to a carrier--that's the ISP. They route it across the country, placing it on different vehicles along the way. It stops at several different facilities, each of which routes the package to a facility closer to its final destination. You, as the sender, don't have to worry about which facilities the package needs to travel through. The facilities themselves don't need to worry about the entire path, either; they just have to hand it off to someone closer.

    IP addresses, like street addresses, are quite handy, but they're not very friendly. I don't want to have to remember the address of each friend to whom I might ever send a package. I know them by name, and I use my address book to look up their street addresses whenever I need them. This is DNS: we, the users of computers, want to remember friendly names, like namepros.com. DNS acts as one giant, distributed address book: when I enter namepros.com into my computer, it looks in its address book to see if it knows the corresponding IP address. My computer's address book is pretty small, so it probably doesn't know. It then phones up a mutual friend who's a bit more pedantic about maintaining his address book--the DNS server.

    This is the essence of the internet: each individual device only knows contains a small amount of the information that exists on the internet. Whenever you try to access information that your computer doesn't have, it passes off your request to your ISP, who passes it off to another ISP, and so on.

    The primary purpose of a domain name is to be friendly to humans. They can serve other technical purposes, but friendliness and ease of memorization is why they were invented.

    Which brings us to apps: they don't have to use domain names. Domains are for humans; apps aren't humans. The programmers can easily stick a raw IP address in an app, and some do exactly that. However, it's usually more convenient to use a domain name for a variety of technical reasons.

    Mobile apps typically only deal with the uppermost layer, the application layer. They send data in a form that would be legible to a human, typically some kind of text. The mobile operating system is responsible for dealing with the other layers.

    HTTP is an increasingly common application layer protocol. Originally, it was designed for transmitting web pages. These days, it's used for all manner of data. As you interact with the Facebook app, it's sending and retrieving data in a similar manner to your web browser. There isn't really a technical reason for this; it's just that they already have the infrastructure for handling HTTP, so why reinvent the wheel?

    Progressive Web Apps (PWAs) are a bit different in that they're true websites--they're using HTTP exactly as intended. The phone displays them in a slimmed-down web browser; it'll typically remove the address bar and tabs from the interface, since they're not relevant. Otherwise, it's exactly the same as the native web browser app.

    Both PWAs and normal apps typically utilize HTTP, and both are capable of analytics. Native (normal) apps are theoretically capable of a higher level of analytics than PWAs, but, in practice, this rarely makes a difference, and the same analytics frameworks, like Google Analytics, are often used in both.

    The main advantages of a PWA:
    1. Lower development costs: rather than developing a website plus a separate app for each platform, you only need to develop an app.
    2. No need to download the app: since it's just a website, data is downloaded as the user interacts with the app, rather than all at once when the app is installed.
    Disadvantages of a PWA:
    1. Web-based interfaces are slower and use more battery than equivalent native apps. This is an inherent limitation of current web technologies. There are efforts to alleviate this, but it will be several years at least before consumers will benefit from such improvements.
    2. Non-native experience. Rather than matching the appearance of a native mobile app on each respective platform, the app will look the same on all devices. Users of a platform will expect certain buttons and controls to behave in a certain way; the web app may not follow all of their expectations. This makes it harder for less experienced users to interact with the app.
    3. The app will be slower to respond. Because data is downloaded as the user interacts with the app, each time the user taps something, more data has to download. This means there's a delay before the app responds to interactions, whereas a native app will appear to respond instantly. The delay can be minimized or even eliminated in certain cases, but, in practice, such optimizations are rare.
    4. PWAs will typically use more data. A native app downloads most of its resources when the app is installed, but a PWA is progressively requesting resources such as images as the user interacts with the app. Depending on the user's cell plan, this could be costly.
    Due to their limitations, as of writing, PWAs aren't particularly popular. There's a push from companies like Google to make this change, but other companies, such as Apple, are pushing strongly in the opposite direction.
     
  3. offthehandle

    offthehandle . Gold Account VIP

    Posts:
    4,558
    Likes Received:
    7,655
    What a nice well detailed response. Thank you Paul, very well written.

    Not sure if it exists, but It would be nice if there widely accepted and “open” trusted APP distribution platform that was similar to SourceForge, not controlled by either Apple or Google. Same with smartphones afaik there isn’t a “Linux”, open source alternative where we only have really only Android or iOS.
     
  4. Internet.Domains

    Internet.Domains Top Member VIP

    Posts:
    1,317
    Likes Received:
    3,054
    Apple is not pushing PWA's for several reasons. One, the hardware on devices that will be built for PWA's will be "lighter". Example being less drive space is needed. (Due to this it can also be argued battery life with devices built for PWA's may last longer). Apple is in the hardware business and PWA's are a threat to the hardware sector. Two, the app store is a major revenue generator. When clients no longer need to download apps in a store, and type a domain instead, Apple loses.

    Google and Microsoft are both behind the push for PWA's because they work on all devices including desktop. There is no need to develop for a particular device due to responsive customization.

    As far as speed, it was recently published that PWA's can load faster than a native app. In addition, user retention is increased by a PWA.

    Apple will be playing catch up if they can't capitalize on the PWA rush as end users are responding with the same enthusiasm as Google, Microsoft and many developers.
     
    Last edited: Nov 18, 2018
  5. Internet.Domains

    Internet.Domains Top Member VIP

    Posts:
    1,317
    Likes Received:
    3,054
    Domains are not used in the back end of a web app (PWA). The app is accessed through a domain and only a domain. Domains are the port of entry. There is no store or download required like its predecessor, traditional native apps.
     
  6. equity78

    equity78 Top Member TLDInvestors.com TheDomains Staff PRO Gold Account VIP ★★★★★★★★★★

    Posts:
    12,168
    Likes Received:
    9,354
    Great post, thanks for all the info.
     
  7. viniproject09

    viniproject09 Established Member

    Posts:
    225
    Likes Received:
    132
    Its means a Android device will eat more resources of physical hardware campare to Apple Iphone.
     

Want to reply or ask your own question?

It only takes a minute to sign up – and it's free!
Topics / Tags:

Share This Page

NameWorth
  1. NamePros uses cookies and similar technologies. By using this site, you are agreeing to our privacy policy, terms, and use of cookies.
    Dismiss Notice
Loading...