DEV Community: Marble IT

Hosting NodeJS application on Windows server

Marble IT — Mon, 03 Jun 2024 11:50:46 +0000

Yes, I know, I know—why would anyone ever like to host NodeJS apps on Windows, right? Well, you obviously haven't had a client who already has a Windows server (probably because of existing .NET applications on it) and wants to host one more app on that server. And that app is written in...(drumroll sound in the background)...NodeJS. Believe me, be thankful it's not WordPress; we'll cover that in another article.

But if this is the first time this scenario has happened to you, Welcome to the world of commercial programming!

This short guide will help you set up Express applications on that Windows bad boy in no time. Let's go through the steps:

1. Install IISNode on the server

IISNode is an open-source native IIS module written in C++ that allows node.js (node.exe) to be run inside Windows IIS. If you don't know what IIS is, you should read an article about it first.

Download and install iisnode via the releases page. Feel free to choose the latest version, and make sure to pick the correct binary package for your architecture (x86/x64).

2. Tell IIS that you want to use the IISNode module for app.js requests

You can easily do this by adding the following line to your web.config. If you don't have a web.config file, create an empty one and add this line:

<add name="iisnode" path="app.js" verb="*" modules="iisnode" />

Your web config should look something like this:

<configuration> <system.webServer> <handlers> <add name="iisnode" path="app.js" verb="*" modules="iisnode" /> </handlers> </system.webServer> </configuration>

3. You can use the URL Rewrite

You can use URL Rewrite (IIS native module) to choose which requests get handled by iisnode and which requests will skip iisnode. This is required when setting up a socket.io server inside iisnode. In this case, your web.config would look something like this:

<rewrite> <rules> <rule name="app"> <match url="app/*" /> <action type="Rewrite" url="app.js" /> </rule> </rules> </rewrite>

4. Set up additional parameters

This is an introductory article, so I won't discuss theses parameters in depth, but here is a list of parameters and their default values for IISNode:

It is important to set up these parameters properly in different scenarios. For example, you can alter this variable:

<attribute name="nodeProcessCountPerApplication" type="uint" defaultValue="1"/>

n order to tell IISNode how many instances of the app it should spawn (similar to PM2 on Linux). It can easily serve as a load balancer!

There are multiple benefits of using IISNode (quoted from the official documentation page):

Process management. The iisnode module takes care of lifetime management of node.exe processes making it simple to improve overall reliability. You don’t have to implement infrastructure to start, stop, and monitor the processes.
Side by side with other content types. The iisnode module integrates with IIS in a way that allows a single web site to contain a variety of content types. For example, a single site can contain a node.js application, static HTML and JavaScript files, PHP applications, and ASP.NET applications. This enables choosing the best tools for the job at hand as well progressive migration of existing applications.
Scalability on multi-core servers. Since node.exe is a single threaded process, it only scales to one CPU core. The iisnode module allows creation of multiple node.exe processes per application and load balances the HTTP traffic between them, therefore enabling full utilization of a server’s CPU capacity without requiring additional infrastructure code from an application developer.
Integrated debugging. With iisnode integrated debugging you can debug your node.js application deployed to IIS from a browser running on Windows, Mac, or Linux. You get this support out of the box, no extra configuration or installation is necessary. The solution is designed in a way that is shared hosting, firewall, and proxy friendly. The integrated debugging in iisnode uses node-inspector by Danny Coates.
Auto-update. The iisnode module ensures that whenever the node.js application is updated (i.e. the script file has changed), the node.exe processes are recycled. Ongoing requests are allowed to gracefully finish execution using the old version of the application, while all new requests are dispatched to the new version of the app.
Access to logs over HTTP. The iisnode module provides access the output of the node.exe process (e.g. generated by console.log calls) via HTTP. This facility is key in helping you debug node.js applications deployed to remote servers.
Minimal changes to node.js application code. The iisnode module enables hosting of existing HTTP node.js applications with very minimal changes. Typically all that is required is to change the listed address of the HTTP server to one provided by the iisnode module via the process.env.PORT environment variable.
Integrated management experience. The iisnode module is fully integrated with IIS configuration system and uses the same tools and mechanism as other IIS components for configuration and maintenance.
Other IIS benefits. Port sharing, security, URL rewriting, compression, caching, logging

