Front-end Driven Applications – A New Approach to Applications

by Cody Lindley on October 22, 2014

The modern web is always changing, and this article is more than two years old.

Cody Lindley lays down his vision of Front-End Driven Applications as a new paradigm for approaching the Modern Web.

 

The concept of a “thick client,” “fat client,” or “rich client” application is not exactly a new idea. Flash applications poked at this problem for years. Its adoption as a web application architecture might still be seeping into the enterprise, but building an application that runs in the client and uses HTTP to get at data via an API/service is not ground breaking. Hybrid web 2.0 applications have been doing this, to some degree, for years and Flash applications did this long before the rise of AJAX and JavaScript. Sprinkling XHR or JSONP strategies into web pages and calling it a thick/fat/rich client is almost old hat. Even the idea of a single page application (e.g. Hash Changes and PushState) has seen several years of iteration.

But something newer is brewing in the world of application development. Developers are pushing the idea of a thick/fat/rich application to the point where the client is completely in the driver’s seat and building a custom back-end is an unnecessary, if not an obsolete, endeavor.

What’s Changed?

I believe this is occurring because of the following 16 ideas/movements/factors that have been percolating in the web community for a couple of years now.

  1. The rise of adaptive interfaces and responsive design to account for the range of devices a user might invoke to interact with a website or web application.
  2. Application logic is moving to the client because this typically results in a better experience for the user by avoiding the older web 1.0 model of full page reloads with every URL change.
  3. JavaScript has become, “the world’s most ubiquitous computing runtime” and, like it or not, JavaScript is the programming language we have to use in the browser.
  4. Developing, running, testing, and deploying application logic using one language, such as JavaScript, avoids the contextual switching cost of using multiple programming languages in a technology stack.
  5. JavaScript is maturing as a language and speed is less of an issue these days.
  6. Simple static files, (.html, .css, .js) that run independently from the need of server-side dynamic processing is all that is needed to build a modern application. The complexity of dynamic files, being parsed first on the server before running in the client, is an unnecessary complexity. Simple static files, free from server-side stacks and frameworks can result in application source code that is simpler to develop, run, maintain, test, and deploy. (SeeStaticApps.org)
  7. Local development and build processes are no longer tied to a server (e.g. Apache), operating system (e.g. Linux), and language (e.g. PHP) combinations. Node JS and JavaScript tasking solutions (Grunt, Gulp, etc.) have made local development and task running (i.e. building) trivial by reducing everything that used to happen on complex server stacks to one language which can run with ease most anywhere. (Note: I am not referring to Node’s usage as a production server but as a tool that can run anywhere for the purpose of testing applications and building applications which result in static files. Having a reliance on a custom back-end using something like a MEAN stack would just be repeating the same pattern found in something like the MAMP stack)
  8. The rise of “un-hosted” applications, which are decoupled from complex back-end technologies and run client-side first and connect to the back-end via an API at runtime. (See unhosted.org)
  9. The promotion of building an application without a custom back-end. Most applications rarely need more than simple data storage, user management, email, payments, etc. These should just be provided via a simple API/back-end service to front-end developers. (See NoBackend.org and hood.ie)
  10. An application should be decoupled from the back-end so that nothing is assumed about what type of application is making use of the back-end. In other words, both a desktop web application that runs in a browser and a native mobile application running on a phone should make use of the same API/back-end. The DRY and KISS principles are in full effect here. Creating anything back-end that might assume the interface between the user and the app is clearly a poor architecture given the diversity of connected devices running applications today.
  11. The use of patterns like JSONP and the adoption of CORS and Web Sockets by browser manufacturers.
  12. The plethora of free APIs to do most anything and the consistency across large organizations to offer developer API’s.
  13. Users want applications to be usable even if no connection to the internet is available.
  14. Newer devices that are used differently than a desktop/laptop computers have opened up a new exchange of smaller more focused applications and games by way of platform specific application stores.
  15. More and more companies are relying on back-end services instead of building a custom back-end solution in house.
  16. The rise of front-end tooling and front dev opts.

Defining Front-end Driven Applications

As a front-end engineer, I have been taking note of these movements for a couple of years and it seems to me that we are departing from a previous understanding of how applications are developed. When this happens new conversations need to occur and new terms need to be crafted for these conversations.

