Or: Lessons from building a Node+Typescript application for production, Part 3
This is one post that is part of a series of posts about what I learned building and running an application with Node.js and Typescript. The application consists of two separated codebases. One for the frontend and one for the backend. There are more posts about Language features, Tools, DevOps and Reliability.
One thing that is a bit more tricky in the frontend compared to the backend is setting up different configurations for environments. I found multiple approaches to this, but in the end chose the most simple to me.
1) In the frontend application, create a file called environment.js. This file just sets some keys on the global window object. It should be ignored in source control, because it will have to be created with different content for each environment.
2) Include it in your index.html before the main compiled Javascript files
3) In the main application, I created a Settings class like this:
4) Whenever I need the settings in the actual application logic, I just call it like this
This is one post that is part of a series of posts about what I learned building and running an application with Node.js and Typescript. To be exact the application consists of two separated codebases. One for the frontend and one for the backend. In this post I’m going to focus on the things I learned related to developing in Typescript/Javascript. There will be more posts about Tools, DevOps and Reliability.
Disclaimer: some of the lessons apply to plain javascript of course and would come up without typescript too.
Types are not checked at runtime
Interfaces, parameter types and function return types are all super helpful when developing your application. But be mindful where your data is coming from. Even if you write hello(name: string), another script can still pass in hello(1), typescript won’t check that.
Fat arrows => awesome
While developing both the backend and the frontend with TypeScript I really learned to love the fat arrow functions. I recommend this article by Brandon Morelli that shows the different syntax options for fat arrow functions and what the differences are. The main things to keep in mind:
() Parenthesis are not required if there is only one argument
If {} is not present around the function body, the function will return the result of the first (and only) statement
To explicitly state a type in Typescript, () are necessary
The advantages of using fat arrows:
In plain Javascript, I’m always asking myself “what exactly is this? right now”. With fat arrow functions, this is always what I expect it to be.
Shorter syntax
It’s easy to use functional paradigms, chain methods and write pure functions.
they make your code much more readable when chaining with other higher order funcions like .map or .filter
Just consider how readable this is:
Constructor assignments are cool too
In typescript you can save yourself a lot of typing when you use constructor assignments. Just add private or public in front of an argument and it will be available as a local variable on the class. These two examples are equal:
Have a look at the available compiler options
TypeScript is very flexible and lets you adjust a lot of the strictness that you want to maintain in your application. Here are some features that we played with and decided to turn on:
Over the last decade or so, we’ve seen a tremendous increase in possibilities about what is possible in regards to fonts on the web. Online repositories like https://fonts.google.com/ or adobe typekit keep expanding the possibilities of fonts that we can use on the web. But how does it look with fonts that don’t use western alphabet, but rather something like 가, 나, 다, 라, 빨? Not so bright unfortunately.
What are web fonts built with?
In fonts, each character is called a Glyph. Imagine little vectorized drawings (points, lines, curves, angles) that are then displayed by your computer. The alphabet in english and most western languages consists of somewhere around 30 characters. Double that for upper and lowercase, and you have the number of glyphs required to draw a font. An example of a small font from Google web fonts is ‘Bubbler One”. It will only add 10KB to the size of your website.
The size of Korean fonts
The Korean alphabet (called Hangeul) contains a lot more characters than this. A font for the Korean alphabet could support up to 11,172 characters. For web fonts, this will of course grow the size of the file significantly. The smallest korean web font I’ve come across was Ticket Monster’s Tmon at 5 MB. This size will increases the download time of your website and if there’s one thing everybody hates it’s a slow loading website. Googles’ open source “Noto CJK” font even amounts to a whopping 99 MB. Those sizes are just too large to make users download them when viewing a website.
So how do you build nice looking websites in Korean?
In Korea, I’ve seen three aproaches to make websites look nicer. I will explain them and point out some advantages/disadvantages to the solutions.
1. The “one image” sledgehammer approach
This one is commonly found on all sorts of e-commerce websites in the country. The idea is that you create one big image in photoshop. This way, you can put all the product images, descriptions, fonts, icons, features, special offers, conditions (and whatever amount of lens-glare or sparkles you want) in there. Then upload this image as your product description on to the e-commerce site. I downloaded an example of this and put it here.
Pros:
Free choice of fonts
It will look the same in any browser
Easy to upload for the vendor/merchant
Cons:
You can not link parts of your image to different locations
The content does not adapt well to small screens so users need to scroll sideways or zoom in and out a lot
The text is not indexed by any search engines
Very hard to maintain or update. Each time you want to change a word or a price, you need the help of a designer
Customers can not copy/past parts of your product description, which they would do for all kinds of reasons. (send it as email, tweet it, translate, etc)
2. The strict western “text for text, images for images” approach
This is what we are mostly used to in the west. You use text as regular html content whenever possible and images for single elements in the content like pictures or logos. The most common places where you would see this approach is content heavy websites such as newspapers (http://news.joins.com/article/21675296?cloc=joongang|home|newslist1) or blogs (http://blog.naver.com/woksusu/221031724093)
Pros:
Indexed by search engines
Easy to update and maintain
Can contain links inside the content
Easily scales to mobile screens
Users can interact with the content (mark, translate, share)*
Cons:
Can look very inconsistent or just ugly on devices with few korean fonts installed
(* it should be noted that a lot of korean websites are still employing the practice of restricting people’s browser functions such as completely disabling the right click)
3. The hybrid approach
This one I have seen increasingly on newer Korean websites that are more tech oriented. Especially in combination with flat design. Most of the written content will be text based and given some space to breathe. Headings, Links and Navigation elements that don’t change too often are displayed using rendered text in sprites. For example Kakao uses a combination of the two.
Kakao is South Koreas leading chat, social commerce and upcoming payment platform.
The navigation on the left including the title are displayed using this single sprite image here:
I appreciate the pragmatic approach, and as a bonus, the content is much more searchable by search engines. get to use different html tags with alt-texts or content that can be better indexed by search engines than just one big image.
Pros:
Ability to use any font for small parts of the website
Indexing by search engines will work OK
Looks the nicest
Cons:
Very tedious to set up and even more if they decide to change the look of the site.
Other leads
While researching for this article, I found an interesting thing in Wikipedia:
Of the 11,172 possible Hangul syllables, the most frequent 256 have a cumulative frequency of 88.2%; with the top 512, it reaches 99.9%
So maybe someone could come up with a subset of the most common 99.9% characters and then find a solution for whenever that doesn’t work. (maybe including the missing characters as a separate resource whenever they’re needed?)
Basic font groups according to W3C recommendations
Apart from the explicit font names like “Verdana” or “Helvetia” there are the so called Generic Font Groups. Like serif, sans-serif, cursive, fantasy and monospace. The actual fonts that will be used for this depend on what you have installed on your machine or what your browser wants to do with it. And in most cases they are not the prettiest choices. Here is an example of those basic fonts on my “US system”.
Those font groups will also work for Korean content. But as it is in english, the aesthetic choices and the visual end result are far from what most clients or website owners would like to see on their online presence.
This is a quick recollection of the steps it took to set up Cloudflare for a website that is using Apache on a DigitalOcean Droplet.
What is a CDN and why do I need one?
If you’ve never heard of a CDN or have but are not sure what it is, here is a small explanation. A CDN is a global network of servers that helps distribute your website content to different places across the globe. Most websites start off on a single server. If you set up your own website, you will usually start with a hosting provider and a domain registrar. At the domain registrar you enter the address of the hosting provider’s DNS servers and/or IP addresses. Sometimes you can have both services from a single company. This is so that when somebody types www.yourwebsite.com the request is correctly routed to your webserver.
In this setup, every visitor to your website will be served by your single server that you rented from your hosting provider. If your hosting provider is in Texas, and your website visitor is in Tokyo, Japan, it will naturally create a little bit of a delay in the communication that happens behind the scenes. The bigger the website you’re serving, the longer it will take to load everything between Texas and Tokyo. Now if you wanted to speed up the loading times for your Japanese visitors, you could set up another server in or close to Japan. But that would be a lot of work and it wouldn’t help your other visitors who might be in South Africa or in Norway.
A Content Distribution network will sit between your hosting provider and your visitors. Because it is a Network, it’s servers are distributed and it will be able to serve your content to much more places, and much faster than you could by setting up a server in every country. Here is an image that I took from Cloudflare’s website and it explains the setup very well I think.
How does the setup process work?
If you’re running a simple website with some information and pictures on it that are not using a secured connection, it’s fairly easy.
Create a cloudflare account
Get your new nameservers from cloudflare
Enter your nameservers in your domain registrar‘s administration panel.
Log in to cloudflare and set up your domains and subdomains
Be sure you recreated all the DNS entries from your old domain registrar. For example, if you are using Google Apps for work, you also have to set up your MX records in your cloudflare account.
What if I use a secure connection over HTTPS?
This was the case for the site I was moving. Cloudflare has a couple of options in their management. They are mostly concerning what certificate to use (cloudflare vs. your own) and what part of the connection should be encrypted with with certificate. Because there are two parts in the connection.
User <-ssl-> Cloudflare <-ssl-> Your Server
Time required to issue a new certificate
If you are using the option Full or Full (strict), Cloudflare will require some time to issue a new certificate. In our case, for the first 24 hours, our website was showing the scary “Your connection is not private” message in all browsers. During that time, the SSL settings in the Cloudflare management screen were saying “Issuing new certificate” or something similar. It was eventually resolved automatically, but this is a very important factor if you’re migrating a website in production.
Ever since I started using WordPress as something different than just a blogging platform, there was a clear upside and a downside to it.
What I love about WordPress
It’s amazingly easy to manage your content. Mainly for two reasons.
Firstly, the backend has proven itself over and over again. It can be learned by anyone in a few hours. Which makes it almost unnecessary to explain to even inexperienced users.
And secondly, custom post types and taxonomies are a concept that is a bit hard to grasp in the beginning. But it allows for a lot of flexibility. Additionally to Posts and Pages, WordPress can be used to manage a lot more things. Products? Events? Movies? … Pets? You name it.
What I don’t like about WordPress
The template system and querying data is a mess. There is this magical thing called “The Loop” that sets up something like a context for your template. Then you can get things like “the_content()” which automatically prints it out to the frontend. This probably makes the learning curve a little bit less steep for newcomers. But for people who are used to work with MVC patterns and like the separation of data, logic and content, it is a nightmare.
There’s no real business logic layer. If you want to build application like features into your website you have the choice of adding it either to your template, or putting it in a plugin.
You want to add automatic unit tests for the code that you wrote for your application? Sorry, we don’t do that here.
Separating one from the other
With the last releases, WordPress has been adding a feature to it’s core that has transformed web development in the last decade or so. It now finally has it’s own API. Using this piece of technology, you can finally get the data out of WordPress and display it in any application you want. A mobile app, another website, anything with access to the internet can now show what you are managing in side your WordPress website.
This allowed the people at https://bocoup.com to build an amazing project. They had to add content management to an existing web application. But instead of trying to create their own, they looked to the old but reliable and proven WordPress backend. Using the API they were then able to manage their content inside WordPress, but display it on their custom built web application. They even created an npm package to call WordPress API from node applications under https://github.com/kadamwhite/wordpress-rest-api. And it’s as easy as this:
wp.posts()
.type('movie-review')
.author('florian')
.perPage(5)
.tag('comedy')
.then(function(movies) {
// Do something with the returned movies
});
Conclusion
I think this is the biggest step forward that WordPress has made in the recent years. The code architecture might still not be to everyone’s taste. The template engine is still the same. But the API is breaking up that monolithic piece of software that it was. Adding a lot of flexibility to it and ultimately paving the way for a brighter future. I am really excited to see what other applications for it are going to come out in the future. And I would love to build an application that makes full use of this.
Here is the whole presentation K. Adam White gave at Wordcamp San Francisco:
