Decentralizing with Server-side Rendering of Native apps

by B. Tkachenko

“History Moves in a Spiral,” and I think the same rule applies to Software and especially Web apps. In the early beginning of the Internet, the most common way to deliver content to the user was a static hosting of HTML pages. Then developers started to use different server-side scripts and frameworks to generate HTML code for every request, depending on user’s info and user’s request. This approach made Web revolutionary and accessible for everyone — anyone can create a website using Content Management System (CMS) which does not require knowledge of a programming language. That is how mainly everything on Internet worked before: you send a request, server renders HTML and sends it back to you, and your browser renders this HTML using the set of visual components.

In 2004 Google changed this approach forever. They introduced Gmail — today’s world’s most popular e-mail service. Having many advantages over other email services, Gmail used a technology named AJAX to load content dynamically, without refreshing a web page. There were already different approaches to do that, like iframes, but technically it was the same thing, but you could have multiple web pages inside of your web page. The funny thing is that Microsoft created this technology in 1999 for some internal needs in Outlook, but basically nobody used that for about five years.

AJAX made it possible to load basic HTML code, JavaScript and then load separate data files dynamically. This started a new Web 2.0 era when everyone tried to create Single-Page Applications which has completely different approach than before: now the server is “dumb” and client is “smart” which means that all markup is generated on client and server is only responsible for delivering content and for some security-related logic.

It is 2018… and guess what? Static websites are trending again! Can’t say that they were not used all this time, but it’s definitely becoming more popular these days. They’re not the same as in early 00’s — they are much more beautiful and much easier to implement and maintain, they also may use 3rd-party widgets to display dynamic content or some JavaScript to make your website more dynamic, but still, it is just a set of HTML files hosted on the server. More and more companies choose static websites every day — it’s much easier to implement custom and unique design. They’re way faster because CDN can cache your whole website and you don’t need to pay for a cluster of computers just to host a website. And probably the main advantage is that it is not possible to hack them. Well, there is still possible to hack a lot of things around them, but not the website itself, for example it is possible to hack or DDOS your CDN provider or to hack DNS provider.

This is just one of many examples of how old technologies are reconsidered and combined with new technologies to create better solutions for specific cases. Mobile apps have gone through some different steps, but it’s always possible to see that a lot of new technologies is just something old, but implemented from a different point of view.

So what is the problem?

In doc.ai we are developing a mobile app which is a part of our new platform, and we want to make it customizable and to allow third-party developers to extend the app, and add new features. Our vision is to make the app completely decentralized and data not being processed on central server. We are working hard on this but it will take us a while as the current technologies aren’t reliable. In the meantime we have to use a server-side solutions to provide the best product and then make it decentralized over time.

So how can you let 3rd party developers add new features to your app? There are several possible approaches:

1.You make your app open-source and let developers modify it. This approach is good, but it has several limitations:

• Developer needs to know the programming language that you use to develop your app.
• To deliver an update to users you need to build a new version of your app, get approvals to publish it in App Store and Google Play and then wait till all users update the app.
• If there is some major problem with feature developed by 3rd party developer, you have three options to fix this:

I.ask 3rd party developer to fix it

II.fix it yourself or

III. just disable this feature

All these options require you to publish a new version of your app, which means that it can take about three days for a user to get a new version. And not everyone will update it — you will get a lot of complaints, and some users will just delete your app because it does not work.

It’s just too hard to support monolithic app implemented by the core team and tens of 3rd-party developers.

2. You have the main part of your app as a native application, and you have specific sections as a web page. This is a pretty popular approach, and it works pretty well, but it has significant disadvantages:

• It’s terribly slow — your users will hate you for the app which freezes every time. It’s slow because WebView is slow and it takes much more time to render a web page, then rendering of a native component, especially if the page has a lot of elements.
• You have to maintain styles of your app along with styles of your web app and to make sure that they do match and that your app looks good.
• Want to use some hardware feature or something OS-specific? Well, you can’t. Sometimes you can spend a lot of resources to maintain lots of additional code to do that, but usually, that’s not an option.
• Your app completely works as a web page. The same as previous, but it’s even a bit slower, but as an advantage, you don’t need to maintain two versions of styles.

Better solution?

At doc.ai we are using a combination of #1 and #2 but with some modifications. We have a native app with plugins that also use native components, but developers can dynamically add them using markup language and send it to mobile app from server. For developer creating a new page (we call them Views internally) in our app is as simple as just creating the HTML file. We use React Native which allows us to have the same code base for iOS and Android, and we let developers also to use a simplified version of JSX. We call this approach “Server-side React Native Rendering.” And because it renders native components, it’s super quick. It still requires additional knowledge of markup language, but writing HTML-like code is way easier than writing Objective-C or Swift code. Here is how simple can simple View look like:

We are sending Views from the server, which means that we can control when to show them. It means that in case if something breaks, we can simply disable one small part of an app while it’s being fixed without affecting other parts of the app and immediately. We don’t need to release a new version of an app and wait till users download it. We simply disable it, and it’s gone, and we also can do this automatically when we detect a problem with one of the sub-apps. We also do have a special Web interface for developers to have some limited control over the app that is running in our app to be able to diagnose and fix problems on early stage.

This approach also allows developers to easily build Views that perfectly match into our app interface because we’re carefully designing and tailoring every component available for developer.

How does it work internally?

Well, our server-side part is pretty simple: we just generate markup code from template per request and send it back to the user. We also do some caching stuff on the server and as well on a client to make sure that user gets the content as soon as possible, but server-side is dead simple.

The real magic starts on a client when we want to render a View from markup. We have a special module that takes JSX markup and builds Abstract Syntax Tree and then creates a native component for each node in that tree and puts it right on the screen. Some components can also have some basic JavaScript code inside of attributes, similar to Angular templates, so as developer you can add some logic to components, for example you can open a modal window when you tap on some element.

More details you will find in the source code of this project when we will publish it to open-source.

But wait, you promised to make it decentralized!

This is our top priority. However there are some interesting challenges we have to solve first. We need to make it fast, reliable, secure and cheap. We also have to design it in such way that it will provide privacy to users, as well as to match a lot of government regulations. Stay tuned to hear first about how we are solving all of that using Blockchain technology and Smart-contracts.

Our first developers meeting will be led and organized by both our engineering and AI teams, as well as, our Chief Science Officer, Jeremy Howard.
When: Wednesday, March 21st from 6 until 8.30 pm
Where: Galvanize 44 Tehama Str. CA 94105 San Francisco

REGISTER HERE ( or sam@doc.ai for last minutes registration)
Food and drinks provided