I hope that you've managed to set everything up. For a further dive, you can read the official Github README.md. If that does not help, feel free to contact us!

Ivan Kockarević

Elastic Beanstalk: Developer's AWS paradise

Marble IT — Mon, 03 Jun 2024 10:24:56 +0000

Beanstalk in a nutshell

Starting with the cloud can be pretty intimidating because of all the fancy words you hear while learning. Auto-scaling and resource provisioning are just a couple of phrases that may be confusing for new developers. Besides that, most developers just want their code to run without digging deep into hosting technology, especially when deadlines are approaching.

Enters the room, Elastic Beanstalk. It is a managed service that helps developers run their web applications fast and without worrying about best practices in the AWS environment. It is used by both new and more experienced developers since it is easy to set up but also rich with features so you can tailor your system to your custom needs.

But first, what does managed service even mean? It means AWS itself is managing everything. You don't need to worry about updates, security patches, and every other detail essential for running the application securely and consistently.

What is your job, then? Provide an overview of what your system needs and upload code. It is that simple. You simply upload your code, and Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, and automatic scaling to web application health monitoring.

How it works?

Beanstalk works with the application/environment model. You create your application, and then you can have multiple environments for it. This basically means you can have completely different system architectures for different environments. For example, your server could run in only one instance for the development environment but have scaling functionalities implemented for production. And what do you need to do there? Just pick the options for scaling. Pick how many instances should be running minimally and maximally. Pick the thresholds for spinning new instances and terminating unused instances. Everything else is managed by Beanstalk itself.

You have the freedom to choose the deployment options for your applications. Some of them are all at once, Rolling, and Blue/Green. These will not be covered in this blog post, but they are mentioned to point out the vast range of features Beanstalk has.

Supported Platforms

Beanstalk supports a wide variety of platforms. The list is as follows:

GO
JAVA SE
JAVA Tomcat
.NET with IIS
NodeJS
PHP
Python
Ruby
Packer builder
Single Container Docker
Multi Container Docker
Preconfigured Docker

New platforms are added constantly. There is also one nice feature that makes Elastic Beanstalk perfectly capable of every need you can think of. It is called a Custom platform. You can completely configure the platform you need for your applications. This is very important for companies that have a lot of custom system configurations. The custom platform has a major drawback though. It is seen as a very advanced feature which means that it is not easy at all to create your personalized platform.

Beanstalk CLI

We can install an additional CLI called the EB CLI, which makes working with Beanstalk from the CLI easier. It’s helpful for your automated deployment pipelines!

After configuring the environment, you can set up one command to deploy your whole application.

Creating your first Beanstalk web app

Starting point

First, log into your AWS account and search for Elastic Beanstalk.When you land on the EB service home page, click on Create a new application.

You will then be redirected to the page shown below:

This is where you give your application a name, pick a platform, and upload your code. This is basically all you need to do for your application to be deployed. Of course, you can manually configure it in more detail by clicking the Configure more options button. This is what we will do to check more in-depth configurations.

As you can see, you can use the Sample application code. AWS has sample source codes for every platform, so you can learn the most common Beanstalk features without writing any code yourself.

Overview of most common environment configurations

After clicking on the Configure More options button, you will land on the Configure environment page:

This is where the magic happens. As you can see, configurations are categorized, making it easier to configure individual resources for your application.

We will go through the most important ones, but feel free to experiment with them all. Just be aware that, even though Beanstalk is free, resources provisioned by it, that are out of the free tier will be charged, so don't forget to check the pricing pages or erase all of the resources if you are just researching Beanstalk capabilities.

Presets:

Presets, also called deployment modes, tell Beanstalk the overall architecture you want for your environment. Single-instance presets are great for development and testing. As the name suggests, they use one instance (server) to run your web app.

High-availability presets are most commonly used in production. They leverage the load balancer features and use auto-scaling.

Platform:

This is the place where you can pick your platform and its version.

Software:

The software category is used for your software-related configs. In software configuration, you can set your environment variables (called environment properties here). Bye-bye, env files.

Instances:

Here, you can configure your instances' memory resources and public availability. In high-availability applications, it is best practice to keep your instances private while the load balancer is public, which will route all the traffic to your application.

Load balancer:

Load balancer type, as well as listeners, protocols and ports, are configured here.

Capacity:

In the capacity section, you choose your EC2 instance type and system image. This is basically the same old-school EC2 configuration.

Security:

Last but not least, security. This is where the role that performs all the deployment actions on your behalf is created. It is also where you will need to create and assign private keys for SSH access to your instance(s).

After you are ready, click on Create an App and let Beanstalk create every resource for your application. After a few minutes, you should land on the page below, and if everything is OK, your application should be fully deployed.

Use the link below the environment name to visit your Beanstalk application.

Conclusion

This is just scratching the surface of one of the most powerful tools AWS is providing to developers. I hope I can show you how EB can save developers time every day while also being a platform where developers can learn about cloud best practices. Elastic Beanstalk is the service you should definitely have in your cloud tools arsenal.

Aleksandar Polić

Unity UI System - Best Practices

Marble IT — Fri, 26 Apr 2024 09:35:28 +0000

During my development days, I've seen many Unity projects. Sometimes I've made them from scratch, other times I've continued someone else's project.

In either case, when I had other developers in the team, I noticed that a lot of them had trouble with Unity's UI system, whether it's scaling of components, optimizing rendering calls or just plain structuring of game objects.

I noticed that most of them didn't follow any guidelines and just worked based on their feeling of the best practice, which often turned out to be wrong. But that was also true for myself, until the experience taught me better.

What I also found to be the problem is lack of summarized material for my cases, when I didn't want to waste time going through whole documentation. So this is my attempt to summarize key points and solutions that I've acquired over the years.

Disclaimer: note that these are not the official guidelines, and they might not be convenient for every type of project (VR for example) - but these are the ones I've found to be most effective for most projects that will run on screens (mobile, PC, PlayStation, Xbox).

Canvas Component

The only way to start this discussion is to talk about the main UI Component - Canvas. Canvas is the main parent object, that contains all the UI components as children. I will not go into detail about how it works but instead, talk about two key properties when setting it up:

Canvas Render Mode

You can choose among 3 options: Screen Space - Overlay, Screen Space - Camera, or World Space.

The main difference between Screen Space and World Space is that Screen Space will render Canvas in front of the whole game world; basically, it will be fixed on the user's screen in front of everything else. Meanwhile, World Space will be rendered among other objects in the game world, and it can be anywhere, like a regular object that is not a part of UI.

In most cases, your choice will be Screen Space, as the UI components are mostly used for UI indicators inside the game that are always in front of the game world (such as health, inventory, number of lives, timers, etc.).

Canvas Scaler (UI Scale Mode)

This is probably the more important part of the Canvas setup - specifically the UI Scale Mode property. By default, it's set to Constant Pixel Size, which can cause scaling issues upon changing resolutions if left like that. In most cases, UI Scale Mode should be set to Scale With Screen Size, which will give you an option to set default resolution and make objects in UI scale, either with width or height, upon changing the resolution.

Example of Canvas settings for Mobile UI:

One Canvas or Multiple Canvases?

This depends on the use case. Before answering the question, let's talk about draw calls in Unity and re-draws explicitly on Canvas. Let's say that you have one Text component inside canvas which shows the seconds passed since the start of the game. That means that each second, your Text component is going to change. Every time a component changes, the Canvas that contains that Text is completely re-drawn. Now let's say, that you have a few static Image components inside that same Canvas with Text timer. Now, each time a second passes, Canvas is completely redrawn, meaning that not only Text will be redrawn, but all the static Images (which technically don't need that redraw since they didn't change). You can imagine how that issue can scale up when you have multiple components that change inside one canvas - and that's where the second Canvas comes to save the day.

If you have Canvas nested inside a Canvas, when child Canvas is redrawn, the parent Canvas will not be influenced. So the smartest structuring of the game objects would look like this:

This knowledge of Canvas redraw behavior can greatly help when optimizing the game for lower-end devices. Think about it all the time, and it will most certainly improve your game's FPS.

Image Component

Image component is pretty simple by itself. The main challenge is making sure that the image will appear the same on different screens (resolutions). To ensure that behavior will happen, just make sure that Preserve Aspect is ticked. This is how the Image component should look:

The second part of making sure it looks the same on every screen will be explained in the Anchoring section.

Text Component

Like the Image, the Text component is also pretty simple and presents the same challenge - making sure that it looks the same on all screens. This can be ensured by setting a custom Font Size and making sure that Best Fit is unticked! If Best Fit is ticked, the size of the font (text) will vary from screen to screen, as Unity (and Canvas) will automatically change it to what they think is best fit, and you will get inconsistent UI as a result.

Here is an example of how Text component should look like:

The second part of making sure it looks the same on every screen will be explained in the Anchoring section.

Anchoring

Anchors define how your UI component will behave in relation to its parent, and it can be set on each object that has Rect Transform, or in other words, is a part of UI. They look like this by default:

You should never leave them in their default position. By clicking on the Anchor Rectangle in the Rect Transform, you can select predefined anchor positions (top, bottom, left, right, middle, each of the corners, etc.). That menu looks like this:

However, what I suggest to ensure that every object will be placed exactly as you've set it up, regardless of screen resolution is to drag by hand each anchor to the corner of your UI Component. In practice, that would look like this:

This way, however you change the resolution, the object will stay in the same position in relation to its parent.

Conclusion

I hope this basics of UI have covered some of the troubles you are facing and managed to put you on the right way of building the best UI. Happy game creating!

Luka Ćurčić

Test Driven Development

Marble IT — Thu, 25 Apr 2024 08:23:29 +0000

After working on multiple projects, I was able to see what difference writing tests make. Sometimes, it seems like writing tests would just eat up a bunch of time and that it's good to test features yourself. But as the project gets bigger and more complex, it's harder to make sure that the code you wrote doesn’t affect other parts of the project.

One project I worked on had many features that affected each other, and our client wanted some significant changes that could break other features. Shortly after, bugs came along, and at this point, we couldn't recall why something was written the way it was and where else it was used. After implementing the change you have been asked to, you test it, and everything seems okay - or so you think. Suddenly, someone reports that other parts of the application are broken, and you find yourself wasting hours on something a test would notify you about in seconds.

This happens a lot. Programmers are being pressured to ship code as fast as possible and often don't push back and negotiate realistic estimates. And then you start to hear, “TDD is a waste of time because I can’t code that fast.” But in reality, you would have code that is easier to refactor and be sure that changes won’t affect the project. You'd spend far less time debugging.

So, what is Test Driven Development?

TDD is an innovative software development approach in which you write tests before writing the bare minimum of code required for the test to be fulfilled. In simple terms, test cases are created before code is written. The purpose of TDD is to make the code clearer, more straightforward, and bug-free. TDD starts with designing and developing tests for every small functionality of an application. The simple concept of TDD is to write and correct the failed tests before writing new code. This helps to avoid code duplication as we write a small amount of code at a time to pass tests; TDD sometimes is also called "Test First Development."

Why use TDD?

The short answer is “because it is the simplest way to achieve both good quality code and good test coverage.”

The longer answer comes from what TDD really is.

For start, you need to follow these rules:

You are not allowed to write any production code unless it is to make a failing unit test pass
You are not allowed to write any more of a unit test than it is sufficient to fail, and compilation failures are failures
You are not allowed to write any more production code than it is sufficient to pass the one failing unit test.

The rules define the mechanics of TDD, but they are definitely not everything you need to know. The process of using TDD is often described as a Red/Green/Refactor cycle.

The red, green, refactor approach helps developers compartmentalize their focus into three phases:

Red – think about what you want to develop
Green – think about how to make your test pass
Refactor – think about how to improve your existing implementation

The red phase is always the starting point of the cycle. The purpose of this phase is to write a test that informs the implementation of a feature. The test will only pass when its expectations are met.

For example, imagine you want to create a function called sortArray that sorts the numerical values of an array in ascending order. You may start by writing a test that checks the following input and output:

Input: [2, 4, 1]
Output: [1, 2, 4]

When you run this test, you may see an error message like:

As you can see, the purpose of this phase was to define what you want to implement. The resulting error message from this test informs your approach to implementation. At this point, you are considered “in the red.”

The green phase is where you implement code to make your test pass. The goal is to find a solution without worrying about optimizing your implementation.

In our sortArray example, the goal is to accept an array like [2, 4, 1] and return [1, 2, 4].

