I recently started working on a relatively simple application in [Electron](https://www.electronjs.org). Since I'm used to working with the JavaScript frameworks [Vue.js](https://vuejs.org) and [React.js](https://reactjs.org), I wondered if I could use them for this application - of course I could. So I decided to go with Vue.js. I spent some time Googling what interleaving methods are most commonly used. Most of the time I ended up with some ready-made CLI. So I decided to try [Vue CLI plugin Electron Builder](https://nklayman.github.io/vue-cli-plugin-electron-builder/). As the name suggests, it is an extension for the Vue CLI and implements, besides Electron, also [Electron Builder](https://www.electron.build), which is a package that makes building a build with a finished application much easier.

So I started to develop the application, and tried a few first builds. At the beginning everything seemed to be without problems, these only increased as the application code was extended. Except perhaps that the first build on macOS didn't work for me either, but it turned out to be a problem with the Archiver application, which doesn't restore symlinks after unzipping the zip, so it can be worked around with other archive software. Besides, Apple has known about the bug since macOS Catalina. I'll stick with macOS, I also tried a build for new MacBooks with Apple Silicon processors, at first Electron Builder didn't seem to recognize these processors, however after checking in Activity Monitor I found that some builds are marked as _Apple_ and others _Intel_. So I figured that the builds are being created according to the correct architecture, but it depends which one is created first - ARM or Intel, because the latter will overwrite it. A number of other silly little things like that popped up, besides not being able to create a .dmg or .pkg. So my friend recommended `electron-packager`. But replacing the builder in this CLI utility is not a matter of one npm *(Node Package Manager)* command. I eventually solved all the problems and the builds work the way I need them to, but it did lead me to wonder, what if I solved the whole thing myself?

That is what I would like to address in this article. However, unlike Vue.js, I decided to go with React.js. I've also decided to replace the traditional Webpack with Vite and see if these tools can be combined. Let's leave aside that while with Electron bundler I get some freedom over configuration, with Vite I sacrifice some of it again. However, combining these tools is ultimately easier than I would have expected. Of course, it has its pitfalls and is definitely not as convenient as ready-made CLI tools, unless you decide to write something similar yourself. That won't be part of this article, though.

## Vite and React.js

Let's start by installing Vite, as I said it is in a way similar to Webpack. Like Webpack, it also offers a dev server and a tool to _build_ application code. However, unlike Webpack, it works directly with ES _(ECMAScript)_ modules and does not compile them into CommonJS, and the Express.js web server has replaced the minimalist Koa server. The _Hot module reloading_ is also many times faster, de facto instant, on the other hand it allows to use only ES modules and not CommonJS or AMD. Build code is done in a pre-configured [Rollup](https://rollupjs.org/guide/en/), whereas Webpack handles this itself. A sort of imaginary advantage is also the need for minimal configuration of the whole project, that is if you decide to use one of the predefined presets, for example React or Vue.

```bash
npm init @vitejs/app my-react-app
```

During project creation Vite asks for a template choice, so we choose `react`. We are then prompted with a few commands that we should run to get everything installed, ie:

```bash
cd my-react-app
npm install
npm run dev
```

If we've launched at least the first two, the Vite interface and React.js app are ready. That leaves the final command, which is to run the dev server to verify that everything works. We should see in the command line that the app is running on `http://localhost:3000` or some other port if 3000 is already taken. We can then proceed to install Electron,

## Electron

It is a framework for creating _cross-platform_ desktop applications using JavaScript, CSS and HTML. Thanks to Electron we can create native applications and the hardest things like updating, native menus and notifications or crash reporting are handled by Electron. Installation is very simple, just run the following command:

```bash
npm install --save-dev electron
```

Now we just need to edit the `package.json` file and add the _entry point_ for the Electron application, most commonly called `main.js`. However, this is where the first catch comes in, Electron only supports CommonJS, while Vite only supports ES. One option is to accept that the parts for Electron will be in CommonJS and the parts for Vite/React will be in ES, but this will make it a bit harder to share code. Since Vite prefers ES it is easier to compile the code for Electron from ES to CommonJS. So our _entry point_ will look like this:

**main.js**
```js
import { app, BrowserWindow } from 'electron'
import path from 'path'

const IS_DEV = process.env.IS_IN_DEVELOPMENT || false

function createWindow () {
  // Create the main Electron window
  const win = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      nodeIntegration: true,
      enableRemoteModule: true
    }
  })

  if (IS_DEV) {
    // If we are in development mode we load content from localhost server - vite
    // and open the developer tools
    win.loadURL('http://localhost:3000')
    win.webContents.openDevTools()
  } else {
    // In all other cases, load the index.html file from the dist folder
    win.loadURL(`file://${path.join(__dirname, '..' ,'dist', 'index.html')}`)
  }
}

app.whenReady().then(createWindow)

app.on('window-all-closed', () => {
  // On macOS, it's common for an app and its menu bar to remain
  // active until the user shuts down the application via the Cmd + Q shortcut
  if (process.platform !== 'darwin') {
    app.quit()
  }
})

app.on('activate', () => {
  // On macOS, if an application is in the dock, it is common for a window to be created after
  // clicking on the icon in the dock if there are no windows active
  if (BrowserWindow.getAllWindows().length === 0) {
    createWindow()
  }
})
```

Perhaps the only difference from the one found on the Electron website is the use of ES and the declaration of the global variable `IS_DEV`, which
to distinguish whether the Electron instance should load the web from the Vite server or a generated HTML page in the `./dist` folder. Then we need to
modify `package.json` so that the value of `"main"` refers to our file, i.e. not exactly:

**package.json**

```json
{
  "main": "./dist/main.js",
}
```

You may be surprised to know that I am referring to the `dist` folder, whereas our file is not in any folder. Let me explain.

## ESBuild

As I wrote, Electron only supports CommonJS, while Vite and by extension React only works with ES. What about it?
The easiest solution is to use some bundler, in this case esbuild, since Vite uses it too. I have also tried Babel, however
it conflicts with Vite and the application fails to _build_. So we install esbuild:

```bash
npm install --save-dev esbuild
```

Add the following lines to the `"scripts"` section:

```json
{
  "scripts": {
    "esbuild-cjs": "esbuild main.js --format=cjs --outfile=./dist/main.js",
    "electron:dev": "npm run esbuild-cjs && IS_IN_DEVELOPMENT=true electron ."
  }
}
```

The first script, `esbuild-cjs` transforms the EC code into CommonJS and thus makes it digestible for Electron. When
we read it carefully, we will also see that the output file is stored in the `./dist/main.js` folder, which is where we have referenced
in the `"main"` value of the `package.json` file. The second script is then used to run the Electron development instance. So, if we have done everything correctly, running `npm run electron:dev` will first transform the `main.js` file into CommonJS and only then will Electron be started. If we're running the Vite server at the same time, we'll see the opening page of the React application - identical to the one we saw in the browser after visiting the `http://localhost:3000` page. Now all we have to do is choose the right builder and we can develop applications with Vite, React and Electron.

## Electron Packager

