3 Types Of Web Application Architecture

Such terms as ”web app”, ”front-end architecture”, ”Web 2.0”, and ”HTML5 apps” have recently become trendy. Unfortunately these terms are often used in a misleading context which doesn’t consider the full specificity of implementation and usage of web app architecture. Today we’ll try to find out more about the types of web application architecture in the light of the latest web trends and key issues that matter to software owners.

We’ll outline 3 main types of web architecture and discuss their advantages and drawbacks for three points of view: software owner, software contractor (developer) and end user. There can be other types but they basically come down to these three as their subtypes.

First we’ll define a web application: it’s a client-server application – there is a browser (the client) and a web server. The logic of a web application is distributed among the server and the client, there’s a channel for information exchange, and the data is stored mainly on the server. Further details depend on the architecture: different ones distribute the logic in different ways. It can be placed on the server as well as on the client side.

It’s near to impossible to evaluate these completely different architectures impartially. But we’ll try to, using several criteria of evaluation:

Responsiveness/Usability. Updates of data on pages, switching between pages (response time). Such qualities of user interface as richness and intuitiveness in use.
Linkability. Ability to save bookmarks and links to various sections of the website.
Offline work. Speaks for itself.

Speed of development. Addition of new functional features, refactoring, parallelizing the development process between developers, layout designers, etc.
Performance. Maximum speed of response from the server with minimum consumption of computation power.
Scalability. Ability to increase computation power or disc space under increases in amounts of information and/or number of users. In case the allocated scalable system is used, one must provide data consistence, availability and partition tolerance (CAP theorem). It’s also worth noting that the case, when the number of features/screens of the client app is increased at the software owner’s request, depends on the framework and implementation rather than the type of web architecture.
Testability. Possibility and easiness of automated unit testing.

Software owner:
Functional extendability. Adding functionality within minimal time and budget.
SEO. Users must be able to find the application through any search engine.
Support. Expenses on app infrastructure – hardware, network infrastructure, maintenance staff.
Security. The software owner must be sure that both business data and information about users are kept secure. As the main security criterion we’ll consider the possibility of changes in functionality of app behavior on the client side, and all associated risks. Standard dangers are the same for the compared architectures. We do not consider security on the ‘server-client’ channel, because all these architectures are equally exposed to break-ins – this channel can be the same.
Conversion: site – mobile or desktop application. Possibility to publish the application on mobile markets or to make a desktop application out of it with minimal additional costs.

Some of these criteria might seem inaccurate, but the purpose of the article is not to show what’s good and what’s bad. It’s more of a detailed review that shows the possible options of choice.

Let’s outline three main types of web applications according to the roles performed by the server and the client browser.

Type 1: Server-side HTML

The most widespread architecture. The server generates HTML-content and sends it to the client as a full-fledged HTML-page. Sometimes this architecture is called ”Web 1.0”, since it was the first to appear and currently dominates the web.

Responsiveness/Usability: 1/5. The least optimal value among these architectures. It’s so because there is a great amount of data transferred between the server and the client. The user has to wait until the whole page reloads, responding to trivial actions, for example, when only a part of the page needs to be reloaded. UI templates on the client depend directly on the frameworks applied on the server. Due to the limitations of mobile internet and huge amounts of transferred data, this architecture is hardly applicable in the mobile segment. There are no means of sending instant data updates or changes in real time. If we consider the possibility of real-time updates via generation of ready chunks of content on the server side and updates of the client (through AJAX, WebSockets), plus design with partial changes of a page, we’ll go beyond this architecture.

Linkability: 5/5. The highest of the three, since it’s the easiest implementable. It’s due to the fact that by default one URL receives particular HTML-content on the server.

SEO: 5/5. Rather easily implemented, similarly to the previous criterion – the content is known beforehand.
Speed of development: 5/5. This is the oldest architecture, so it’s possible to choose any server language and framework for particular needs.

Scalability: 4/5. If we take a look at the generation of HTML, under the increasing load comes the moment when load balance will be needed. There’s a much more complicated situation with scaling databases, but this task is the same for these three architectures.

Performance: 3/5. Tightly bound to responsiveness and scalability in terms of traffic, speed etc. Performance is relatively low because a big amount of data must be transferred, containing HTML, design, and business data. Therefore it’s necessary to generate data for the whole page (not only for the changed business data), and all the accompanying information (such as design).

