How we are going to use the internet in the near future

I will make some predictions based on current trends while I also consider opinions from other authors (links below).

Source:  https://arstechnica.com/features/2015/10/the-future-is-the-internet-of-things-deal-with-it/

Mobile

The number of users who browse the Internet on a smartphone already outnumbers the number of those using a desktop PC. The trend seem to continue. Most European countries have almost full mobile network coverage allowing users to surf the internet almost anywhere. At the end of 2017 all European countries (except Belarus and the Ukraine) had mobile networks with a download speed of a least 10Mbps available (1). 5G is on the horizon being already for commercial use in some countries. On the other hand there are an increasing number of applications made or optimized for mobile. The number mobile apps on the Google Play Store has doubled from 2014 to 2017 bypassing 3 Million (2). Similar growth was seen in Apples App Store, though the number has slightly gone down recently. Mobile friendly websites (i.e. responsive websites) have become a standard in web development.

Smartphones are constantly receiving more functionality, i.e. the ability to run Augmented Reality (AR) apps. And of course the ability to have a conversation with the phone which brings us to the next point.

Voice

Siri (on the iPhone) may have been the first voice assistant that was broadly available to the public. But other vendors such as Amazon with its Alexa system and Google with it Google Assistant have caught up. Google Assistant is built into Android, the most used operation system for smartphones. While Apple also integrated Siri into its MacOS, Microsofts Cortana is available on all PCs running Windows. Voice assistants are now everywhere and can handle more intelligent tasks every day. Users can even make a purchase with it, like in the case of Amazons Alexa (3). Voice user interface (VUI) are also being integrated into mobile apps enabling users to input their data by speaking rather than typing.

Smart assistants for cars called Voice-enabled virtual personal assistants (VPAs) are already being manufactured and sold to the public (4). And VPAs are built into other devices like Microwaves.

Smart everything

Devices are becoming smart when they are connected to the internet and when users have a way to control them remotely via app or voice assistant. At home people can remotely control their smart light bulb(s), smart thermostat, smart fridge or their smart microwave (5,6). A home equipped with smart devices are generally referred to as Smart Home. More home devices/appliances will probably become smart.

But smart devices aren’t limited to home usage. Offices can become smart, manufacturing companies can become smart and even cities can become smart. Smart cities are in every mouth, though there is not a common definition. But we are still in the beginning.

Final thoughts

Those are not the only three factors that are influencing the way we connect to the internet to exchange data. Talking about data. A question that remains to be answered in the future is the ownership of the data generated.

Sources
1) https://www.ispreview.co.uk/index.php/2018/02/q4-2017-map-europe-uk-countries-mobile-data-speed.html
2) https://www.googlewatchblog.de/2018/04/google-play-app-store/
3) https://www.theverge.com/2017/7/10/15947672/amazon-alexa-voice-controls-shopping-prime-echo-how-to
4) https://www.alphabet.com/en-ww/blog/connected-cars-car-virtual-personal-assistants
5) https://www.tomsguide.com/us/what-is-a-smart-refrigerator,review-6307.html
6) https://www.lifewire.com/smart-microwave-4159823

Quo vadis web-development ?

In this post I will try to show how web development has evolved taking a frontend developer viewpoint.

Source: https://insanelab.com/blog/web-development/web-development-trends-2018/

The rise of client side rendering

Up until about 10 years ago server-side web development dominated. Applications (and websites) were merely functional and rarely intuitive. Then companies like Google, Apple & Co. demonstrated to the the world that well-designed and highly intuitive web sites were possible. This triggered a shifting focus user interaction (UI) and created professions such as Web Designer, UI/UX-Expert and (Web) Frontend Developer. It also brought up „frameworks“ like jQuery which enabled developers to simply pick from a set of UI-elements and listen for any events. Logic was gradually moved to the client side using JavaScript (or frameworks on top of JS like jQuery). Endpoints (APIs) were called to exchange data with the server. Few APIs were purely restful these days nor were they consistent in terms of content type or response structure.

The increasing usage of APIs and their asynchronous nature caused a so-called „Callback-Hell“ where one request had to wait for another to be complete. Furthermore jQuery did not enforce any coding style nor did it provide a clear structure. One can easily imagine that the code base became quickly unmanageable. The backend saw the introduction of frameworks like CakePHP or ASP.NET which enforced the concept of Model-View-Controller (MVC). This concept got later adopted in the frontend with the introduction of Backbone (which was mainly just MV) and later AngularJS (which was rather Model-View-Presenter (MVP)). This clear separation of concerns made the code more readable and maintainable.

The „Callback-Hell“ got eventually resolved by the introduction of promises which became the standard implementation in Javascript with the release of Ecmascript 6 (or Ecmascript 2015). CSS-Libraries like Bootstrap also got introduced which provided an extensive set of UI elements and a grid system enabling developers to effortlessly create responsive websites. An increasing amount of users browsed the internet with their mobile devices and could now be served mobile-friendly websites. Some companies even went as far as following the paradigm of „mobile first“. Creating a single page application (SPA) allowed web frontend developers to even create an iOS or Android app with no extra coding. They simply used a solution called Cordova (formally known as PhoneGap) to create an app that basically consisted of a browser which only ran the SPA. Such an app is called „hybrid app“. There are still around but get increasingly created by making use of other frameworks such as Reactive Native or Flutter.

When React became open-source in 2013 it also introduced a new concept: the Component-Based-Architecture (CBA). The idea behind this concept is the encapsulation of individual parts of an UI into self-contained, independent micro-systems. With the use of a virtual DOM (rather than the „real“ DOM) it was able to update the view much faster than AngularJS. Angular (or Angular2+) adopted the CBA and now enables developers to create encapsulated and loosely coupled components. The framework also pushed developers to use Typescript instead of Javascript with the intention of introducing type security. That clearly had a positive effect on Typescript which has become one of them most popular programming languages (1). Both React.js and Angular are still the most-widely used frontend frameworks (1).

