Hello to all! I'm Seok Heo, a web service developer at LINE. I'd like to introduce you to LINE's various web-based services and their architecture, technology stack, and development methodologies in this post. To simplify things, I've classified LINE's web-based services into web services, hybrid web apps, messenger, and library/platform.
Overview of each service category
Web service
LINE offers LINE Timeline Web as a web service.
LINE Timeline Web
LINE Timeline Web is a social service where you can share your stories with text, photos, and videos or check out stories of your friends. It is a global service provided in seven languages.
The following image on the right shows a page where you can write your stories. You can send a sticker, share a link, and create animations out of text messages. What you create here will be shown exactly the same on both mobile and web.
You will find technology stacks and methodologies used in the development of LINE Timeline Web below. Timeline Web is developed with Java Script. React or Redux are used to manage different types of views. Node.js and Express are used to provide WAS (Web Application Server) for SSR (Server-Side Rendering). We adopted SSR since it is essential to show the first page as quickly as possible and deliver good search engine exposure, given Timeline's characteristic as a SNS.
The following slide shows the refactoring steps we went through during Timeline Web development. Unlike other projects, refactoring process was quite long for Timeline Web. The initial version was developed with ES5 Vanilla JS. Techniques for JS module management and bundling evolved as time passed by, and Timeline Web project appeared to become legacy code. That's when we went for the first round of refactoring, using RequireJS for AMD (Asynchronous Module Definition) module formats. It was maintained for some time until frameworks such as React and Vue.js became more common and mature enough for service. Then, we went for the second round of refactoring with React. With this second round of refactoring, React version enabled us to improve inefficiencies in the existing Vanilla JS version web apps such as reusability of modules and consistency in status management. The third round of refactoring was for adopting Node.js. We were able to lay foundation for SSR as the team directly managed Node.js, and implemented SEO (Search Engine Optimization ) and improved the Time to Interactive (TTI) metric.
If LINE's front-end development team was reluctant to adopt new technologies, Timeline Web would have not been maintained as it has been or the team must have had suffered the agony of developing with the legacy code.
Hybrid web app
Next are hybrid web apps including LINE Search, LINE More tab and LINE Chat app.
LINE Search
The first one on the list is LINE Search, which provides a search on data used in LINE messenger. Currently, LINE search covers external web search such as news, matome (Japanese Internet jargon for saving logs on web pages) and influencers, and internal data such as friends, chat history, official accounts, stickers and themes.
This project is unique as it used both Vanilla JS and Vue.js framework and adopted an event-driven development approach. There is also an interactive interface, enabling communications between webview and the native application.
LINE as a global service provider should be able to offer a good performance even with poor network performance. LINE Search is composed of the 'entry page' to enter a search keyword and 'search result page' to show the search results. Like in other services, our focus was to provide rendering as fast as possible for the entry page. To this end, we created the entry page with Vanilla JS so that users did not have to stand by until the framework bundling file was fully downloaded. As the search result page needs to show various forms of components, we used the Vue.js framework. In addition, we created a separate bundle file for the entry page and search result page, and the bundle file for the search result page was designed to be loaded after downloading all of java script, CSS and image files required for the rendering of the entry page and completing asynchronous network work.
Conventional wisdom is to use async or defer for asynchronous loading of JS files. However, we couldn't control the timing with either of the two attributes (Reference). Instead of simply delaying the loading or evaluation of the JS file until the completion of HTML parsing, we wanted to wait until the rendering of the entry page was completed. As a resolution, we implemented an asynchronous loader to load the resource files at a specific timing for current service.
As we separated the bundle files from the initial stage, there was an issue where the search would be executed even before the Vue.js framework was loaded if a user entered a keyword. We added a queue between the entry page and search result page so that search would be executed only after the search result page is fully loaded.
In addition, the entry page and search result page have different context (or state). The entry page is implemented in plain Vanilla JS while the search result page uses Vuex. We implemented an interface called event bus between these two different context to communicate and share information. Event bus interface is also used for communications between webview and the native application.
LINE More tab and LINE Chat app
The following image shows the more tab among LINE messenger's tabs. You can access various menu from here including settings, profile and call. Many of these features are serviced through web app: Sticker Shop, Theme Shop, LINE Game, LINE Pay and etc. There was no web app only 5 years ago. But, now web app provides more menus than the native application.
Web app also provides various features in LINE Chat app such as poll, schedule, ladder game and more.
Messenger
LINE started its business with an instant messenger. It is only natural for LINE to have an instant messenger on every platform including web. LINE's mission statement is "Closing the distance" between people so we think communications should be enabled on any platform.
LINE Chrome messenger
LINE has a Chrome extension for its messenger with the following technology stack.
We used Marionette as a backbone framework to implement view. Recently most use either React or Vue.js. Let me further elaborate why we chose to use a relatively older technology in detail. Indexed DB was adopted to save conversations between users, images and configurations in clients, and Apache Thrift was used for communications with the server.
LINE puts emphasis on security. Despite using HTTPS for secure communication, we encrypt HTTP body again to protect data packets from main-in-the-middle (MITM) attacks. We also adopted end-to-end encryption (E2EE) so that no one but communicating users could read the messages. Not even LINE admins can read those conversations. LINE's web-based messenger pursues "once source multi-platform", and the internally developed obfuscation tool is used to prevent an unauthorized analysis of the source code.
Timeline of LINE's web-based messenger
LINE's web-based messenger has evolved over a few years, undergoing significant transformations.
Firefox OS
The first of its kind was for Firefox OS. In early 2014, LINE with the web technology was launched for Firefox OS in Spain and some of Latin American countries. Back then, it had to run on a low-specification terminal with about 1GHz CPU and 128MB RAM. We had to decrease the size of the resources as much as possible. Still, we decided against using Vanilla JS due to some difficulties and adopted the backbone framework. Out of 128MB RAM, the available memory of the application was less than a half, given the memory allocated for the OS. Once, the service crashed as users sent and received photos and RAM usage went up to 80MB. We analyzed and implemented optimizations for the next version, limiting the memory usage up to 40MB even for sending and receiving photos. This was a project that we focused on making it light-weight and optimized.
Chrome app
The next step we took was a Chrome app. We've built the basics with the LINE app for FireFox OS and saw a hint of success. With Chrome platform, we implemented and serviced the messenger with all features we dreamed of. In 2015, we launched LINE messenger with almost full range of features including sticker shop, sending stickers or rich messages with voice or video, screen capture and pin code authentication.
Tizen
In 2016, we migrated the Chrome app to Tizen platform. Tizen, just like Firefox, was also a low-specification device priced at less than KRW 100,000. Despite such limitations, we have put in a lot of effort to further improve the performance. We've done tens of times of prototyping to provide smooth and seamless UX even for users with thousands of friends on their friend list. Another point we focused on was to provide the same features including screen activity, physical keyboard actions and push notifications as the native app in the mobile environment. The Chrome app was successfully migrated and preloaded on Tizen in such a short period of time.
Chrome extension
In mid-2018, Google changed its policy and ended the service and support for Chrome applications in the Chrome app store. That's why we launched the Chrome extension version of LINE web messenger. This was a much easier path as it was converting a Google Chrome application into a Chrome extension. We still had to develop some APIs in the Chrome app version that were not supported by Chrome extension.
Browser
Toward the end of 2018, we needed a pure web-based messenger to manage LINE's Official Accounts. At first, we started discussing about using the existing Chrome version as a starting point for easier and quicker development. However, as it was on the backbone framework, its codes and concepts were already considered as legacy, and we concluded that it was counterproductive for future service and potential expansion. In the end, we decided to reuse core modules including the network module for transferring conversations, database module for saving or looking up conversations in the client and business logic for handling various events, and use Vue.js for the refactoring of the presentation layer. We were able to relatively quickly and successfully complete the project.
I think it was possible to support such various platforms with single source code because it was web.
Code obfuscation
Portability is one of the advantages of web-based services, but it is known to be susceptible to security risks. As I mentioned earlier, LINE puts an emphasis on security. So, we planned to apply code obfuscation. Commercially available code obfuscators do not obfuscate properties in objects, member variable of prototypes or methods. This didn't meet LINE's standard on security so we ended up developing our own obfuscator tool called "ENIL". ENIL is LINE written backwards.
The main goal of ENIL was to obfuscate the codes enough so that people could not easily read the codes. In other words, our mission was to put attackers in misery when they tried to understand the codes and their mechanism. As shown in the image above, we used barcode-looking unicode for the substitution of codes so that attackers wouldn't even dare to analyze our codes.
Library & platform
Next is about library and platform.
LINE Social Plugin
LINE Social Plugin offers a library to add buttons like "Share via LINE", "Like" or "Friend Request" on personal pages.
Usually, it is difficult to forecast for this type of service how much traffic is going to be generated from which websites. Say, it generated only a little traffic today, but it could be applied to a high traffic service just the next day. We had to be as efficient as possible.
In addition, this service can be vulnerable to clickjacking, a malicious technique of tricking a user into performing undesired actions by clicking on a concealed link for advertisements or product sales. Abusers use various forms of clickjacking such as making a button transparent, tempting with a gift or hiding a button behind the play button for media. However, protection against clickjacking is evolving day by day (I'll write about past clickjacking cases on LINE Social Plugin and how we countered those attacks.)
LINE web app architecture
Now I'll explain about LINE's hybrid web app architecture. LINE develops many services as a web app. Here let me explain how these services are being operated. LINE's web apps can be classified into LCS (LINE Channel SDK) and LIFF (LINE Frontend Framework).
LINE Channel SDK
LINE Channel SDK (LCS) is developed with Apache Cordova, formerly known as PhoneGap. Cordova enables access to various features on a device. LCS provides the social graph information of LINE users including user environment, ID of chat rooms, geographical information and friend information on top of what Cordova offers. LCS also enables LINE messenger app's system service such as beacon and ultrasound to be used on web. Webview used by LCS does not take up the entire screen, and some are implemented with the native SDK. There is an interface to control such native areas in webview. As of now, apps developed with LCS are mostly internally developed at LINE. Only a few authorized external developers can use LCS for development.
LINE Frontend Framework
LIFF or LINE Frontend Framework is a framework built purely for webview development without direct interaction with the native application unlike LCS. There are quite many open APIs by LINE. You can use these APIs to obtain a social graph or send a message to friends.
Please visit the LINE Developer site and find relevant documentations including Getting started. You can create your own web application and run it on LINE.
LINE's web development technology stack
The following image shows the list of web development technology stack at LINE.
Java script in blue is surely at the top of the list. LINE also invests its resources in recently popular frameworks such as React or Vue.js and deepening its understanding of Vanilla JS with ES6, ECMAScript and TypeScript. Those in red indicate network technology with an emphasis on the fundamentals of network and backend technology. LINE developed its own WAS with Node.js for proprietary development of SSR and adopted PM2 for the management of Node.js instances. Many enabling technologies are represented in green. You can also see ESLint for static code analysis and Prettier for code formatter.
LINE's web development methodologies
Here is a list of development methodologies adopted at LINE.
Mos of web services or web apps are developed as a SPA (Single Page Application) with Vue.js or React. SSR is used with Node.js, if necessary. LINE also has the 'continuous deployment system with PM2'. We also rely on test codes to improve the reliability of programming and make refactoring more efficient and effective.
Wrap-up
As I introduced many technologies at LINE, I began to worry that I might have scared potential developers away from LINE. You could think you have to know and be good at all of these technologies to work as a frontend developer at LINE. No doubt it would be ideal to know all of these technologies. However, frontend technologies are evolving even as we speak. So, it is good enough if you are capable of using an appropriate technology under appropriate circumstances. If you have the basic understanding of java script and passion for frontend development, you are qualified to work as a frontend developer at LINE. Thank you for taking your time to read such a long post.
p.s. LINE is looking for frontend developers. Apply now.