Testability: 4/5. The positive thing is that there’s no need in special tools, which support JavaScript interpretation, to test the front-end, and the content is static.

Security: 4/5. The application behavior logic is on the server side. However, data are transferred overtly, so a protected channel may be needed (which is basically a story of any architecture that concerns the server). All the security functionality is on the server side.

Conversion: site – mobile or desktop application: 0/5. In most cases it’s simply impossible. Rarely there’s an exception (more of exotics): for example, if the server is realized upon node.js, and there are no large databases; or if one utilizes third-party web services for data acquisition (however, it’s a more sophisticated variant of architecture). Thus one can wrap the application in node-webkit or analogous means.

Offline work: 2/5. Implemented with a manifest on the server, which is entered to HTML5 specifications. If the browser supports such a specification, all pages of the application will be cached: in case the connection is off, the user will see a cached page.

Type 2: JS generation widgets (AJAX)

Evolved architecture of the first type. The difference is that the page, which is displayed in the browser, consists of widgets (functionally independent units). Data are uploaded to these widgets through AJAX query from the server: either as a full-fledged chunk of HTML, or as JSON, and transforms (through JavaScript-templating/binding) into the content of the page. The option of uploading chunks of HTML excludes the necessity of using JavaScript-MV*-frameworks on the client side; in this case something simpler can be used – for example, jQuery. By lowering interactivity we boost the development speed and make functionality cheaper and more reliable.

The foremost advantage is that updates from the server arrive only for the part of the page requested by the client. It’s also good that widgets are separated functionally. A particular widget is in charge of a part of the page; changes in a part will not affect the whole page.

Responsiveness/Usability: 3/5. The volume of transferred data for a part of a page is smaller than for the whole page, that’s why responsiveness is higher. But since a page is a set of widgets, the applicable UI templates in a web application are limited by the chosen UI framework. Cold start (the first full loading) of such a page will take a little longer. The content, which is fully generated and cached on the server, can be instantly displayed on the client; here time is spent on getting the data for the widget and, as a rule, on templating. At the first visit the website will not be that quick to load, but further it will be much more pleasant in use, if compared to sites based on the architecture of the first type. Also it’s worth to mention the possibility of implementation of ”partial” loading (like it’s done on yahoo.com).

Linkability: 2/5. Here special tools and mechanisms are needed. As a rule, Hash-Bang mechanism is applied.
SEO: 2/5. There are special mechanisms for these tasks. For example, for promotion of websites based on this architecture it’s possible to predefine the list of promoted pages and make static URLs for them, without parameters and modificators.

Speed of development: 3/5. Not only does one need to know the server-side technologies, but also to use JavaScript frameworks on the client side. It’s also required to implement web services on the server side.

Performance: 4/5. The time and resources, spent on generation of HTML-content, are relatively minor if compared to the time spent by the app on retrieving data from the databases, and on their processing before templating. Use of the extended type of this architecture (when data are transferred as JSON) lowers the traffic between the client and the server, but adds an abstraction level to the application: retrieval from database -> data processing, serialization in JSON -> API: JSON -> parsing of JSON -> binding of data object on the client to HTML.

Scalability: 4/5. Same as for the first type of architecture.

Testability: 1/5. It’s required to test the server side, the client code, and the web service which returns the data to update widgets.

Security: 4/5. Part of the logic is shifted to the client JavaScript which can be modified by an intruder.

Conversion: site – mobile or desktop application: 0/5. Same as for the first type of architecture.

Offline work: 1/5. The manifest mechanism works in this case, but there’s a problem with updating or caching the data displayed on the widget. This functionality has to be implemented additionally: in the manifest can be indicated only names of the files which will be cached from the server. Correlation between the widget template file, cached in the manifest, and logic of page behavior requires extra labor efforts.

Type 3: Service-oriented single-page Web apps (Web 2.0, HTML5 apps)

Here we’d like to say that the term ”Web 2.0” isn’t quite correct here. One of peculiarities of Web 2.0 is the principle of involving users into filling and repeated adjustments of content. Basically the term ”Web 2.0” means projects and services which are actively developed and improved by users themselves: blogs, wikis, social networks. This means Web 2.0 isn’t bound to one technology or a set of technologies.

