All web developers will at some point come across "CORS" errors and they can be incredibly frustrating, after all you're just trying to grab some data from your development server. This blog will show you how you can use XAMPP as a reverse-proxy so that you can pull data from your development server to your local machine.

Cross-Origin Resource Sharing (CORS)

In order to understand CORS, we need to understand why it exists and that brings us to the Same-Origin policy (where an origin can be equated to a domain). The general principal behind this policy is that a 3rd-party should not be able to interfere with your webapp via means such as Cross-Site Request Forgeries (CSRF) and clickjacking, in essence it protects the integrity of data contained and transmitted from all origins.

However without being able to share things, how do we have the internet? CORS restricts the sharing of resources across origins so that it's possible to share resources without making yourself vulnerable to attacks. This is the reason that your local webapp running on localhost:8080 can't pull data from a gateway service running on https://my.gateway/my-service, you're not on the same origin!

What's a Reverse Proxy?

A reverse proxy is the usual answer to this problem for web developers, it is essentially a server that sits in front of a web server and client requests to the web server. It sits between a client and a server as the middle-man, in our particular case this means that it becomes the single-point of origin for all our requests.

By running a local web server on our environment and routing all of our traffic through the server we can trick a browser into thinking that our webapp and gateway are running on the same origin.

I'll be using XAMPP as my web server, download it here.

XAMPP configuration

After installing XAMPP on your machine, open up the control panel for it and start up your Apache server. If you visit localhost:8080 you'll notice that it resolves to something you're not used to seeing, this is your Apache web server!

Note: You may have to enable default port forwarding to point your web server to localhost.

Running your webapp

In order to host your webapp on your fresh new web server, you can either:

• Move your web projects into Apache's default hosting directory which is /ApacheInstall/apache/htdocs
• Update your Apache configuration to point to your project directory e.g. ~/Documents/

You can update the configuration by clicking on the config button on the XAMPP control panel, once httpd.conf is open you can use Ctrl + F for "htdocs" to find the line you want to edit.

Note: On Mac you will have to mount a volume in order to find the XAMPP config files.

