42 Big Frontend Building Cross PC Mobile Platform Applications Through One Cloud and Many Ends

42 Big Frontend Building Cross-PC Mobile Platform Applications Through One Cloud and Many Ends #

Hello, I am Ishikawa.

JavaScript nowadays is not only for web development but can also be used for back-end servers and even database-related development. In the previous lesson, we talked about “micro” front-end. Today, let’s take a look at the difference between “macro” front-end, a front-end driven development model, and the traditional development model, as well as how to use macro front-end to achieve all the development needs of the front-end and back-end.

Image

Frontend Applications #

First, let’s take a look at how we can meet the development needs of applications for different platforms in our familiar frontend development using the JavaScript language. Before discussing the solutions, let’s first look at several modes of mobile development and their advantages and disadvantages.

The first is native development. For example, for Apple applications, we usually use Swift for development, while for Android applications, we usually use Kotlin for development.

Native development has the following advantages:

  1. For end users, the experience will be smoother because during the process of downloading and installing the app package, the initial resource package is usually downloaded at once. Combined with the preprocessing of the loading process, this reduces the pressure of dynamic rendering.
  2. For developers, native apps have powerful development tools. From development to packaging to release, there is a mature end-to-end pipeline, unlike in web application development where various native support issues and browser compatibility issues need to be dealt with.

However, this development model also has its drawbacks. One of the more obvious ones is that during the development process, developers need to simultaneously master three languages: Swift, Kotlin, and JavaScript. In addition, there are tasks like testing and application store review. It can be said that the workload is multiplied, so the development of all three platforms is usually done by different teams.

The second is web applications. For web applications, programs run in the browser.

Web applications have the following advantages:

  1. They greatly reduce the amount of memory space needed on users’ phones.
  2. They avoid the problem of certain app stores not supporting the app. When users need to access related applications, they only need to open the browser and enter the relevant app address to browse the information.
  3. For developers, they greatly avoid the lengthy application store review process, shortening the development and release cycles.

Of course, web applications also have their disadvantages:

  1. In terms of end user experience, the experience of web applications is inferior to that of native apps. After all, the rendering of browsers still cannot match the smooth experience of native apps.
  2. In terms of user experience, users need to enter the app address to access the relevant app. Although web applications also support generating shortcuts on the desktop or bookmarks in mobile browsers, users do not have the habit of using them. Therefore, for apps with high user stickiness and frequency of use, web applications are not that suitable.
  3. For brands, giving users a trustworthy experience, a downloadable native app looks more reliable than a web application that can only be accessed through a URL. The third type is hybrid development mode. In hybrid development mode, as the name suggests, the app itself is published in a native way, but it embeds web applications to varying degrees.

First of all, let’s talk about the advantages:

  1. In this development mode, the app looks more native, after all, it is published through a native shell in the app store.
  2. In this development mode, content updates become easier because the internal application is actually a dynamically loaded web application under the shell of a native application. This means that “hot updates” can be adopted during updates, without the need to package, re-audit, and publish the application again.

Of course, there are also related issues:

  1. App stores are not foolish. If everyone only creates a shell and publishes it to the app store, then the review mechanism becomes meaningless. Therefore, usually, an application cannot pass the review if the native part is below a certain proportion.
  2. Even if it passes the review, the user experience will be relatively poor because the app itself is an application that calls a browser to render a web application internally. This experience is usually lower than that of native applications and may even be worse than accessing the web application directly in the browser. Therefore, this method is definitely not suitable for developing applications, especially games.

So, are there any solutions to solve the above problems in development?

In the early days, front-end developers attempted to replace native applications with Progressive Web Apps (PWA). The concept of PWA was proposed at Google’s I/O conference in 2016. Its core concept is to improve user stickiness, increase responsiveness, and enhance the reliability of offline messages through a series of technical implementations based on web applications.

To give users a more native-like experience, Notification/Web Push API, Web Manifest, Service Worker, and other features are used. These features allow web applications to implement message push, create desktop applications and offline functions. However, although PWA has sparked great enthusiasm in the developer community, it has not been widely accepted by end users. For the majority of mobile and tablet users, people still prefer to download native apps. However, on desktop computers, most users have formed the habit of using browsers and avoiding native apps as much as possible.

Since it is impossible to change user habits through development-driven approaches, developers have switched to another approach, which is how to choose JavaScript as the development language while maintaining the native experience.

At that time, React Native, launched by Meta in the same period, gradually became popular in 2015. It allows developers to develop iOS, Android, and web applications, as well as Android-based TV applications using the same JavaScript codebase. In other words, developers no longer need to learn several languages to do mobile development. Of course, as React Native became popular, development modes based on React Native for Windows and macOS applications also emerged.

