Published on June 12, 2022.

Here's a follow-up to this post, with questions that I've received about SuiteFrame.

Today I'm happy to announce that I've released SuiteFrame, a framework for developing NetSuite-native applications.

SuiteFrame is really more of a methodology than it is a formal software development framework. There are no strict rules to adhere to, no libraries that you must use or can't use. SuiteFrame essentially provides a structure that you can build a NetSuite solution on - a structure that I believe is both flexible and sturdy.

My goal in developing SuiteFrame is to help developers use their Web development experience to build modern NetSuite-native solutions - solutions that include modern interfaces, that are performant, and that are responsive.

Here's a short video that shows a sample app that I developed using SuiteFrame.

SuiteFrame's Origins

Many of concepts on which SuiteFrame is based originated in and were initially visible in the SuiteQL Query Tool. While developing the most recent version of the tool, I started to experiment with how the app was structured, both in terms of the back end and front end. My only real limitation - which was somewhat self-imposed - was that the application had to consist of a single script. I felt that was important because it would make the distribution and installation of the app much easier. I'm not associated with a NetSuite partner, and I'm not a NetSuite customer, so providing the app as a bundle wasn't an option.

Needless to say, that constraint did make developing the tool difficult. But while working on the SuiteQL Query Tool, I was able to prove that some of the ideas that I had been curious about were actually viable. For example, I was able to use popular Javascript libraries, such as Bootstrap and Datatables, for the user interface. I was also able to implement an idea that I had where a single Suitelet could serve to both initialize the app and act as its API, thus avoiding the need for a RESTlet.

However, I was anxious to take some of those ideas and concepts, and use them without that single-file constraint. And so late last year, I built a few proof-of-concept apps that split an app's code into more logical, manageable pieces. The result was a much more modular architecture, and SuiteFrame started to take shape.

Since then, I've used SuiteFrame on about a half-dozen client projects, and with great success. My clients like the look and feel of the apps, their speed, and, of course, the lower development cost.

In fact, several of my clients have asked for additional SuiteFrame-based apps that are intended as replacements for standard NetSuite functions. For example, one client has asked me to develop a SuiteFrame-based app that will replace NetSuite's standard Sales Order list, view, and edit functionality.

About SuiteFrame

SuiteFrame can be used to build internal applications (requiring a user to be logged into NetSuite), as well as external, public-facing applications. With regards to external apps, you can present them using the technique that I shared back in January (NGINX As A Reverse Proxy for NetSuite), which gives you the ability to serve up an app behind a reverse proxy server.

When SuiteFrame is used to develop internal apps, you get all of the benefits that NetSuite normally provides to developers, including security (authentication and permissions), session state, and so on. Internals apps can be rendered within NetSuite's standard interface - which I sometimes refer to as the NetSuite's "chrome" - or rendered outside of the standard UI. In other words, you can completely "break free" of any of NetSuite's normal UI-related constraints.

With SuiteFrame, a single Suitelet serves to initialize the app, load its UI elements, route GET and POST requests, and act as an app's back end API. Best of all, NetSuite's native security model is used, as are standard Suitescript modules.

In terms of the user interface, you can choose to generate views using server-side techniques, client-side techniques, or any combination of the two. In the example app that I'm sharing below, you'll see that for the list view, I'm generating the interface entirely on the server-side. For the detail view, the interface is generated client-side (using Handlebars). I'm also using Bootstrap, just as I did in the SuiteQL Query Tool. This makes the design and layout of the detail view much easier, and responsive. (Well, for the most part anyway.)

For the list view, I'm using DataTables. If you've used the SuiteQL Query Tool, then you might find this to be familiar. It's essentially a Javascript library that can be used to enhance a standard HTML table, providing automatic pagination, sorting, keyword search, and other functionality.

The ability to use whatever libraries you choose, and whatever techniques you'd like, is something that I really like about SuiteFrame - and I think other developers will like that, too. Use whatever you want, whether it's a technique, a library, etc.

About The Sample App

I'm making a SuiteFrame sample application available under an MIT license. For the most part, it should "just work." The application is basically an Employee Directory, a use case that I chose because all NetSuite accounts have employee records (of course!) and because I think I can rely on them having a fairly standard structure. That said, you might need to make minor changes to the SuiteQL queries, especially if you aren't running in a One World account.

The app initially displays a list of all employees, and again, it uses DataTables to provide a nice user experience - pagination, keyword searching, sorting, etc. In a future version, I'll show how you can add support for filters. But for now, using the keyword filtering provided by DataTables is a good start.

You can click a link in the list view to "drill into" a detailed view of an employee. And again, I'm using Bootstrap and Handlebars on the detail view.

When viewing an employee, you can edit their notes. A simple form is presented via a Bootstrap-based modal window. When you submit the form, an API request is sent back to the app's core Suitelet, where it is processed, and the employee record is updated. I'm using Boostrap's new "Toast" support to display a notification to the user when the record has been successfully updated on the back end.

Downloading the Sample App

The app can be downloaded here:
https://tdietrich-opensource.s3.amazonaws.com/suitescripts/suiteframe-v1-r0.zip

The app consists of several files, including:
• employee-directory.core.suitelet.js - initializes the app, routes requests, delivers views, and processes API requests from the client side. When installing the app, this is the Suitelet that you should create a script and deployment record for.
• employee-directory.css - a simple stylesheet used by both the list and detail views.
• employee-directory.library.module.js - a library of helpful functions used by the app.
• employee-directory.ui-detail-view.module.js - handles the generation of the detail view.
• employee-directory.ui-detail-view.template.html - the client-side HTML, CSS, and Javascript file for the detail view.
• employee-directory.ui-list-view.module.js - handles the generation of the list view.
• employee-directory.ui-list-view.template.html - the client-side HTML, CSS, and Javascript file for the list view.

I recommend that you place all of the files in a single subfolder within the File Cabinet's SuiteScripts folder, as shown below.

Wrapping Up

Over the past year or so, I've come to see NetSuite as much more than an ERP system. I now see it as a full-blown Web development platform. This has completely changed the types of applications that I build for my clients and how I build them. I hope that by sharing SuiteFrame, it will help other developers see NetSuite this way as well.

I've been using SuiteFrame on single page apps, as the foundation for public-facing Web apps, and more. I can't wait to see what other developers do with it.

If you have any comments, questions, or suggestions, please feel free to reach out.