Let’s figure out the essence of this architecture. An HTML-page is downloaded from the server. This page is a container for JavaScript-code. This code adresses a particular web service and retrieves business data only. The data are used by JavaScript application, which generates the HTML-content of the page. This type of architecture is the evolution of the previous type, which actually is a self-sufficient and rather complex JavaScript application, where part of the functionality is shifted to the client side. To compare, the architecture of the second type cannot show a high number of interrelated and structured functions.

It’s also worth noting that nowadays rarely do appear JavaScript apps which work fully offline (with few exceptions, e.g. rad-js.com). This approach allows an easily made reverse conversion: publish an existing application on the web.

Responsiveness/Usability: 5/5. The volume of data transferred for updates, is minimal. That’s why responsiveness is at the highest level. UI is generated via JavaScript, it’s possible to implement any necessary variants. There is an issue with multithreading in JavaScript: in this particular case processing of big volumes of business data should be shifted to the web service.

Linkability: 1/5. One will need special tools and mechanisms, as well as frameworks which can use, for example, Hash-Bang mechanism.

SEO: 1/5. The hardest architecture to promote. If the whole app is promoted directly, there’s no problem: it’s possible to promote the application container. If it’s needed for a part of the application, a special mechanism will be needed for that purpose. Each more or less big search engine offers its own methods of standartization for this process.

Speed of development: 2/5. It’s required to develop a web service and apply more specialized JavaScript frameworks which build the app architecture. Since the architecture is relatively new, there aren’t many specialists who are able to create a high-quality site/system based on this approach. There aren’t many time-tested tools, frameworks and approaches.

Performance: 5/5. Under this architecture this criterion has the lowest influence from the server side. The server only has to give the JavaScript application to the browser. On the client side performance and browser type are of the biggest importance.

Scalability: 5/5. All the web logic is on the client side, there is no content generation on the server. When there’s an increase in the number of users, it’s required to scale only the web services that give the business data.

Testability: 3/5. It’s required to test web services and the client JavaScript code.

Security: 0/5. All the logic is shifted to the client JavaScript, which can be relatively easily modified by an intruder. For protected systems it’s required to develop a preventive architecture, which considers the peculiarities of open-source applications.

Conversion: site – mobile or desktop application: 5/5. A website becomes an application with the help of such platform as PhoneGap or similar ones.

Offline work: 5/5. This architecture is a full-fledged application; it’s possible to save separate data, as well as parts of the application using any storage (for example, localstorage). One more advantage is the possibility to switch data storage and management to the offline mode. To compare, the two aforementioned arhitectures are only partially functional in the offline. Here the missing data can be replaced with mocks, it’s possible to show alert windows or use data from the local storage, while synchronization may be left for later.

Thus we can see that there’s no perfect architecture – the optimal choice depends on tasks and priorities. If some criterion wasn’t mentioned here, it doesn’t mean it was ignored – it’s just the fact that for each particular software project every criterion has different importance. Each project must be discussed separately so the software owner will be able to make a choice. For every real project one of these criteria may be defining. It’s also possible to optimize the architecture of the app or implement a hybrid architecture which will perfectly meet the business requirements.


Apple team has made many app and technologies. They have popularized many new technologies as well. However, there are lots of IOS apps that are open source and hence you are going to find a lot of work that you can do as an IOS developer for the Apple. Either it is the Apple TV, Apple Watch, ResearchKit, HealthKit, CloudKit, Finance field, Communication, Content blocking, location, media, news, Games and many other sectors, You can build plenty of apps for Apple and then load on the Apple App store. You will have to pay a small fee as security to the Apple and then for each App you develop, you are going to get 70% of the sales profit earned through your App. Isn’t that exciting?

Apple has provided its third party IOS app developers with loads of new device features. If you remember each WWDC, then you will find that there is a Workshop during each WWDC and those are exclusively for the third party App developers. Top Apple programmers provides top information and tricks to the third party IOS app developers during these Workshop.

Now suppose you want to make an app on Asthma and you find out that Apple is in need of such app, you can start immediately. When you get an Apple ID and signup as a third party App developer, you still needs to update yourself or else you will not succeed. Technology related to various Apple OS keeps coming and you should know about all of them.