So, in the same period, Electron, launched in 2013, also gained popularity. Developers can develop desktop applications for Linux based on Windows and macOS applications. Later, with the emergence of mini-apps, there was also uni-app based on Vue.js in China, which supports native and web applications, as well as mini-apps.

Web Services #

After discussing the frontend, let’s take a look at the middleware layer.

Typically, our website needs a web application framework to create frontend pages and provide relevant data for frontend rendering. In order to achieve this goal, the core functionality that a web application needs to support is routing, middleware, and template engine.

The purpose of routing is to parse the user’s requested URL and determine which page to serve. Middleware is responsible for processing the frontend request, providing feedback, and calling the next middleware in the chain. The template engine is used to render pages based on pre-defined HTML templates and variable parameters. Currently, the popular web server-side framework is Express.js, which can fulfill the core functionalities mentioned above.

At the same time, if we further explore the functionalities of middleware, we will find several core sub-functionalities that are needed:

  1. As a service provider, in addition to building pages in the middleware layer, we also need to provide APIs that adapt to different frontend platforms, supporting multiple platforms based on different requirements.
  2. When dealing with different types of databases or backend systems under the middleware layer, a layer of aggregation is needed to transform data formats to meet the needs of the frontend.
  3. From a security perspective, API creation requires a series of authentication processes.

To meet these requirements, a related platform is usually required on the server-side to provide the necessary functionalities. For example, Apollo Server is a platform that can be combined with Express.js to provide similar services.

Data Storage and Query #

We have discussed front-end applications, middleware, and web service APIs. Now, to create a complete web application system, we need to consider data storage and query.

First, we need a database to store the data generated by the front end. Databases can be roughly divided into two categories: relational databases (RDBMS) and non-relational databases (NoSQL). In server-side JavaScript, there is MongoDB, which is a file-like non-relational database implemented using the JS engine SpiderMonkey. With MongoDB, we can store the data generated and relied on by the application. It is well-suited for web application development because it naturally stores data in a JSON-like format.

In front-end development, when we want to query information from a database, we need to use a query language. In traditional query languages, especially in relational databases, we typically use a query format like “select from” to receive a table. GraphQL, on the other hand, is a query language and return format that is more like JSON or object literals.

In other words, its usage aligns better with our intuition in front-end development. GraphQL was developed in 2012 as an internal project at Meta and was later announced publicly in 2015. In 2018, it moved from Meta to an independent organization for management.

GraphQL has several key features:

  1. From its usage of JSON, we can see that GraphQL is a query language that is more suitable for API services. It is a runtime that uses existing data to complete these queries. GraphQL provides a complete and easy-to-understand description of the data structure in the API, allowing the client to accurately express the objects they want to query.
  2. Another key feature of GraphQL is that it utilizes the type system mentioned earlier in JavaScript type checking. This allows for better definition and specification of data types for input and output.
  3. In traditional REST APIs, we sometimes need multiple requests to retrieve complete information. With GraphQL, we can include all the required information in one response, greatly reducing the need for repeated requests.

In traditional development, disagreements between front-end and back-end are common. One major reason is that it is difficult for the back-end to think from the perspective of the front-end and provide data that is more oriented towards business objects. In situations where data serves the business, it is important to ensure the specification of the type system. Additionally, it is important to reduce the number of requests and increase the efficiency of each service call. Under the concept of the “big front end,” all system designs serve the front-end users. In this business-driven model, it can drive the back-end to better meet the requirements of front-end development.

Summary #

From the study of this lecture, we can see that we can almost complete everything from frontend application development to server-side and API development, to backend data storage and querying using JavaScript and related tools.

When it comes to data storage and querying, we can identify two key terms: JSON and GraphQL. JSON, as a data storage structure, is used in frontend-driven development to empower the implementation of business data objects and logic. On the other hand, the emergence of GraphQL is more in line with the querying of data generated in a network environment, which is often non-linear and web-like. In this regard, GraphQL is different from traditional, formal, tabular data querying methods. Therefore, the emergence of the big frontend can better serve the interaction and business needs of the frontend by improving the storage and retrieval methods of data.

Thought Question #

Today, we mentioned the concept of “大前端” (Da Qian Du), or “The Big Front End”, and discussed its core advantages, which include more efficient API and data usage for front-end users and business needs. However, its advantages go beyond this aspect. From another perspective, by utilizing JavaScript as a core technology, it can also meet the development requirements of front-end, middle-end, and back-end. In other words, it plays a role in reducing costs and increasing efficiency.

However, besides these advantages, can you think of any other strengths or weaknesses of “大前端”?

Feel free to share your insights, exchange learning experiences, or ask questions in the comments section. If you find today’s content helpful, you are also welcome to share it with more friends. See you in the next class!