Application Architecture for Box Platform Apps

This is the third article of a three-part series on building a custom application with Box Platform.

Part 1 of our series took a look at common Box Platform usage patterns and explored how and why you would use Box Content API in your apps. Part 2 of our series took a close look at the reference architecture of a modern application, and where Box fits in. Now we get to the fine detail of how you would go about building an application with Box, including best practices to ensure that your application is performant and secure.

To refresh your memory, below is the ecosystem for enterprise cloud application development that we covered in our second article.

In this last article in our series, we’ll go deep on the architecture and design patterns for your application; how you can design and build an app against the cloud app Stack outlined above.

Why Legacy Application Architectures Don’t Work

If you were building web applications a decade ago, they probably looked like this: 

Your web “site” was designed by someone who used to design print brochures, and each “page” would be rendered by calling a server that would return HTML that could be displayed. Browsers of the era were quite limited - all of the intelligence was handled by the server. The heavy hitters in your development process were the folks who wrote Back-end processing logic, kept the databases tuned, and managed the web and applications servers (and corresponding network). In these good old days, the biggest performance gains came from reducing database I/O, ensuring that every layer of the page-serving process could be cached. Pages were cut down into fragments, cached at the web server layer where possible, with distributed cache on the application server and careful tuning in the database.

The rise of iPhone is responsible for killing this architecture. There were certainly examples of complex client-side applications before the iPhone, for example Microsoft’s early use of AJAX on the Outlook web client. But the iPhone required a new kind of design. After a (thankfully) brief period of trying to hack the old paradigm onto new devices, using m-dot websites, the era of responsive design emerged.

Responsive design required that designers rethink their process and move away from brochureware design to using interactive tools for prototyping. Responsive design also introduced new techniques for developers, like media queries that allowed for dynamically fetching content as window size and orientation changed. 

But something else was happening that would push design and development teams even further. With the advent of smartphones and then tablets, users became accustomed to highly engaging interactive content in apps. And the contrast between what was possible in a native application, and web content on the same device, was pretty stark. Native apps had access to all of the underlying resources of the device, such as the sensors and actuators, the storage, and the graphics card. Web content could not compete.

Think about it this way: web content was designed to be created on a server and passed down to a dumb browser for rendering. Compare this to an application where the logic runs locally on the device in a tightly controlled runtime Sandbox. HTML5 had no hope of competing, leading to the now infamous decision by Facebook to abandon their commitment to the web and shift their mobile resources to native development. The last few years have been spent bringing web content to parity with native, and as we’ll see, much progress has been made. This evolution is driving a new way of building applications.

Modern application architecture

If the last five years has been about the maturing of the responsive web application, the next five will be about rethinking the underlying architecture and composability of application logic. 

Just try to rationalize for yourself the legacy web application architecture described above, with the ecosystem of enterprise cloud services from the second article in our series. We’re building applications from best-of-breed services running outside your data center. How can that be possible, when in the old days we couldn’t handle the latency from a co-located database server?

High performance from composite applications is the holy grail of software architecture, and we’re now seeing it every day. The architecture to support this kind of application looks like this:

We’ll discuss each component of the stack below, then get into some best practices for building highly performant and secure web applications.

Client Browser

Web browsers have grown up a lot in the last decade. JavaScript performance is getting close to native code. Web developers have a threading model (web workers), sockets ( Websockets), peer-to-peer communication (WebRTC), graphics processing ( WebGL), parallel computing (WebCL), advanced audio and video support, and access to pretty much every sensor on the device. A well designed web application is now indistinguishable from a native mobile application.

It should come as no surprise that we’re seeing a lot of application logic shift to the client. Instead of loading pages all at once, we’re now storing HTML templates locally, and populating the templates with data using JSON services. When the user clicks a button, we don’t load a new page, we pull content (if it’s not already cached to local storage), and update the display.

Using a client-side MVC Framework like Angular, Polymer, Ember, React, Meteor, etc, you can build rich application logic with native performance and even offline capabilities. This is a paradigm shift for enterprise web application developers, it looks much more like how you would build a mobile application for iOS or Android, but it is a critical mindset to ensure that your application meets customer expectations. Especially for customer-facing applications.