Click here and in the footer, you will find two labels, developer program and developer Account. This is where you can create an Apple ID and then you can enroll for the developer program. To know about all Apple new technologies do visit this page and you will get a lot of information. We will be covering everything related to Apple.

Apple is the richest company in the World worth more than 750 Billion and its shares has never fallen or been shown negative. People buy Apple shares with eyes shut as they know they will be getting record profit through the company. In the mid of 2015, Apple was in huge loss as rumored by media. However, Tim Cook kept on saying there is nothing like that and in the last WWDC with a series of new features, OS and devices, Apple proved that they are the best.

IOS 9.2 Beta 4 is available and you can download now.

Do visit this page regularly, you will get a lots of details out here.

Nook Color Update and Adding side loaded Nook Color App for Android on Screen by Nook Color App Manager

You will find thousand of apps related to the Nook Tablet as far as the Barnes & Noble shop is concerned. However, you will find many more apps that you can download with the help of the Barnes & Noble shop. It is undoubtedly thousands of additional apps and you will get everything out of the shop out here. There is an update for you as well. The Nook Tablet certainly requires the device running OS version 1.4.0 or earlier, if you want to sideload the Android apps. However, when you will side load the apps then in that case, those apps will not show up in the Nook tablet app library as well as the home screen. You need to search for them by name or you can use the Go Launcher EX that is a third party app launcher. However, what you are going to do when you want to add the shortcuts to apps on the Nook Tablet home screen, what will you do? You are certainly going to feel a little bit confused and would like to find apps that can solve your problem. If you will move to the past then in that case you will find the older Nook Color tablet that can certainly add the shortcuts on the Nook Tablet home screen certainly. That is important for Nook Color Update.web
It is the Nook Color App Manager that is available free of cost in the Android Market. If you will find that you have not rooted your tablet then you need to do it first and only then you can install this app as it certainly quite hard to find this particular app without the Google App Store.

Nook Color App for Android

This app was certainly being made for the Nook Color. It is one of the best Nook Color Apps for Android. You need to follow the fixed pattern for the fixing of the short cut on the Home screen certainly.
You need to tap and hold the App Manager icon in your app library and then a context menu will certainly pop up. Now you need to choose the Add to home option. You have started the process now. Now just press the N button on the Nook and then chose the home to just go to the home screen. Now you will see the shortcut for the App Manager. You can certainly tap it now to open the list of all the apps being installed on your device. However, there is an exception for the apps, which are being downloaded from the B&N shop as well as that being pre-installed on the tablet certainly.

Nook Color App for Android
If you want to quick as well as easy way to load the full list of the apps then you will be all set. You can certainly add the other apps to the home screen as well. Now open the App Manager as well as find an app that you want to add up on the home screen. Now you need to tap and hold on that app and finally choose the add to apps option as well. Now you will find a listing to the app library. Now you need to navigate to your app library just by pressing the N button on the Nook and finally choose the apps. Now locate the app being added as well as tap and hold until you find the context menu. Now choose the Add to Home option.
Now you will be able to do Nook Color Update with various unlimited number of apps on your home screen and you will not need to use any of the third party launcher certainly. The new apps are stacked on top of one another and you can drag as well as drop the icons at any place on the desktop.
Note: Nook home screen does not arranges the apps on the strict grid like others and hence there is no limit to shortcuts of the apps and the media.

AppMkr: online Android app maker review

Here is my first review of an online app builder. App maker software can seem ideal if you don’t want to learn how to develop Android apps yourself. The one up for review here is AppMkr.

After signup and activation, you can start building your app: you get offered three choices: ”Native iPhone MashUp”, “Native Android MashUp” and “Windows Phone MashUp”. All three basically offer to do the same thing: create an app from one or more RSS/Atom based feeds.

As you would expect I chose the Android MashUp option. Subsequently I was prompted to provide a URL, RSS/Atom Feed or Search Term. After that the site searched the web for content to use in the app. I chose the RSS feed for PubMed, a database of medical literature (when I am not working on Android projects, my hobby is practicing medicine icon wink AppMkr: online Android app maker review )

Sure enough, after a few seconds, a screen opened displaying a large picture of an Android phone showing a single icon in its screen. This icon was the logo of the PubMed organization. Clicking it launched a screen displaying the items in the RSS feed I chose. To the left of this demo screen were options for choosing an icon and a splash screen (both with images and pages downloaded from the PubMed site).