You can approach the problem by writing a loop that iterates over the array and moves the current number over if it is larger than the number to the right. Then nest this loop inside of a loop that repeats until all of the numbers are sorted. After implementing this, you should see a passing test message that could look something like this:

At the end of this phase, you are considered “in the green.”

Now, you can start thinking about optimizing your codebase while having a descriptive test if you do something wrong. In the refactor phase, you are still “in the green.” You can start thinking about how to implement your code better or more efficiently. And by that, I mean how to accomplish the same output with more descriptive or faster code.

For example, instead of using a bubble sort method, you can use the merge sort algorithm because it has a faster average sorting speed than bubble sort.

So, after refactoring the sortArray function and running the test, the test message would look something like this:

Do you notice the difference? Instead of 19 ms, the code now needs only 7 ms to execute.

Summary

In test-driven development(TDD), a test is written first before writing the functional code. This doesn’t mean that TDD can replace traditional QA, but instead, it ensures effective unit testing. An effective unit test will ensure better code coverage, fewer bugs, and QA efforts in the long run. Implementing TDD can be challenging though, because you need people involved who have the necessary skill sets for using different unit test frameworks. If you have the right people, then it’s always good to implement TDD in your projects.

Conclusion

While it’s challenging to learn to use TDD, in my opinion, every developer should be familiar with it. Because in the long run, TDD is definitely not a waste of time, and is a way to keep code clean and optimized. Refactoring code could also cause other parts of the application to malfunction without us knowing. Then, you might have a situation where the project is “finished,” but you get a message from the client saying that something broke, and it is your responsibility to fix that. Most likely, you are already on some other project, so now you have to work on two sides, probably doing overtime, and at that moment, you realize that if you had written tests, this wouldn’t have happened. You already wasted more time on solving bugs, than just writing tests from the beginning.

But what if you are working on a small app, that has few features and is not that complex. Is there a need to write tests for it? No, it's up to you or your team to decide if TDD will take more time or save it.

The bigger the app, the more likely TDD will save you time and stress.

Aleksandar Tišma

Application of S.O.D. in frontend development

Marble IT — Mon, 22 Apr 2024 09:31:56 +0000

In this post, we will show that SOLID matters for every software engineer, regardless of the area of expertise. In web UI development, engineers mostly work with HTML, CSS, and client-side JavaScript, which do not necessarily require knowledge of object-oriented design. This leads to engineers who never get in touch with SOLID, and less code quality in general. Let's fix this by introducing some of the principles that are a must in client-side development.

Motivation

By knowing SOLID, you enhance the quality of your code in many ways - you benefit from readability, maintainability, minimal repetition and redundancy, agility, and cost of development in general. Not to mention the stress relief during RFCs (requests for change) and code maintenance!

Principles are initially easy to adopt, but once you get better at them, they will reveal more and more things.

Introduction

The term "SOLID" was first introduced by the famous engineer Robert C. Martin. It marks a set of five principles that lead to better code quality. Although they are mostly followed in object-oriented design, they are also useful in front-end development.

These principles are not rules, they are tenets that engineers need to adopt and use responsibly in their projects.

The acronym "SOLID" stands for:

Single responsibility principle
Open-closed principle
Liskov substitution principle
Interface segregation principle
Dependency inversion principle

Liskov substitution and interface segregation principles are more related to object oriented design and aren't that crucial in frontend development, but, of course, in larger frontend applications, you will also find those. For today's post, let's go through S, O and D!

Single responsibility principle

This principle is really easy to adopt and demonstrate through simple CSS. The principle itself states that every module we write (classes, functions in JS, or even CSS selectors) should have one responsibility or, to be more precise, one reason to change. This means that we shouldn't write complex ninja classes, functions, or selectors that do and define everything. Instead, we should dissolve that module into smaller modules, each having one functionality. A level of separation of the modules in your code is called "granularity." As an engineer, it is your responsibility to find a perfect level of granularity for your project. Don't be stingy, but do not go nuts.

Let's illustrate this principle with a CSS example. Let's imagine that we have a button in our project, that should be 40px in height, 100px in width and always red. We can write this in CSS:

> .btn-red { 
    width: 100px; 
    height: 40px; 
    background-color: red;
}

