Saturday, April 22, 2017

Putting my node.js-toolbelt aside...

So I'm about to head into a new challenge, which does not include much - if any - node.js development. Therefore I'm trying to conserve as much of my current knowledge as possible for others and potentially a future me (hey tom! :)).

Setup

Ubuntu is the one and only operating system to use if you ask me, but I'm sure you can get stuff done with any of the operating systems nowadays. As an editor I love Atom for its simplicity, ecosystem and performance (see: how to install Atom on Ubuntu). Chrome is the way to go for its incredible developer tools of course.

Installing npm properly is surprisingly hard because of file permissions. If you don't follow the steps below you'll have to install global dependencies as root (and also some local dependencies if I remember correctly?): 


Frequently used modules (server-side)

When creating a new project I see myself using the same modules over and over again:
  • moment: I haven't touched a Date-object in a year or so...
  • express: it took me months to finally give it a try, but it really makes things a lot easier!
  • Q: I'm trying to use native Promises, but for advanced promise-handling (e.g. wait for several promises to finish) this library is still the way to go
  • bunyan: must-have if you're serious about your application. Crank up your logging for easy error-detection. Also incredibly helpful if you're using multithreading (cluster)
  • request-promise: for requests...
  • standard: You're doing it wrong if you're not using a linter. It took me way too long to figure this out, since I was too lazy to figure out the correct rules, but that is exactly the point of standardjs: just use a fairly standard ruleset across all projects and get coding!
Some more notes on standardjs: I hate single quotes and I was absolutely shocked when I saw that they do not use semicolons. However, it really does not matter at all. You'll get used to it, I promise. It's not religion, we just want to get stuff done...
There are also Atom-plugins to show and automatically "fix" style violations. That way I didn't even care if I accidentally used double quotes or a semicolon out of habit, because the linter fixed it for me.

This is usually enough to get started. Of course, depending on the project you might include a few more related modules, but I generally try to keep the number of dependencies low. Most importantly, I try to avoid frameworks like lodash, etc because they're usually used like a blackbox that magically does things without knowing about its performance or security implications. That's why it took me so long to finally use express, but in that case it saves you from lots of stupid boilerplate-code (request routing) without being an unnecessarily thick layer.

Someone has to be able to use the application after all (aka client-side)

I'm really not a designer, and would never dare to call myself a Frontend Developer. I can get decent things done, but using CSS is like black magic for me, which is why I'm still using br-tags instead of setting margin on elements...

Anyway, I recently started using Material Design Web Components for all webapps I'm working on! The documentation is far from perfect, which makes getting started really hard as a non-experienced Web Developer. In fact it took me three tries (over the span of a few months) until I finally understood how to properly use it and felt comfortable to use it in my own projects. The thing that was not obvious to me from the beginning was that there is additional documentation for each component inside the respective folder (doh!). So after checking out the Getting Started Guide make sure to look at a component's documentation.

For small webapps which are only used internally inside a company it's usually fine to include each Javascript- and CSS-file in your HTML and call it a day. If the project gets any bigger and you care about the nerves of the poor guy who has to maintain your project after you quit, you should give webpack a try. I love that it allows you to draw dependencies between Javascript, CSS and even HTML if need be. Moreover, you can start using npm for installing frontend dependencies, which is a huge step forward for everyone involved. Again, the documentation is really hard to follow for non-experienced developers and it took me quite some time to figure out the basic setup I needed. I recommend you to take a look at the obvious "Getting Started" for Javascript and "Code Splitting CSS" for CSS.

Architecture

It's still hard for me to put the way I create applications into words, but I share a lot of articles related to that on Google+. Here's a few things to know:
  • classes ending with "Bridge" are generally wrappers for some kind of logic, but nothing that involves UI. TimeBridge, SqlBridge, etc you get the idea.
  • classes ending with "Component" wrap a UI component and all its logic.
Without webpack, every class is wrapped in an IIFE in order to not pollute the global namespace by exposing internal methods and variables. With webpack the class is simply exported using standard syntax.

That's the most important things to know when reading my code. There are some more subtle things which I won't go into detail now (instead, take a look at the articles posted on Google+).

Deployment

I love Google Cloud, and I enjoyed working with AppEngine a year ago. But for node.js development Heroku is still the way to go if you ask me. The deployment process via git is too good to be true!
(Please note that I've only used Heroku for single-instance hobby projects. For anything serious I'd probably not recommend Heroku but a multi-instance setup with a loadbalancer and autoscaler)

Putting it all together

You can find a sample project which uses all of the above on GitHub: either with webpack or without it.

The apps are hosted here (with webpack) and here (without webpack) for demonstration purposes.

No comments:

Post a Comment