Next up were many options for enriching the app:

Adding tabs with different functions such as adding an Atom/RSS feed reader, a photo album or a “post message” tab.
Customizing the app: adding a header image, choosing different colors for the screen header and text and some “advanced features” which are not very clearly described.
Next up were several fields to input information about the app: title, description, website, etc.
Monetize option: you can choose between a free or a paid option. The “Free” option offers the user to publish under your own brand, free rebuilds, charging money for downloads, sharing and commenting, a sub selection of tabs in the app, and several other features. The other choice is the “Premium” version. This offers all the features of the free version plus scroll menu navigation, custom image or video wallpapers, live feed updates, customized feed layouts with HTML, sub-feeds, customized in-app advertising and more. The price of this is $79 per month.
This is quite a substantial sum! Getting a freelancer or company to develop an app exactly to your specifications can cost as little as $100. Bear in mind that this would be a one time cost, not a monthly subscription like AppMkr offers. Anyway, I chose the free option.

Several steps of the app creation process offer links to “Hire a professional” from the design marketplace. This is an interesting way to improve the quality of the app and of course it generates extra income for the company.

After that you get to a page where you can publish the app. An interesting feature is a “quality meter” at the top of the page, the app quality index (AQI). This is automatically generated by the site. It did not rate my lovingly crafted app very highly. Going back and adding more features enhanced the quality score. So, the AQI seemed to only consider the number of features in the app. More features get rated as higher quality. But simply adding more features does in no way guarantee a better quality product. An overwhelming amount of non essential features can even severely hurt the user experience!

Moving on: the publish screen has a “Build App” button. Pushing it sends the user to a page displaying the status of the app building process. So I waited… a few minutes later the app was done.

When the app is done, the user gets a choice to either manually install it or via an email they have to open on their Android device. Choosing the latter is as simple as clicking a link in the email AppMkr sends you on your Android device and the app will be installed. The manual install option provides a download of the app’s APK file which you can then install on an Android device and of course upload to the Google Play Store. Unlike some app builder services, AppMkr does not publish the app for you.

An important feature of AppMkr is being able to manage changes to the app after building and publishing it. The dashboard has options to send push notifications, swap the feeds for already published apps without rebuilding them, manage developer accounts etc. These features probably justify the subscription model of the paid version: after publishing the app, you will want to come back regularly and do updates and AppMkr has some nice tools to do just that.


AppMkr offers a simple but limited work flow for creating apps based around Internet content. If you want to make games or utility apps, an app creator like AppMkr won’t suffice. On the plus side, you can get your app up and running within an hour and it’s free! The paid version is subscription based: whether the extra features justify the $79 monthly fee is up to you… All in all it’s an interesting product so why not give the free version a spin?

The Great Android App Maker Shootout!

Yes, my friends, the time has finally come… the time to sort the wheat from the chaff, the good from the bad and possibly even the ugly! What am I rambling on about? Android app makers!

The last few weeks I have been reviewing several online Android app creators. These are (mostly) online tools which help you create an app if you don’t know how to develop Android apps with the Android SDK. I wrote about the pros and cons of several app builders and in most posts I compared the one under review with other products I reviewed earlier. But a real overview article was missing so I have decided to pit them all together in order to find out which is the best of the bunch.

This review covers the seven app creator I reviewed earlier. However, there are many more app makers out there so I may add others later if the need should arise.

How am I going to compare all these different products? The answer lies in the “Grand Table of App Maker Awesomeness” which I have been secretly working on for the past few weeks. This bad boy lists all the features, benefits and drawbacks of each app builder in one big ol’ table.

The Grand Table of App Maker Awesomeness

Some say, it has been here since the beginning of time… and that it eats cute green robots for breakfast. All we know is that it’s called the Grand Table for a reason!

The contenders in this shootout are Buzztouch, App Inventor, AppMkr, Andromo, iBuildApp, Appsbar and Mobile Roadie. All those different app makers have different features and each has its unique benefits and drawbacks. However, as I reviewed more and more app builders, I began to notice some trends. The Grand Table addresses the (in my opinion) most important features and characteristics. So can decide which app maker fits your particular needs best, without having to try them all for yourself!