The backend in the meanwhile slowly shifted towards a micro service architecture (2).

The current state of frontend development

Vue, Angular, React

The Flux pattern became hugely popular in the frontend allowing functional (or reactive) programming. One reason was the introduction of the library Redux that worked perfectly well with React.js allowing more efficient application state management. Many Angular developer teams adopted this paradigm (using a library Ngrx store). Another framework took the stage that has a flux-like implementation built in: Vue.js (with its vuex state management). It gained a lot of traction and finds itself amongst the „most loved“ frontend frameworks (1). The framework is supposed to be easy to learn, small in size and therefore „ensures a more rapid development process“ (3).

The introduction of Service Worker (SW) addressed an issue that still persisted on the client side: the functioning of web apps when the client device is offline. By using service worker developers were now able to create progressive web apps (PWA). The aforementioned frameworks all have a strategy of how to integrate service worker (5,6,7). The strategy of programming the web app to be usable offline is also called „offline first“. Besides having to find an offline strategy for their application web developers also have to spend time figuring out a suitable rendering strategy (8).

Another problem remained: not being able to use a component in another framework. Web Components are addressing this issue enabling developers to create self-contained components (WebComponents) that are framework-agnostic. They can run in any (modern) browser as they bring everything along (JS, HTML, CSS). Web Component are not new though, but the attention has only recently shifted more towards them. A new framework called Svelte.js made the stage. It is supposed to be very lightweight and it embraces the creation of Web Components.

The backend is seeing a shift towards „containerization“. Instead of leaving the admins to figure out what system requirements are to be provided on the server in order to run the application containers are created (i.e. with Docker) that run anywhere.

The future of frontend development

Nobody can predict the future, but some trends can already be seen on the horizon:

  • WebAssembly: a programming language that the browser understands and that runs along with Javascript.
  • GraphQL - „a query language for your API“. While a „conventional“ Rest-API has „fixed“ data structures, GraphQL enables consumers of the endpoint to define the data structure.
  • Serverless: having a single function deployed (in the cloud) that can be called any time. This saves the deployment (and maintenance) of an entire app (or service).

Another trend to watch out for may be the „low code development“ approach which lets non-developers create software using UI-Tools.

Sources:
1) Developer Survey Result: Stackoverflow
2) The What, Why, and How of a Microservice Architecture: Medium
3) The Pros and Cons of using Vue.js: naturaily.com
4) Using Service Workers: Mozilla
5) Angular service worker introduction: Angular.io
6) Making a Progressive Web App: https://create-react-app.dev
7) Build a Progressive Web App in. VueJs from Zero to Hero: hackernoon
8) Rendering on the Web: developers.google.com

State Management in Angular2: Using ngrx-store to manage state

State Management in Angular2: Using ngrx-store to manage state

Where should an application keep the state ?

  • Components? Not ideal, at least once you have shared logic (state) between components.
  • Services? It is one way, as you inject the ones necessary into a component and subscribe to its Subject(s) or
    BehaviourSubject(s).

Better than services: using a library that manages state (i.e. ngrx-store).

Having your Angular2 (or 4) application setup, just install ngrx-store (https://github.com/ngrx/store)

npm install @ngrx/core @ngrx/store --save

An easy example for its usage could be a component, which displays alert messages. First we will need a reducer, that handles the different actions.

// reducer/alert.reducer.ts
import {ActionReducer, Action} from '@ngrx/store';

export enum messageTypes {
  SUCCESS,
  ERROR,
  INFO
}

export interface AlertStateInterface {
  message: string;
  messageState: messageTypes | string;
}

export const initalMessageState: AlertStateInterface = {
  message: '',
  messageState: ''
};

export const ADDALERT = 'ADDALERT';
export const REMOVEALERT = 'REMOVEALERT';

export function alertReducer(state: AlertStateInterface = initalMessageState, action: Action) {
  switch (action.type) {
    case ADDALERT: {
      return Object.assign({}, state, {
        message: action.payload.message,
        messageState: action.payload.messageState
      });
    }
    case REMOVEALERT: {
      return Object.assign({}, state, {
        message: '',
        messageState: ''
      });
    }
    default: {
      return state;
    }
  }
}

There are 2 types of actions (ADDALERT and REMOVEALERT) which the reducer can receive. An action has 2 properties : type and payload. There is a switch case for each type, which returns a new state. The payload can be defined as needed, in our case it has 2 properties : message and messageState (which can either INFO, SUCCESS or ERROR).

The actions can be dispatched anywhere in the application by calling :

store.dispatch({ type: XXXXX, payload: { // });

Lets say we want to dispatch an error (alert) in a component. First we need to inject store, and then dispatch the action.

constructor(private store: Store<AppState>) {
  // dispatch an error
   this.store.dispatch({ type: ADDALERT, payload: {
     'message': 'BAD',
     'messageState': 'ERROR'
   }});
}

An alert component is then needed, which listens to state changes in the store. Since we do not want component state, we simply create an observable and update the view using the async pipe.

@Component({
  selector: 'app-alert-messages',
  template:`
    <div class="alert" *ngIf="alertAsync | async as alert">
      <div class="" *ngIf="alert.message">
        
      </div>
    </div>
  `
})
export class AlertComponent {
  alertAsync: Observable<AlertStateInterface>;

  constructor(private store: Store<AppState>) {
    this.alertAsync = store.select('alert');
  }
}

Managing state employing ngrx-store means having stateless (!) components and services.

Everything is a stream.

You can find the implementation on my github : https://github.com/marek1/ngrx-alert