We’ll look at client side MVCs in more detail later in the article, when we talk about designing for mobile and offline first. But for now, consider that the bulk of your development effort for a modern responsive web application will be client-side coding, interacting with RESTful services as needed. Assume that you’re going to want a client-side MVC framework and a templating language on the client, rather than generating HTML on the server. 

App Server

Michael Facemire from Forrester recently wrote a piece on Enterprise JavaScript—a must-read for IT leaders today. As mentioned earlier, JavaScript performance has improved dramatically over the last few years, to the point where large scale enterprise applications are being built with JavaScript on the client and the server.

At Box, we see a lot of custom applications built in Python, .Net, and Java from our enterprise clients. We also have a lot of startups and ISVs in our ecosystem, and are seeing a lot of Node.js and Go apps from them. There are two main reasons to choose a JavaScript-based server. The first is that more and more business logic is moving to the client, and it makes sense to use a common language where developers can move freely back and forth. The second is that these JavaScript servers were designed for Asynchronous programming, which is really important when building applications with real-time services and call-outs to remote services from third parties.

Imagine that you wanted to use Box in an application built using the legacy architecture above. You would make a call from your client to your server, and within the code (say Java or .Net) you make one or more remote calls to Box to get information about a document. If we do our job right, the response from Box will be pretty fast. But it’s still a remote HTTP call. And if your application is making multiple requests in serial, then it’s going to be a while before the final page is returned.

Using a modern architecture, your web server passes through long-running tasks (like calls out to third-party services) to workers that can run in parallel. And if it’s really going to take some time, your client can set a Callback to be notified when the job is complete. The end result: your application can do something useful for the client while the job is being done, and the multiple remote calls can all happen in parallel.

It’s worth mentioning that the growing movement towards serverless architectures takes this design one step further. In this case, the database is just another service that the client calls directly. “Serverless” is a bit of a misnomer, because there are servers. It’s just that there are no long running server processes—“servers” are spun up on demand in an event-based model. Because more and more logic is being pushed to the client, when you do have a server, you want to offload tasks as quickly as possible to run in parallel.  

API Management & Analytics

It is a fair question to ask what tradeoffs we’re making with this new approach to architecture. When you build your application by composing best of breed services (developed in-house or from third party cloud vendors), you get a number of benefits: increased reuse, agility, User Experience, etc.. But you also now have complexity over building a monolithic application. You are architecting a distributed system, where the individual components need to be managed. This adds some overhead.

The first category of new investment is in API management. This is a smart move for any company that is building a number of internal services across their business. Whether it’s a simple API gateway or an enterprise service bus, it’s extremely valuable to have a strategic solution for managing and monitoring the APIs that you’re developing internally, as well as those that you’re leveraging from external vendors.

The second major area of investment is in analytics and business intelligence solutions. If user content is going to flow across multiple services, you need some way to reconstruct a single view. Leveraging analytics and security information and event management (SIEM) solutions to gather that information and provide that unified view is a strategic imperative. This allows your organization to move to a world where your applications are constructed from APIs.

Final Thoughts

There are legitimate reasons to rethink how you deliver business application to your users and offer them a better user experience, at a lower cost, with less risk, and more agility to respond to future changes. This article represents a particular viewpoint on how you might consider building those applications, without trying to be too prescriptive. 

Here are some key best practices to consider:

Design for mobile and offline first: this is good practice for ensuring that your applications are truly designed like applications, and will help to encourage the right levels of abstraction and drive the right API design process.

Delegate permissions to the client: client applications have a tremendous amount of business logic and access, and we need to be really explicit in what we’re allowing them to do. When you hide permissions behind a server side request, ask yourself if you’re adding security or obfuscating what the client is trying to do. This is not to suggest that you give your client direct access to your database (though some applications do!). But the more you can get very precise about your permission model, the more you can allow your client to get what it needs without the indirection of your server 

Treat third-party API calls like extremely expensive database I/O: Use the techniques that you’ve always used (like caching), and some new tricks (like asynchronous programming and calling services directly from the client).

Hopefully, this article series passes along some useful high level concepts to consider about when designing and building your application using Box Platform. If you have questions about modern application design and Box or Box Platform, please reach out anytime

Be sure to read the other two articles in our series:
Part 1: Box Platform Usage Patterns
Part 2: The Cloud App Stack

Be sure to read the next Application Development article: Apple-Developer Dispute Devolves Into He-Said/They-Said