Now, you may disagree with the choice of characteristics I put into this table. Perhaps you feel I have left out some crucial factor that should not be left out of this comparison… If so, do let me know! I do not pretend to know it all when it comes to this particular subject or any other for that matter. I intend to update this table when the need emerges and your input is appreciated!

So, without further ado, let’s have a quick look at the characteristics I chose as the basis for this epic app comparison…

First off is some information about pricing which is of course always an important characteristic! Some features with regards to branding and publicizing the app are listed such as being able to download a .apk file and publishing it under your own name. Then we get into the options for building and customizing the app, which contribute to the “overall design flexibility” judgment near the bottom as well as “overall feature set”.

I chose not to give the app makers an overall score or pick a winner because they tend to differ in the kind of propositions they offer. Some are free and seem to be designed for hobbyists, others are very much focused on businesses. However I will go into some pros and cons of the contenders and state some of my preferences.

The Good, the Bad and the Ugly

None of the app makers are so difficult to use that you’d have an easier time programming the app yourself in Java. App Inventor could be considered the most complicated to use, as its blocks interface is in fact a programming language in itself. On the flip side though, AI has the most extensive featureset… is really an awesome “laboratory” for those who want to experiment with mobile app functionality! Bear in mind though that your apps won’t be visually pleasing.

With Buzztouch, the difficulty (for some) is that the user must compile the app’s source code himself. This is however also a benefit as you will be able to “hack” the code and learn from it. Generally, Buzztouch offers a nice mix of features, customizability and price. I did however miss a preview function in the online builder.

Appsbar stands out because it is easy to use, completely free and has a balanced featureset. The commerce module lets you sell products and services through your app, impressive for a free product!

Andromo and Mobile Roadie won’t let you make an app for free… this may seem stingy considering that there are free app makers but bear in mind that these are businesses (except for App Inventor which is run by MIT). Both Andromo and Mobile Roadie offer a comprehensive featureset. Mobile Roadie offers more by way of customization but you will pay a much steeper monthly fee for it.

I was less impressed with iBuildApp and especially AppMkr: both offer free, easy to use app making capabilities but don’t stand out in any other way. AppMkr has the least amount of features and the paid version is quite expensive.


So, which is the one Android app maker to rule them all? That depends on the purpose you have for your app. App Inventor is great for experimenting: hours of fun can be had if you’re in to toying around with functionality and learning to program with “blocks”. For promoting businesses, artists and brands Mobile Roadie seems to be the most professional and comprehensive choice although it’s not inexpensive.

These are just two ends of the app creator spectrum… If you are looking for something in between be sure to have another look at the Grand Table of App Maker Awesomeness and check out the free versions or trials of the app makers in there. Happy developing!

Mistakes to Avoid While Choosing an App Developer

mistakesApp development is a complicated task and requires a lot of input, both physical and monetary. So before you merge into the app business, have your assets and prerequisites handy. If you are looking to hire a professional app developer and it’s your first time, choose wisely. The success of your app business depends on the caliber of the programmer.

Here are a few mistakes you should avoid while choosing an app developer.

Don’t pay upfront

If the developer you have hired asks for money first, deny. Do not lose a penny until you see the results he or she has generated. Provide the details about the app you want built to the developer and ask him or her to build it. If you are satisfied with the result, only then should you pay. Most developers today rush through their work or harness used programs to build apps. This could be dangerous for your app business.

 Look for Outsourcing

When you have hired a company to build your app, see if they outsource the job. See if they hire a freelancer. If they do, please retract your assignment. It not only brings about the involvement of a third party, but also may lead to unethical coding practices. You can never be sure of the language or the UI interface being used to develop your app. Get in touch with the company or individual personally before you assign the project.

Money is Result

Get quotations from various app development companies before you assign the task. Compare prices, time to be taken to complete the app, clients’ testimonials. Do not look for cheap developers as they may not be able to produce what you need on a tighter budget. You have to see if the developer is capable of producing what you have ordered. Look up their previous works; see if they have worked industry contracts before. Do not be tempted by a cheap quotation.

One Who Owns

Sometimes companies and freelance web developers leave trademarks on the apps to increase their popularity. Make your app developer sign a written copyright contract or a ‘work made for hire’ contract before you buy the finished product from your developer. The contract should have clear information on who owns the app designs, its source codes and all other contents and should not be disclosed unless approved by the owner.

These are some of the key points you should remember before you go out and hire an app developer.