[UK] Why do we build servers with web components? What should I do?

No, I’m not just talking about server-side Rendered Web Components. I’m talking about Web components that you can use to reach a record degree of support build servers.

As a refresher, web components are a set of proposed standards that offer a way to modularize and package UI and functionality into reusable and declarative components that can be easily shared and composed to create entire applications. Currently their greatest use has been in front-end web development. What about the back-end? It turns out that web components are not only useful for UI, as the Polymer project has shown us, but they are also useful for raw functionality. We’ll look at how these can be used, and talk about the key benefits:

• Declarative
• Modular
• Universal
• Shareable
• Debuggable
• Smaller Learning Curve
• Client-side Structure

Declarative

First off, you get declarative servers. Here’s a quick sample of an Express.js application, written with Express Web Components:

    

    
Copy the code

Instead of writing routes purely in JavaScript imperatively, you can write them declaratively in HTML. You can actually build a visual hierarchy of your routes, which is easier to visualize and understand than the equivalent in pure JavaScript. Taking a look at the example above, all endpoints/middleware pertaining to the Express application are nested in an element, and middleware is hooked up to the app in the order that it is written in the HTML with elements. Routes can be nested easily as well. Every middleware inside of an is hooked up to that router, and you can even have elements inside of elements.

Modular

We already have modularity with vanilla Express and Node.js, but I feel like modular web components are even easier to reason about. Let’s take a look at a good example of modular custom elements with Express Web Components:

    
        
        
    

    
        
    

Copy the code

Everything starts out in the index.html file. There is really only one place to go, :

    

    
Copy the code

We start up an Express app listening on port 8080 or process.env.PORT, and then we declare three middleware, and one custom element. I’m hoping that intuition leads you to believe that those three middleware will be run before anything inside of , because that’s exactly how it works:

    

    
Copy the code

Everything inside of is wrapped inside of an . All middleware in this component are available at /api. Let’s continue following to and :

    

    
Copy the code

    

    
Copy the code

As you can see, all of the routers are split into their own components, and are easily included into the main app. The index.html file is the beginning of an easy-to-follow series of imports that lead you through the flow of routes.

Universal

One of the reasons I love JavaScript is the possibility of sharing code across client and server. To some extent that is possible today, but there are still client-side libraries that don’t work server-side because of missing APIs, and vice-versa from the server to the client. Basically, Node.js and browsers are still different platforms offering different APIs. What if you could combine both? That’s what Electron is for. Electron combines node.js and the Chromium project into a single runtime, allowing us to use client-side and server-side code together.

Scram.js is a small project that helps run Electron in a headless state, making it possible to run your server-side web components just like you would run any other Node.js application.

I already have some basic apps working in a production environment using Dokku. If you’re curious, check out the Dokku Example.

Now let me explain one of the neatest things that I’ve seen while developing with server-side web components. I was using this client-side JavaScript library to make some specific API requests. It became apparent that the library was compromising the credentials to our database by providing them client-side. That wasn’t going to work for us. We needed to keep those credentials secure, which meant that we needed to perform the requests server-side. It could have taken a significant amount of effort to rewrite the functionality of the library to work in Node.js, but with Electron and Scram.js, I just popped the library in and was able to use it server-side without modification!

I just popped the library in and was able to use it server-side without modification!

Also, I had been working on some mobile apps built with JavaScript. We were using localForage as our client-side database. The apps were being designed to communicate with each other without any central authority, using a distributed database design. I wanted to be able to use localForage in Node.js so that we could reuse our models And have things work without major modifications. We couldn’t before, but now We can.

Electron with Scram.js offers access to LocalStorage, Web SQL, and IndexedDB, which makes localForage possible. Simple server-side databases!

I’m not sure how the performance will scale, but at least it’s a possibility.

Also, now you should be able to use components like iron-ajax and my redux-store-element server-side, just like you would client-side. I’m hoping this will allow reuse of paradigms that work well on the client, and close the gap between the context-shifting that inevitably occurs when going from the client to the server.

Shareable

This benefit just comes with web components. One of the major hopes of web components is that we will be able to share them easily, use them across browsers, and stop reimplementing the same solutions over and over again, just because frameworks and libraries change. This sharing is possible because web components are based on current or proposed standards that all major browser vendors are working to implement.

That means web components don’t rely on any one framework or library, but will work universally on the platform of the web.

I’m hoping many people will create server-side web components that package functionality just like front-end components. I’ve started with Express components, but imagine components for Koa, Hapi.js, Socket.io, MongoDB, etc.

Debuggable

Scram.js has an option -d allowing you to open up an Electron window when you are debugging. Now you have all of the Chrome dev tools available to you to help debug your server. Breakpoints, console logging, network info… Server-side debugging in node. js has always seemed second-class to me. Now it’s built right into the platform:

Smaller Learning Curve

Server-side web components could help level the playing field of back-end programming. There are a lot of people, web designers, UX people, and others who might not know “programming” but do understand HTML and CSS. Server-side code as it is today probably seems untouchable to some of them. But if it’s written partly in the familiar language of HTML, and especially the semantic language of custom elements, they might be able to work with server-side code more easily. At the least we can lower the learning curve.

Client-side Structure

The structure of client-side and server-side apps can now mirror each other more closely. Each app can start with an index.html file, and then use components from there. This is just one more way to unify things. In the past I’ve found it somewhat difficult to find where things start in server-side apps, but index.html seems to have become the standard starting place for front-end apps, so why not for the back-end?

Here’s an example of a generic structure for a client-side application built with web components:

app/
----components/
--------app/
------------app.component.html
------------app.component.js
--------blog-post/
------------blog-post.component.html
------------blog-post.component.js
----models/
----services/
----index.htmlCopy the code

Here’s an example of a generic structure for a server-side application built with web components:

app/
----components/
--------app/
------------app.component.html
------------app.component.js
--------api/
------------api.component.html
------------api.component.js
----models/
----services/
----index.htmlCopy the code

Both structures potentially work equally well, and now we’ve reduced the amount of context switching necessary to go from the client to the server and vice-versa.

Possible Problems

The biggest thing that could bring this crashing down is the performance and stability of Electron in a production server environment. That being said, I don’t foresee performance being much of a problem, because Electron just spins up a renderer process to run the Node.js code, and I assume that process will run Node.js code more or less just like a vanilla Node.js process would. The bigger question is if the Chromium runtime is stable enough to run without stopping for months at a time (memory leaks).

Another possible problem is verbosity. It will take more lines of code to accomplish the same task using server-side web components versus vanilla JavaScript because of all the markup. That being said, my hope is that the cost of verbose code will be made up by that code being easier to understand.

Benchmarks

For the curious, I’ve done some basic benchmarks to compare the performance of this basic app written for and running on vanilla Node.js with Express, versus the same app written with Express Web Components and running on Electron with Scram.js. The graphs below show the results of some simple stress tests on the main route using this library. Here are the parameters of the tests:

• Run on my local machine
• 100 GET request increase per second
• Run until 1% of requests return unsuccessfully
• Run 10 times for the Node.js app and the Electron/Scram.js app
• Node.js app
  • Using Node. Js v6.0.0
  • Using Express v4.10.1
• Electron/Scram.js app
  • Using Scram. Js v0.2.2
    • Default settings (loading starting html file from local server)
    • Debug window closed
  • Using Express v4.10.1
  • Using electron – prebuilt v1.2.1
• Run with this Library: github.com/doubaokun/n…
• Run with this command: nab http://localhost:3000 --increase 100 --verbose

Here are the results (QPS stands for “Queries Per Second”):

Surprisingly, Electron/Scram.js outperformed Node.js… we should probably take these results with a grain of salt, but I will conclude from these results that using Electron as a server is not drastically worse than using Node.js as a server, at least as far as short spurts of raw request performance are concerned. These results add validity to my statement Earlier when I said that “I don’t foresee performance being much of a problem.”

Wrap Up

Web components are awesome. They are a standard declarative component model to the Web platform. It’s easy to see the benefits on the client, and there are so many benefits to be gained on the server. The gap between the client and server is narrowing, and I believe that server-side web components are a huge step in the right direction. So, go build something with them!

Credits

Node.js is a trademark of Joyent, Inc. and is used with its permission. We are not endorsed by or affiliated with Joyent.