Several terms have been proposed (e.g. static, no back-end, un-hosted apps) describing various aspects of this shift to client-heavy applications that are decoupled from an abstracted back-end. None of these concepts have caught on because of the semantic baggage from words like “static”, “back-end”, and “hosted”. The term I have settled upon is “Front-end Driven Applications” or FDA’s. The definition of the term is still very much a work in progress but the gist is this:

Front-end Driven Applications run on the client first from static files (html, css, js) and rely on XHR or Web Sockets at runtime to connect to decoupled, non-custom, independent, third party back-end services (e.g. data storage, file storage, search, user management, emailing, payments etc.) that can’t occur on the client alone.

How Are Front-end Driven Applications Different From X?

I’ve already gotten push back that the term “Front-end Driven Applications” is really just another name for a thick/fat/rich application and completely unnecessary given that this isn’t anything new. The reason I think we need a new term is because part of the definition of a FDA is the notion that the entire application runs first on the client and anything that can’t occur in the client is passed off to a third-party service that is not a custom back-end. This, I believe, is a completely new way of thinking about the construction of an application, even if some of the parts are old hat.

Why Build Front-end Driven Applications?

Only using back-end services when needed and only doing so from the client is certainly not the ideal architecture for every application. In many cases, thinking of the back-end as a set of independent black box services is just not realistic. However, given the attention this area of thought has seen recently, it is obvious that some people believe FDA’s to be a viable alternative to a traditionally built back-end. I believe the following five scenarios exist that might lead a person to build a Front-end Driven Application:

  1. You are startup and you need to build something fast using the skills of a front-end engineer alone, while relying on free or paid BAAS solutions to iterate quickly and manage costs.
  2. You need a functional prototype for the purpose of testing application logic, features, and UI’s and don’t have the time to create a custom back-end or infrastructure.
  3. You are a front-end developer who doesn’t want to cross over into the domain knowledge required to do back-end development, but you desire to build a real application.
  4. You want to build separate mobile, tablet, and desktop/laptop applications using front-end technologies that all make use of the same back-end while not having to build your own SDK’s for native and web platforms.
  5. You recognize building a custom back-end to store simple data is unnecessarily re-inventing the wheel and BAAS is a trivial cost compared to rolling your own.

If none of these scenarios resonate with you just consider in general that FDA’s are generally simpler, quicker to develop and test, and cheaper to host. And that might be all the reason you need to implement one.

What’s the Catch?

Building an FDA is far from a perfect endeavor. Several details complicate the construction of a Front-end Driven Applications.

  1. CORS and Web Sockets did not get full support until IE10. This is why you see most BAAS solutions focused on mobile applications. Polyfilling Sockets, which Firebase is doing, provides the broadest browser support.
  2. Currently making a payment from the client alone without leaving the context of the application is not possible. Most payment solutions require a custom back-end running custom back-end code.
  3. The cornerstone to front-end applications rest upon services like Zapier that allow third party services/APIs that require secured keys for access to talk to each other. This is possible because Zapier holds all of the security keys and brokers communication between services/APIs outside of the client. Sending a secured key to the client is never a good idea because someone else might find it and do something evil with it. This is still very much a new frontier and from my experience the road is still filled with bumps and traps.
  4. While hosting static files can be a free or very inexpensive, BAAS solutions are typically not free for production applications. It will take paid services to prop up a Front-end Driven application. But, just like off-the-shelf UI widgets, the cost of purchase pales in comparison to developing a custom solution.

Will Front-end Driven Applications Take Over The World?

I have no idea what the repercussions of building FDA’s will be, or if it will even gain mainstream mindshare. This movement to Front-end Driven Applications might simply be a small stepping stone to the next major shift in web applications. The important thing is that, as a front-end engineer, FDA’s help me build applications faster, with less risk and dependencies, without having to care about the back-end. If that sounds good to your brain, then give it a try. I recommend starting with a combination of UserApp, Firebase, Swifttype, and Zapier or Telerik’s all in oneBackend Services if you are building an application. If you are building a website you might try something likeContentful or Prismic.

 

This article originally appeared on the Telerik Developer Blog and was re-printed with permission.