After the initial fiasco with Electron Builder, I decided to try an alternative for this article, namely [Electron Packager](https://github.com/electron/electron-packager). I have to admit that the documentation doesn't compare, Builder has much better documentation, but you should try everything. So let's install Electron Packager:

```bash
npm install --save-dev electron-packager
```

After installation, just add another script to `package.json` in the value `"scripts"`, namely:

```json
{
  "scripts": {
    "electron:build": "npm run esbuild-cjs && electron-packager --out=release ."
  }
}
```

The script again first uses an existing esbuild script to convert the `main.js` file to CommonJS and then calls
Electron Builder, which in this case creates an application package for our active paltform. In the case of Windows for Windows, macOS for macOS and Linux for Linux. With that, we're done and all we have to do is play around with the application itself and configure all the components.

Electron and Vite.js with React.js


If we want to display posts from social networks on our website or any other website,
or work with an API, it's often a good idea to have your own server that caches the results from the original API.
This is especially true when queries to the API are limited and there is a real risk that one
one day the server for that service will shut down and not send anything.

In this article I would like to discuss how to create such a simple API cache using
_Express.js_ application. So I assume at least basic knowledge of _JavaScript_, working with _NPM (Node Package Manager)_ and command line.

## Getting Started

The easiest way to get started with an _Express.js_ application is to use the _Express application generator_. This is
simple tool that prepares the basic structure of the project and adds information about the
libraries that we will need for our application. So let's start by creating a folder with our application:

```bash
mkdir API-Cache && cd API-Cache
```

Then we create a new _Express.js_ application in the folder and install some libraries. I also recommend to take a look
for possible configuration options in the [documentation](https://expressjs.com/en/starter/generator.html).

```bash
npx express-generator && npm install
```

This should create the basic structure of the project in our folder, including the `node_modules` folder containing all the libraries
specified in the `package.json` file. For our project, however, we will need a few more libraries that
_generator_ does not contain, namely _dotenv_, _cors_ and _got_, and possibly also _nodemon_ to automatically restart the server when there is a change in the code.

```bash
npm install --save dotenv cors got
# since we don't need nodemon in production, we only install it as a dev dependency
npm install --save-dev nodemon
```

Finally, we create an empty `.env` file that will contain sensitive data of our application, such as authentication tokens.

```bash
touch .env
```

This should give us everything we need to develop the application.

## Information source

For our example application, we will use the _Quotes on Desing_ API, which is freely available, as a source of information.
contains a number of quotes from famous people. The API information can be found [here](https://quotesondesign.com/api/) for our purposes, copy
this link:

```
https://quotesondesign.com/wp-json/wp/v2/posts/?orderby=rand&per_page=1
```

The results are sorted randomly, and due to the `per_page=1` parameter, we only ever see one quote.

## Cache

Next we need to solve the _cache_ of the provider, in this article I will work with the _cache_ in the server memory. It is not
ideal solution, especially if you need to store a larger amount of data or if the data should remain in the cache even
after a server reboot. In this case, it would be better to choose a _cache_ that is stored on disk. However, in this case I assume,
the data will only stay in the _cache_ for a few tens of minutes at most.

So we will create a simple _constructor function/class_ that will hold our data. So we'll create a folder called `mkdir utils` in which we'll
to store our _constructor function/class_ - `DataCache.js`.

**DataCache.js**
```js
function DataCache (fetchFunction, minutesToLive = 10) {
  this.fetchFunction = fetchFunction;
  this.millisecondsToLive = minutesToLive * 60 * 1000;
  this.fetchDate = new Date(0);
  this.cache = null;

  //...

}

module.exports = DataCache;
```

The basic form of our _constructor function/class_ _DataCache_ is as follows, it accepts two parameters.
The first `fetchFunction` is a method to fetch data from our source when the _cache_ needs to be updated.
The second parameter is the lifetime of the data in _cache_ before it is no longer valid. For clarity, we will specify it in minutes
and we'll convert them to milliseconds afterwards. Next, we prepare a variable `this.cache` which should contain the data and `this.fetchDate`,
which will carry the date the data was last read into _cache_.

We will also add the `isCacheExpired()` function to our class to find out whether _cache_ has expired or not.

```js
  this.isCacheExpired = () => {
    return (this.fetchDate.getTime() + this.millisecondsToLive) < new Date().getTime();
  }
```
The method compares the current time with the sum of the time stored in the variable
`fetchDate` and the cache lifetime. If this time is less than the current time, _cache_ expires.
The most important function, however, is `getData()`, as it provides both the retrieval of data from the source and the return of data from the cache, namely
depending on whether it is cached and still valid.

```js
  this.getData = () => {
    if (!this.cache || this.isCacheExpired()) {
      console.log('expirováno - načítám nová data');
      return this.fetchFunction()
        .then((data) => {
        this.cache = data;
        this.fetchDate = new Date();
        return data;
      });
    } else {
      console.log('data jsou v cache');
      return Promise.resolve(this.cache);
    }
  }
```

The method always returns _Promise_ with data. For better clarity, I also left the logs in the code, which we can see in the command line
to show if the server has read the data from _cache_ or from _cache_. This completes our _DataCache_ class and we can try it out
in practice.

## Loading data on the server

So we create a controllers folder in the project root `mkdir controllers && cd controllers` and in it a controller `touch QuoteController.js`. The _QuoteController_ will contain only one method, namely `getQuote`, which will query the _Quote on Design_ server for the current quote.

**QuoteController.js**

```js
const got = require('got');
const DataCache = require('../utils/DataCache');

function getQuote () {
  return got(`https://quotesondesign.com/wp-json/wp/v2/posts/?orderby=rand&per_page=1`)
    .then((response) => {
      return JSON.parse(response.body);
    })
    .catch((error) => {
      return error;
    });
}

const quote = new DataCache(getQuote, 1);

module.exports = quote;
```

First we load the necessary libraries, which is the _got_ we will need for
API query and our _DataCache_ class. Then
we declare a function `getQuote()` which consists of just a query to the API. For the query
we use the [_got_](https://github.com/sindresorhus/got) library, even though it would be
could also use the standard _HTTP_ module, but _got_ gives us a much
saves us a lot of work. In the `then` block, we also convert the response body to _JSON_ format,
since _got_ itself does not handle the response and only returns a text string.
Finally, we create a variable in which we initialize our _DataCache_ class and export it.

We add the following lines to the `./routes/index.js` file. We will add _Require_ to our controller below the others
_require_ lines. Then register our path anywhere below the original code, but before `module.exports`.

```js
// ... original require statements
const quoteController = require('../controllers/quoteController');

// ... original code
router.get('/quote', async (req, res, next) => {
  quoteController.getData().then((data) => {
    res.json(data);
  });
});
```

In the _route_ registration we just call _controller_ and in it a method from our class that mediates for us
data either from _cache_ or from a query to the API. We then send the returned data in json format. That's it! Now
just run the `npm run start` command and visit the `http://localhost:3000/quote` page in your browser, where you should
you should see a random quote! You should see the following in the server console:

```
[nodemon] starting `node ./bin/www`
expired - loading new data
GET /quote 200 164.028 ms - 5056
data is cached
GET /quote 200 1.710 ms - 5056
data is in cache
GET /quote 200 0.969 ms - 5056
```

## Conclusion
Congratulations on successfully creating a very simple and basic cache API! If you have decided that you
such a simple cache is enough. I recommend you take a look at the whole code again and extend or modify the error trapping as well
it is probably advisable to remove the `console.log()` parts of the code. The `DataCache` class can also be extended very easily with the `fs` module.
module with the ability to cache to disk, although even this may not be ideal in some cases.


How to create custom cache server for different APIs?


If we want to work in PHP with Oracle database, we must first compile and install the OCI8 extension.

## Installing Oracle Instant Client and SDK

First we need to download _Instant Client_ and _SDK_ from ([Oracle website][wOracle]) to which
we also need to register on the Oracle website. We are looking for the files
`instantclient-basic-linux.x64-[version].zip` and `instantclient-sdk-linux.x64-[version].zip`.
Once the files are downloaded, we create a folder in `/opt`, for example `mkdir /opt/oracle`. The files
files are then moved into the folder.

```bash
mv instantclient-basic-linux.x64-[verze].zip /opt/oracle/instantclient-basic-linux.x64-[verze].zip
mv instantclient-sdk-linux.x64-[verze].zip /opt/oracle/instantclient-sdk-linux.x64-[verze].zip
```

Moved files need to be unzipped.

```bash
cd /opt/oracle
unzip instantclient-basic-linux.x64-[verze].zip
unzip instantclient-sdk-linux.x64-[verze].zip
```

Then we create symbolic links to the `.so` files. **Your version of Instant Client and SDK
may differ, so double-check the folder name and the name of the .so files.**

```bash
ln -s /opt/oracle/instantclient_19_5/libclntsh.so.19.5 /opt/oracle/instantclient_19_5/libclntsh.so
ln -s /opt/oracle/instantclient_19_5/libocci.so.19.5 /opt/oracle/instantclient_19_5/libocci.so
```

Finally, you still need to add the folder to the ldconfig configuration. **The folder name will be different**

```bash
echo /opt/oracle/instantclient_19_5 > /etc/ld.so.conf.d/oracle-instantclient.conf
```

And update ldconfig, using the `ldconfig` command.

## Installing extensions to PHP

In order to compile oci8 extensions, it is usually necessary to install a few more
additional libraries. Typically, these are:

```bash
apt install php-dev php-pear build-essential libaio1
```

After successful installation we can finally start compiling the OCI8 extension. In the command
`echo' command, we will specify the path to the _instant client_ installation folder, because if we
we didn't specify it, the installation would ask us for it anyway.

```bash
echo "instantclient,/opt/oracle/instantclient_12_2" | pecl install oci8
```

After compilation and installation, you still need to modify the PHP configuration so that the extension
OCI8 to load. Therefore, we send the following set of commands:

```bash
echo "extension=oci8.so" >> /etc/php/7.3/mods-available/oci8.ini
ln -s /etc/php/7.3/mods-available/oci8.ini /etc/php/7.3/cli/conf.d/20-oci8.ini
ln -s /etc/php/7.3/mods-available/oci8.ini /etc/php/7.3/fpm/conf.d/20-oci8.ini
ln -s /etc/php/7.3/mods-available/oci8.ini /etc/php/7.3/apache2/conf.d/20-oci8.ini
```

The first line creates the `.ini` file in PHP 7.3 mods. If you have a different version of PHP, or you
you are not sure, check it first with `php --version`. The remaining three lines will create
a symbolic link to the CLI, FPM and Apache2 to load the extension in all environments. However, if
you are not using FPM or Apache2, you can safely omit one of these lines.
Finally, we'll check to see if the extension is actually enabled.

```bash
php -m | grep oci8
php-fpm7.3 -m | grep oci8
```

If you see oci8, we're almost done. We still need to restart the FPM client and Apache2.

```bash
service php7.3-fpm restart
## nebo
service apache2 restart
```



[wOracle]: https://www.oracle.com/database/technologies/instant-client/linux-x86-64-downloads.html

Martin Roček

How to create custom cache server for different APIs?

How to create custom cache server for different APIs?

Installing OCI8 not only on Ubuntu

Installing OCI8 not only on Ubuntu