As a warning, this article assumes certain knowledge. This link should provide you with any background or refresher information if needed.
This is the second article (but only half step forward) in an ongoing series, please visit here to read the first article. This article is intended to give some background on what Server-side JavaScript is and basics to help make the next article make more sense.
JavaScript and Server-side Code Refresher
JavaScript is a cross-platform, object-oriented scripting language. An Object Oriented Programming (OOP) language is defined if it can provide the following four basic capabilities to developers: Encapsulation, Aggregation, Inheritance and Polymorphism.
JavaScript is designed for embedding in other products and applications – such as web browsers. It is heavily intertwined with HTML and CSS, but focuses mostly on creating dynamic and interactive elements.
JavaScript contains a core set of objects:
These objects are the base objects for JavaScript to operate and interact with the environment. There are other ‘built-in’ objects that are available, but there are too many to effectively list out here. Here is a good link to check out a list. Please note that some of these are not available sever-side.
JavaScript allows you to implement complex features utilizing:
- storing information in variables
- operations and evaluations
- event based scripts
- Application Programming Interfaces (APIs)
JavaScript contains two different contexts – server-side and client-side. Vanilla JS is shared between the two contexts, but most have their own libraries/environments specific to the context.
Client-side code is code that is run on the user’s computer — when a web page is viewed, the page’s client-side code is downloaded, then run and displayed by the browser. It is mostly for displaying and manipulation of HTML in a windowed environment.
This environment is run solely in the browser or ‘local user’ environment and is dependent on the browser/software that the user has. This means that all of your JavaScript is then fully exposed for the user to see via source code. Any information you use in your scripts, such as user/pass, will be able to be viewed by any visitor of the site – opening up security risks.
Server-side code in contrast, is designed to work with resources outside the windowed environment – utilizing the ‘home’ server environment. It is able to interact with relational databases, API calls to other systems, or manipulate objects on the server prior to response rendering.
Generally, server-side Javascript is run in a specific environment (like Node.js), which is run differently than vanilla JavaScript. The server script is not passed along to the requester, only the results of this scripting. So you can utilize ‘sensitive’ information in here (with appropriate security measures) without worrying that the end user will be able to see it.
How is Server-side Run?
Server-side JavaScript contains the same core language as the client-side version, but it does not include DOM (Document Object Model) or BOM (Browser Object Model) capabilities.
Overview of Runtime processing: (for example, a web page)
- User accesses the URL via Browser. The browser sends request to server for page
- The server finds the appropriate file and begins processing
- The runtime engine constructs the HTML page that will be sent over
- It first begins with those that are set to run at server
- It then compiles the results of this along with the remaining HTML/CSS/JS to be shared
- The runtime engine sends the new, compiled HTML page to the client
- The web browser then interprets all client-side JS that was in the compiled page, formats the HTML and then displays the page
As you can see from above, the SSJS is run before the HTML page is compiled fully and sent to the browser. Essentially what it does is scan the page from top to bottom and each time it sees a runat=server it will then process and output that script instead of moving it across as content.
It then continues on with the scan until it reaches the end of the file. At this point it will have the ‘final’ rendered page that it sends back to the browser where then all the client-side scripting is run and processed.
Hopefully soon I will release the next full step forward to the basics of utilizing SFMC Server-side JavaScript.