Node Congress

Node Congress 2022

NodeJS is a server-side representation of Javascript that can work well as an application's backend and can be run on various servers and infrastructures. In this talk, we'll be going through the journey of how Nodejs has been deployed over the years via various infrastructures from PaaS to Containers. You can check the slides for Shedrack's talk <a href="https://drive.google.com/file/d/1olBLlCmJKzr-0sYw6olVJP6Nju4aDiQl/view?usp=sharing">here</a>.  <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

The Evolution of Deploying Node on Servers and Platforms

Hi friends, welcome to my talk. The title for today is the evolution of deploying node on servers and platforms. Let's get into it. My name is Shedrak Akintayo. I am a developer relations engineer at Platform Message. I also do my bit of technical writing and I like to build communities, which I've done with Facebook, DevCillegos, Open Source Community Africa and DevRel Community Africa. So the table of content for today is we're going to be talking about how node is deployed over the years in various forms. So how it is deployed on a server in a garage and how node has been deployed on monolith servers, how node has been deployed on a platform as a service and how node has been deployed on containers. Then we'll do a quick rundown of how node has been deployed on serverless and cloud function or function as a service. So let's get into it. So the first thing I would want to highlight is that deployment is not easy. Trust me, anybody that has spent time working as a DevOps engineer deploying Node.js over the years, it's not as easy as it is, but thankfully as the year as Node.js evolves, the deployment becomes even easier. So thanks to the evolution of Node.js. So the first thing we'll be talking about is node deployed on a physical server in a garage. So basically building your own server. So before everything else, node used to be deployed on a server in a garage actually. So the pros of it basically is that you have a dedicated node server for just your application. So you have like a lot of bare metal for your application. You can control your node environment to an extent it is secured because you handle everything that has to come with security, which is a really good thing because you do not have to depend on any service provider. Whenever a provider is down, you don't have to worry about it. So this is how it was deployed basically. Node can be deployed on a physical server in a garage. Next up is the cons. So it gets too expensive to set up. The manpower, the technical know-how, it gets too expensive to set up.
And another one is it gets very stressful to manage because you are doing all the work yourself. Engineers are having to do all the work themselves. So this is another issue. And it's harder to optimize because most of the work is being done by you and your team, most of the part. So handling the optimization by yourself gets very, very tasking.

So the requirements then as at the time where nodes used to be deployed on a bare metal, like a window is to be deployed like that now, not just as much as it was before. You need the early versions of node. You need a lot of GPUs. You need RAMs. You need CPUs basically to deploy node on a, to be the physical server for yourself, to deploy node on it. 

So the next up is deploying Node.js on a monolith server. So basically a monolith server consists of all parts of an application deployed on a single server from the backend to the static part of the application. The pros of this particular way of deploying node over the years is that the entire path is in a centralized server and it's always a great choice to deploy node as a monolith. So you can have all your application in a single server, which is really, really great because you can see every single thing you need to see. You can see all your applications coupled together. Then the cons is as the application gets larger, it becomes difficult to update and the memory requirements increase over time. For the requirements, you need a hosting server and Node.js 12 upwards. 

The next stop is being Node.js being deployed on a PaaS. So PaaS for Platform as a Service, also known as PaaS, involves, it provides a broad set of cloud-based application infrastructure and middleware resources via the cloud. Example of PaaS that you might have come across is Platform Message. Platform Message is quite different because you can deploy a PaaS on containers, then Heroku, Vercel, Netlify, et cetera. Now the important, the pro is Node.js can be deployed faster. Then you can also easily add additional data services to your node application. Then the cons is, can be very, very expensive at scale and vendor locking also is another issue. The requirements to deploy node on a PaaS are dependent on what the PaaS provider specifies generally.
Next up is deploying node on a container. Now this is currently the most used way for deploying node on a, or deploying node generally. A container is basically a lightweight piece of software that provides a runtime environment for your application. So Platform.sh uses PaaS, but you get to deploy on container. It's basically a PaaS that you can use to deploy on containers in Kubernetes, then also Docker. The pros, it makes your app, your node app light with a resource efficient. It's easy to manage and control your node infrastructure. Adding external data services with your node app is easier. Now the cons is, can be very expensive at scale and you also have issues with vendor locking. Whenever a vendor has issue, then it becomes a problem. Requirements to deploy node on a PaaS are dependent on the container provider. That's the container provider, whoever is providing the container services. You also get to control what node version memory dig size of your application. Now serverless is what we are basically going to talk about next. So serverless basically involves deploying your application without worrying about servers. Servers are still present, but it's on a as-used basis, which also uses function as a service, which is a serverless way to execute modular pieces of code on the edge. Example is, which we've basically seen is AWS Lambda, which is like one of the most important provider of serverless and serverless.com. Another pro, a pro of serverless is lower costs. You get to build faster, like go to market becomes very, very fast. The backend code is simple because it's mostly in chunks as modular, basically uses modular programming, which functions. So every part of your backend becomes a function. And another part is, the cons of serverless basically is vendor locking, which is one of the major problem of serverless and it's unsuitable for long-term tasks. So in terms of scaling for a very, very long-term tasks, serverless doesn't really do well because it becomes a problem basically, and it becomes very expensive, even though they sell it as something that provides lower costs. So that's basically the end of my talk. I hope you've basically been able to know how Node.js have been deployed over the years as from point A to point B, from on-premise to containers, from monoliths to serverless.
So my name is Shidra Kakinthayo.
I am a developer relations engineer at PlatformSage.
Thank you.