Now, a realistic scenario is that, at some point, we will have an RFC for a new button color, let's say blue. In that case, assuming that we cannot change our old code due to the fact that it is used all over the project, we can write something like this:

.btn-red { 
    width: 100px; 
    height: 40px; 
    background-color: red;
}

.btn-blue { 
    width: 100px; 
    height: 40px; 
    background-color: blue;
}

This is not good since we duplicated some of our previous code. This is a small duplication, but it can become larger and create more significant problems. For example, you can have buttons in 10 colors, and you need to change their height to 30px. You would need to write that change in 10 places in your code. Let's take a look at a better example.

We could follow the "S" principle and write our initial code like this (separated functionalities):

.btn { 
    width: 100px; 
    height: 40px;
}

.btn.red { 
    background-color: red;
}

With the properly granulated code, we can easily do something like this:

.btn { 
    width: 100px; 
    height: 40px;
}

.btn.red { 
    background-color: red;
}

.btn.blue{ 
    background-color: blue;
}

We didn't change our original code, but we added a new feature, without code duplication. This is the point of single responsibility!

Important thing to note: we could granulate our code even further without getting any benefits. For example, we could've written something like this:

.width-100 { 
    width: 100px;
}

.height-40 { 
    height: 40px;
}

And so on, for every CSS property. This level of granularity brings no value to our specific scenario, so watch out, do not over-engineer.

Open-closed principle

This principle states that the code that you write should be OPEN for EXTENSION and CLOSED for MODIFICATION. What this basically means is that the developer that continues the work after you doesn't need to change the existing code but should be able to easily extend it. We can illustrate this principle on the exact same CSS example as the previous one.

By writing code like this, we allow the next developer to easily extend our code and add a new color:

.btn { 
    width: 100px; 
    height: 40px;
}

.btn.orange { 
    background-color: orange;
}

.btn.custom{ 
    background-color: #f2f2f2;
}

On the other hand, our original example was CLOSED for extension.

Dependency inversion principle

Well, this principle comes in naturally with JavaScript since it doesn't support types, so there isn't much point in mentioning it in a JS context. But if you are using TypeScript, you need to know this principle!

The dependency inversion principle states that nothing should depend on concrete implementations but on abstractions instead. What this means is that if you are using a certain module in your code, like FacebookService (e.g., for some logic related to Facebook SDK), it should reside behind its own abstraction (e.g. SocialNetworkService), so the actual implementation is minimally mentioned in the code. The reason to do this is to achieve an easier switch if, at some point, that FacebookService needs to become, let's say, Google Service.

To follow the dependency inversion principle, you'd first need to create your interface with the same method signatures as the original implementation. Second, your concrete implementation should extend your newly created abstraction. Third, you'd need to write the logic in your code to ensure that a concrete implementation is returned each time someone requests the abstraction. Let's see how we can achieve this in TypeScript:

At first, we will have a concrete service that looks something like this:

export default class FacebookService { 
    login() { 
        // Some logic with Facebook SDK 
    }
}

Then, we need to create our interface:

export default interface SocialNetworkInterface { 
    login: () => void // The only important thing is that the method signature is the same as the concrete one
}

Then, our concrete implementation should extend the interface:

export default class FacebookService extends SocialNetworkInterface ...

And, last but not least, we need to create a way to always get our concrete implementation behind our abstraction. We can use a factory method to do this:

class SocialNetworkServiceFactory { 
    getService() : SocialNetworkService { 
        return new FacebookService(); // This is the only place in the code where the concrete implementation will be mentioned so that it can be easily swapped with GoogleService 
    }
}

export default new SocialNetworkFactory();

So, when we want to use our FacebookService in our code, we would write something like this:

let socialNetworkService: SocialNetworkService = socialNetworkFactory.getService(); // This will create a FacebookService, even though we haven't mentioned it in this line. A job well done!

Some will argue that this isn't, in fact, dependency inversion, but a simple factory method instead. To them, I say - Do not mix dependency INVERSION with dependency INJECTION. Dependency inversion is a PRINCIPLE (that we achieved with this solution), and dependency injection is a PATTERN that is used in some technologies to achieve dependency inversion and inversion of control.

Ivan Kockarevic