Restart your web server and edit the URL to point to one of your projects (or delete everything else and you'll see a file tree with all your projects) and you should see your webapp.

Reverse Proxy configuration

Now that we've got our webapps running on our web server, we need to pull our data source into the server too. To do this we need to enable a few Apache modules in the httpd-apache.conf and then set-up the proxy path, this is the URL-pattern we want to map from our server to our gateway server.

Activate the following modules:

Include "conf/extra/httpd-proxy.conf"
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so

Note: # is used to comment lines in our config files, you can search for these particular modules and uncomment them if you want to save yourself any headaches that may arise from updates to XAMPP.

With these modules loaded onto our web server, we can now set-up our proxy paths. This is how we map a specific URL-pattern on our web server to our gateway server.

If you're using an SAP Gateway server, then it makes sense to map anything after ./sap/ in our URL to our Gateway server. Add the below lines to your config:

ProxyPass /sap/ https://my-gateway-box.com/sap/
ProxyPassReverse /sap/ https://my-gateway-box.com/sap/

Note: Update my-gateway-box in the above code, to your own gateway server!

Now save your config changes, restart Apache. Our configuration is now live and that means that a service call from our web server that looks something like localhost:8080/sap/opu/odata/sap/ZTEST_SERVICE will be mapped to https://my-gateway-box.com/sap/opu/odata/sap/ZTEST_SERVICE.

Now load up a webapp that pulls data from your gateway server, you should see the data you've been waiting for!

Leave a comment

If you've gotten stuck somewhere along the way or you're using another web server as a reverse proxy, leave a comment and let me know how you got on.

This post will detail the process to easily and reliably deploy your React web app to GitHub Pages.

What is GitHub Pages?

GitHub Pages is a way for you to turn your GitHub repository into a website for free, it hosts the site/app/documentation for your repository. It's free and helps you get on with developing rather than going through web hosting provider #342.

Pre-requisites

You will need to have the following before starting this tutorial:

• Code editor (I use VS Code)
• Git SCM
• Node.js
• NPM or Yarn
• A GitHub account

Creating a GitHub repository

The next step is creating an online repository for your application, log in to GitHub and then create a repository and fill out the details as below:

Once you have created the repository we need to turn GitHub Pages on for the repository. To do this navigate to the "Settings" tab of your repository and scroll down to the "GitHub Pages" section. Now set the source for your pages to gh-pages branch and save your changes.

Once you have saved your changes you will need to clone it to your development machine. You can get the clone URL (via SSH or HTTP) from your repository.

git clone git@github.com:Leoooob/leonhassan.co.uk.git

Now that we've got our local repository set-up, we can create our application.

Creating a React application

You are going to create a simple react application that is ready to go, to do this you are going to use the create-react-app NPM module.

npm install -g create-react-app

Now that you have installed the module, you want to use it to create the template application. I'm going to use leonhassan.co.uk as my example project, once it's created you should navigate to the app directory and run it.

npx create-react-app leonhassan.co.uk
cd leonhassan.co.uk
npm start

You should now have be staring at a webpage served from localhost:3000 that looks something like the below:

If you can see something similar to the screenshot then commit the changes to your repository and push them upstream.

git add .
git commit -m "create-react-app commit"
git push origin master

Deploying to GitHub Pages

There is a very handy NPM module called gh-pages that we are going to use to deploy the application for us by running a single command.

npm install --save gh-pages

While the package installs, edit your package.json to include 3 new key-value pairs, as highlighted below:

Make sure that you use your own github.io repository link!

Now that we've installed the deployment package and configured the project to use it properly, we can deploy our application by running the following command from the project folder.

npm run deploy

Once the deployment process has run it's course, you should be looking at a console output similar to this:

You have now successfully deployed to your GitHub page, well done! I recommend waiting a few minutes before checking the site, it can take a little while to build your webpage so don't be disheartened if it's not instantly available.

Leave a comment

If this tutorial has helped you or you have any questions, please leave a comment and share the post.

In this article I will be detailing a very simple DevOps pipeline that uses Babel.js and Gulp.js to transpile ECMAScript 6 to ES5, making it compatible with IE9!

Prerequisites: Node.js v8.11

npm install

Add the following dev dependencies to your project by either dropping them directly into your package.json or by running npm install --save-dev ${package}, where ${package} is the package name e.g. @babel/core.

{
  "main": "index.html",
  "devDependencies": {
    "@babel/core": "^7.1.2",
    "@babel/preset-env": "^7.1.0",
    "babel-cli": "^6.26.0",
    "gulp": "^3.9.1",
    "gulp-babel": "^8.0.0",
    "gulp-rename": "^1.4.0"
  }
}

Once you have all of these packages successfully installed, run the command npm install from the root directory.

Gulp tasks

Now create a gulpfile (terminal command touch gulpfile.js) at the root directory of your project and paste the below:

const gulp = require('gulp');
const rename = require('gulp-rename');
const babel = require('gulp-babel');

// default gulp task
gulp.task('default', () =>
  // for each js file in the javascript folder
  gulp.src('./javascript/*.js')
    .pipe(babel({
      // transpile ES6 to ES5
      presets: ['@babel/preset-env']
    }))
    .pipe(rename((path) => {
      // add file name suffix .controller to file
      path.basename += '.controller';
    }))
    // save new js file to the controller folder
    .pipe(gulp.dest('./controller'))
);

To run this build pipeline, run the gulp command from the top-level directory of the project (where your gulpfile.js sits).

Example JavaScript in project

Currently this simple build script:

• Takes each javascript file from the javascript folder named.
• Transpiles them to ES5 as per the preset-env (you can write your own preset)
• Adds the .controller suffix to the new file
• Saves the new file in the controller folder

git and ui5 ignores

Your project .gitignore should include:

/node_modules
/controller

Your project .Ui5RepositoryIgnore should include:

/node_modules
/javascript
gulpfile.js
package.json
package-lock.json

Leave a comment

I hope that this tutorial has been helpful to you in modernising your UI5 workflow, I've setup an example repository here on GitHub. Leave a comment or tweet me with your thoughts and questions!

In this PWA post I will cover the Cache API and the storage limitations of the Cache and IndexedDB APIs, how you can use a Manifest file to support touch icons and the 'add to homescreen' functionality and the Lighthouse audit tool.

Cache API

A cache is technically a request-to-response map, where we store request URLs and their responses in the cache. This allows us to serve data from the cache initially, or intercept network requests and serve directly from the cache where possible.

There are a number of methods in the Cache API, however I will not be covering them in this post.

Building a simple application cache

Mapping our cache actions to Service Worker events will help us to understand how to incorporate caching into service workers and allow you to build upon your service workers easily.

There are a number of common caching strategies such as the Cache with Network fallback you have seen in a previous PWA post. This strategy focuses on caching on network response, other strategies focus on caching on installation or on user interaction.

Note: You should have a service worker setup prior to continuing. Instructions to set-up a basic service worker and how to implement it on your page can be found on my GitHub Gist.

Cache on Install

Caching on install happens in almost every service worker, because we almost always cache some static assets. For instance a website header image, the CSS file etc. This particular caching stategy extends to webapps in a specific way, caching your application shell! By caching our application shell we stop the user from having to redownload the static parts of a web application, meaning that they only use data for the dynamic parts of the application.

The code example for this can be found on my GitHub Gist.

Cache on User Interaction

Caching on user interaction is very useful for a lot of user journeys, for instance a blog that does not fully-support an offline experience could make use of this strategy by allowing users to "Save for Later". Triggering this action would then put a copy of an article/post in the cache, allowing the user to visit that post at their leisure e.g. while on the train home from work, while offline.

The Cache API is available from pages, not just the service worker and this means that we can add things to the cache without involving the service worker. The following code is an example DOM structure and JavaScript that should be added to your webapp's JavaScript and not your service worker:

HTML:

<div id="articleList" >
  <div class="article" id="articleID">
    <!-- your article link/thumbnail goes here -->
  </div>
</div>

JavaScript:

// when an item in your articleList is clicked
document.querySelector('#articleList').addEventListener('click', (event) => {
  event.preventDefault();
  var class = event.target.class;
  if (class.includes("article")) {
    var id = event.target.id;
    
    // create a new cache for the article and add it
    caches.open('mysite-article-' + id)
      .then((cache) => {
        // fetch the article to add to the response
        fetch('/get-article-urls?id=' + id)
          .then((response) => return response.json())
          .then((urls) => cache.addAll(urls))
          .catch((error) => return error);
      }).catch((error) => sreturn error);
  }
});

Using the code example above you should be able to implement Cache on User Interaction with ease, the only real changes needed are configuration-related for your website e.g. DOM structure and fetch URL + parameters. You will also need to adjust your fetch event listener in the service worker to check for article caches.

Storage limitations

Due to Progressive Web Application's being a rather young technology, the specifications for these young APIs aren't quite as unified across browsers as you would expect and therefore implementation details vary slightly. To clarify: there is no change in behaviour across browsers.

It is very common for these storage limitation to be across the various storage APIs, that means that your cache, indexedDB, localStorage and cookies etc can all count towards your storage limit.

These are not hard figures as the specification is still being standardised across browsers, therefore they are subject to change. I would use the rule of thumb: Don't bank on more than 20mb of space available. Think of your mobile users, your poor storage starved mobile users!

Manifest file

A manifest file is primarily for mobile browsers, allowing you to simulate a native-app experience for your web app. This is achieved by giving users the opportunity to 'Add to Homescreen'. This will 'install' the application on the user's device and allow them to run it from their app launcher, in a headerless browser. This gives the user a more native-feeling experience.

The file is just some json information, here is an example:

{
  "name": "My Application",
  "short_name": "My Application",
  "start_url": "index.html",
  "icons": [{
    "src": "images/touch/icon-128x128.png",
    "sizes": "128x128",
    "type": "image/png"
  }],
  "background_color": "#ffffff",
  "display": "standalone",
  "theme_color": "#f05f40"
}

You can examine your manifest file in Chrome Dev Tools, via the 'Application' tab and Manifest heading. You can now examine many of the individual properties in your manifest, it will even render the icon images.

You can include your manifest in your webapp by adding the following HTML to your head tag:

<link rel="manifest" href="manifest.json">

Touch icons

The icons key in your manifest file are important, especially as the manifest specification matures. These icons are used not just as the 'app launcher' tile image, but also in the splash page of the app while it loads.

Currently for other non-Android operating systems, we need to specify some HTML shivs so that our icons are picked up. The below example uses the Wandr website as an example:

  <!-- Add to homescreen for Safari on iOS -->
  <meta name="apple-mobile-web-app-capable" content="yes">
  <meta name="apple-mobile-web-app-status-bar-style" content="black">
  <meta name="apple-mobile-web-app-title" content="Wandr">
  <link rel="apple-touch-icon" href="./assets/static/favicon_192px.png">

  <!-- Tile for Win8 -->
  <meta name="msapplication-TileColor" content="#f05f40">
  <meta name="msapplication-TileImage" content="./assets/static/favicon_192px.png">

As Progressive Web Applications mature and become more widely supported, these shivs won't be necessary. You can read more about all the different properties you can set in your manifest at Google Developer docs.

Lighthouse audit tool

Lighthouse is an open-source audit tool for webpages, focusing on the core areas: progressive web apps (most of this comes from the PWA checklist), performance, accessibility and best practices. Lighthouse scores the webapp in each of these areas and provides human-friendly information on how to score higher and fix issues in your webapp.

You can run Lighthouse directly from Chrome dev. tools on a page (open Chrome dev tools and navigate to the Audits tab), as a Chrome extension or from the commandline using the npm package.

You can run Lighthouse directly from Chrome dev. tools on a page, as a Chrome extension or from the commandline using the npm package.

The best part of a Lighthouse report is the feedback given for each of your scores, the feedback tells you what was done correctly and what can be approved. The highlight of this is that the information is human-friendly, not just a generic error as we so regularly find in web development.

As you can see in the screenshot above, the criteria your webapp is measured by are clearly displayed and in cases where it does not meet these criteria comprehensive errors are given, as depicted in the screenshot below:

Opportunities to improve the performance of my webapp are listed in the above screenshot, with clear instructions on how this can be achieved.

Using Lighthouse to audit your webapp helps you to contribute to a reach PWA ecosystem and ensures that you are building responsive, performant webapps. In cases where your webapp isn't as well-built as it could be, Lighthouse even offers insights on improving your webapp. I believe that Lighthouse is an invaluable tool that will become a part of all web developers toolkits in the near future, get ahead of the curve and start using it now!

What have you built?

You can view a large and growing list of Progressive Web Applications at https://outweb.io/ and https://pwa.rocks/, you can even index your own applications on these websites!

Leave a comment or tweet me, letting me know what you've been building throughout this post! I'm a massive advocate of PWAs and can't wait for the day that the majority of websites leverage service workers and manifest files.