Shedrack Akintayo

Node.js has become an increasingly popular language to build and deploy backend APIs. In a world of legacy CMSs adopting decoupled implementations, plenty of frameworks have sprung up to classify themselves as "headless" CMSs, designed from the start to provide an easy way to personalize content models, administer permissions and authentication, and serve a content API quickly. Strapi, one of the leaders in this space, has recently released their v4 version of the framework, and with Platform.sh it can be deployed alongside a number of frontends within the same project, giving a drastically simplified development experience working with decoupled sites. In this workshop, we'll deploy a Strapi demo application, which has been configured to serve a restaurant review site. Piece piece you will add database services, tests, and frontends, all within the safety of isolated development environments. At the end, each user will have a functioning decoupled site, and some greater understanding of working with decoupled sites in production. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Deploying a decoupled restaurant review site to production with Strapi and Platform.sh

Chad Carlson

JSNation Live

JSNation Live 2020

In this talk, I'd go through the Evolution of JavaScript Tooling and frontend build tools, Javascript itself and the future of them all. Also, Babel and other build tools, what they might most likely be in the future. Also, I'd talk about javascript itself as a language, it's present and it's future. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Javascript Tooling - The Evolution and Future of JS & Front-end Build Tools

Hello everybody, my name is Cedric Aguilentario and today I'm going to be talking about Javascript tooling, the evolution and future of Javascript and frontend build tools. I'm a social developer, I'm a developer advocate, I'm also a guest technical author at Smashing Magazine. So why the web is built? So the essential reasons why we build our frontend code today. So these reasons include dependency management, we need to be able to manage all the dependencies our code needs without having to worry about any of them breaking. We also need transpiling, so we need to be able to use these latest syntaxes without having any browser compatibility issues. Bundling, we need to be able to package all our codes into a central file. Minifying, we need to be able to make the size of our code smaller and have a faster delivery to the client side. Also, one very important part is no module management using the browser. So there are certain browsers that do not have module management, so we need to be able to manage our modules without having to worry about anything. So the story of building the web. So 2005 to 2010 saw the era of the first bundlers. So Dojo was released in 2005 with its own build tool called Dojo Builder, which offers minification, dead code will involve multiple build profiles, module management, and you can even make use of Node.js for faster build. Google Closure Tools was also released in November 2009 by Google and it had a compiler. So this is basically its own build tool which helps remove code, dead code, minimize code, link code, and also optimize code. So problems of the first builder and bundlers, why they weren't perfect. So Dojo Builder was heavy. It relied heavily on Java and had very poor documentation. So Google Closure compiler issues were it was proprietary, obviously it was made by Google and it was some kind of an internal project before it was released to the public. It required Java 2, compile time was really slow, and it had poor developer experience. So 2010 to 2012 saw the come up of Gulp and Grunt. They were the first to try and standardize building usable pipelines on top of plugins. So they also gave developers freedom to write their own build scripts and plugins were also available for, readily available for basic tasks for developers. In 2012, it saw the come up of Babel. So Babel allowed developers to use latest ASX syntax without worrying about browser compatibility issues. It converts ASX syntax to common JS and allowed developers to build custom plugins for their needs. So about 2012 to 2014 saw the come up of Browserify. This was the game changer mainly because of it had the power of NPM as a package registry. It allowed developers to use certain plugins. It had the same syntax as Node.js and it also has ASX module syntax so developers were pretty much happy but it had its own drawbacks. So from 2015 till now, we've seen the come up of Webpack, of how it has grown from version one to currently version five. And it's a lot of corporate giants are currently using Webpack in production. It is faster than Browserify. It has a very cool Webpack development server called Webpack Server and it had features like hot module replacements, code splitting, live reloading, et cetera. And it also had the power of NPM scripts so developers can write their own NPM scripts without worrying about anything. Their own build script basically with NPM scripts. It had plugins for various uses and it also had presets for extending the features of Webpack. It also had a better developer experience than other build tools. It was really, really good for developers. So let's see what the future looks like. So the future. So we have Rollup. So Rollup is a module bundler for JavaScript. It was released about say five years ago and it's easier to learn obviously and it has a very fast build. It offers features like code splitting. It is really, really easy to configure compared to Webpack and it's the perfect build tool for building JavaScript library because it takes small pieces of code and converts it into a very complex file. So Parcel. So Parcel's selling point when it was released about two years ago was that you needed zero configuration so the pain of developers configuring Webpack Rollups did not happen in Parcel. It had a very fast, it had a faster bundle time. It uses multi-core processing. Plugins are not necessarily needed. This is because certain basic tech tasks that require developers to use plugins were already built into Parcel so the need for plugins were not really, really that much. It had an awesome developer experience. It has a very nice documentation for developers and it also has a very nice community. So Snowpack. So Snowpack was recently released. Its selling point is that it does not need bundling during development so it skips that bundling process in development. This is because of the power of ESM inputs, ES module inputs. So it is, I give it the ability to skip modeling and bundling during development although you need to, so it also provided a plugin where you could use either Parcel or Webpack to create your own production builds. It does not have its own custom production build tool currently. It provides instant rebuilds on sale so because there's nothing to rebund you so your change reflects almost immediately. It's obviously a faster build tool and it has out of the box support for TypeScript, JavaScript, JSX and CSS modules so you don't need to install plugins for these particular languages, extensions. So ES Build. So ES Build is basically an experiment. It's still experimental. It's the main aim of the project is just to show how fast JavaScript build tools can be. It is faster than Webpack, Rollup and also Parcel. It is written in Go which makes it really fast because Go compiles to native code and so far we're looking at it to be a very, very bright project. So Browser Import. So Browser Import is basically making use of your modules in your browser and your script tiles in your browser so splitting your code into smaller, smaller pieces and delivering them as modules to your JavaScript, to the web, to the browser basically. So browser support has not really been great but the web is advancing. Browser support for browser imports for ES modules would increase also. So it has a very good advantage like caching so the browser does not, once the modules have been loaded once, the browser does not really need to reload everything unless there's a change in one of the modules. You can also async or defer in the script tag for specify your script, your modules to async or defer which is a very, very cool feature for the ESM, for the ES module basically. And also finally we have bundling free approaches, runtime import system. So basically bundling free approaches basically would use ES modules so you would not need your webpack, you would not need Parcel, you would not need Snow, other build tools for this. You just basically will be bundling directly in the web. So it's basically bundling free. So all of the production, so if you need a production, you would definitely not need a production build. And also an example is Snowpack, so Snowpack is trying to make use of the bundling free approach with ES modules. It is not so much in use yet, it's still kind of experimental and if we are able to achieve bundling free approach, we will have lightning fast builds and also deploy time. So conclusion, so the JavaScript ecosystem, Telecosystem is dynamic. It changes and only the best tools can survive technically. It's basically a composition. So in the future we'll be seeing tools with no configuration, no configuration at all, better customizability, so it gives developer more flexibility to do whatever they want to do, more extensibility features and also faster speeds, blazing fast build speeds. So the kind of build tools developers will use for an application's front end is basically a personal core based on the requirements of the project. It's like choosing what works best for you basically for that particular project and most of the time, selecting developer to build tools are kind of trade-offs. So references and useful resources, so this is kind of, if you need more knowledge on this or what I've spoken on today, you can check out these links. Thank you so much for coming to my talk, I appreciate it and I hope you enjoy the rest of the conference. Thank you.
