paint-brush
Using Webpack with ArangoDB and Foxxby@stockholmux
968 reads
968 reads

Using Webpack with ArangoDB and Foxx

by Kyle DavisApril 10th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

I’m building a project with the <a href="https://www.arangodb.com/why-arangodb/foxx/" target="_blank">Foxx</a> microservices framework and <a href="https://vuejs.org/" target="_blank">Vue</a>. It’s pretty exciting, but I ran into some annoyances when it came to tooling. I was making changes rapidly and I had to invoke both webpack to bundle my front-end files and foxx-manager to “upgrade” the ArangoDB/Foxx service. On a side note, I was surprised that making changes to a static file in Foxx requires an upgrade. I need to dig into that further.

Company Mentioned

Mention Thumbnail
featured image - Using Webpack with ArangoDB and Foxx
Kyle Davis HackerNoon profile picture

I’m building a project with the Foxx microservices framework and Vue. It’s pretty exciting, but I ran into some annoyances when it came to tooling. I was making changes rapidly and I had to invoke both webpack to bundle my front-end files and foxx-manager to “upgrade” the ArangoDB/Foxx service. On a side note, I was surprised that making changes to a static file in Foxx requires an upgrade. I need to dig into that further.

A few years ago, as I was migrating to a more back-end-centric role, the front-end world went bonkers for task runners and compilers. It left me scratching my head — being that I’m old, I remember one of the compelling reason to write in an interpreted language was that you didn’t have to wait on a compiler. Oh well, turns out it wasn’t just a short lived fad. Most modern front-end frameworks require (or strongly encourage) the use of some sort of tooling. Thankfully, the backend JS world and the front-end world have started to normalize and with tools like webpack, you’re seeing the worlds merge.

But first, let’s back up and describe webpack. Webpack is slightly different than other front end tooling in that it’s a module bundler rather than a task runner like Gulp or Grunt. It’s mission is to take modules (used broadly) and package them into front-end friendly assets. How it makes modules digestible for the front end is by managing and packaging the assets. Webpack itself runs in Node.js as a CLI tool or as a module. Webpack also has a built-in development web server and file watcher.

My first thought was that maybe Foxx itself could run webpack as a module. After all the setup script (scripts.setup in manifest.json) is the perfect place to do this kind of thing. And it’s all Javascript. Unfortunately, that didn’t work out very well. The Foxx implementation of fs lacks the readFile function and only has the readFileSync. Which makes sense because ArangoDB implements Javascript synchronously. I probably could have patched much of it together but why swim against the stream?

Since Arango can’t run webpack, then maybe I could get webpack to run foxx-manager. In webpack you can run a simple setup with the command line or create a Javascript module that defines your configuration. I decided to go that route. First things first, however, let’s pulldown webpack. Since we want to have a repeatable setup, let’s initialize a package.json file.

npm init

It might seem a bit off to do this as the package.json file is a distinctly node thing, but we’ll be using a little bit of Node.js here as well.

After you’ve answered your questions in the npm initialization process, we can add a few development dependencies.


npm install --save-dev webpacknpm install --save-dev webpack-shell-plugin

Let’s build our configuration file. It’s customary to name this file webpack.config.js although it could be anything. My file looked like this:

Going through this file, let’s examine a few key points.

  1. On line 2, we’re using the webpack-shell-plugin. This allows webpack to act as a rudimentary task runner. foxx-manager is very simple from a command line perspective, we just need to run something — no inputs or outputs. It should fit our needs.
  2. The path module is used to smooth out differences on different platforms. I haven’t tested my script on anything aside from macOS, but this makes sure we’re generally constructing our paths with the right directory dividers.
  3. The entry property of module.exports (line 6) is the single file that we’re going to run webpack over. In this file, you can do cool things like…

import joi from 'joi-browser';

…to get access to a module. Webpack will manage the dependencies for you.

4. The output object of module.exports (line 7–9) defines the output file mentioned in the entry property.

5. Probably the most interesting part is the use of WebpackShellPlugin on line 12. This is where we’re going to trigger the foxx-manager upgrade. Now, in this example, I’ve put in the development credentials for a localhost server. You might want to include a file from outside the repo to manage the username, password, mount point and database name. I tried to access webpack’s command line arguments but no dice. I’d be curious to know of a workaround to be able to pass in arguments or a path to a JSON file to manage these credentials.

Now, to run this, you can run webpack from the command line in your project directory.

./node_modules/.bin/webpack --config webpack.config.js

This will first package up your webpack file then run foxx-manager. If you want to get really fancy, you can add the watch command line switch and webpack and foxx-manager will run automatically when you change the webpack managed file.

./node_modules/.bin/webpack --config webpack.config.js --watch

There you have it. Webpack will run foxx-manager automatically when you alter your webpacked dependencies. Now, this will run the foxx-manager only for file in module.exports.entry, so if you alter another static file you’ll need to manually re-run foxx-manager.

P.S. If you’re interested in ArangoDB, you might also want to checkout Getting started with ArangoDB and Foxx: Joifully CRUD-y in the best way.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!