Front-end Driven Applications – A New Approach to Applications

front_end_driven_apps_header

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. (See StaticApps.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.

Whats 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 one Backend Services if you are building an application. If you are building a website you might try something like Contentful or Prismic.

Comments

  • Pingback: Dew Drop – September 30, 2014 (#1866) | Morning Dew()

  • B. Clay Shannon

    Assuming you’re a Packers fan (http://en.wikipedia.org/wiki/Corey_Linsley)

    • I’m not. But I do like the similarities in our names. ๐Ÿ™‚

  • B. Clay Shannon

    Assuming you’re a Packers fan (http://en.wikipedia.org/wiki/Corey_Linsley)

    • I’m not. But I do like the similarities in our names. ๐Ÿ™‚

    • I’m not. But I do like the similarities in our names. ๐Ÿ™‚

  • B. Clay Shannon

    Assuming you’re a Packers fan (http://en.wikipedia.org/wiki/Corey_Linsley)

  • Cody, that was a great read. I share your excitement about the future of the front-end and its ever growing relevance. Keeping back-end and front-end separate, with all the communication going through an API, slowly, but steadily, becomes the “right way” of doing things in the Internet. I’ve never thought about relying *purely* on BAAS solutions though! We can finally break free from the grip of the back-end guys ๐Ÿ™‚

    • You will never break our grip! Haha!

      Seriously, though, nice job Cody this was a great read and I agree with most everything said and I am a backend guy.

  • Cody, that was a great read. I share your excitement about the future of the front-end and its ever growing relevance. Keeping back-end and front-end separate, with all the communication going through an API, slowly, but steadily, becomes the “right way” of doing things in the Internet. I’ve never thought about relying *purely* on BAAS solutions though! We can finally break free from the grip of the back-end guys ๐Ÿ™‚

    • You will never break our grip! Haha!

      Seriously, though, nice job Cody this was a great read and I agree with most everything said and I am a backend guy.

    • You will never break our grip! Haha!

      Seriously, though, nice job Cody this was a great read and I agree with most everything said and I am a backend guy.

  • Cody, that was a great read. I share your excitement about the future of the front-end and its ever growing relevance. Keeping back-end and front-end separate, with all the communication going through an API, slowly, but steadily, becomes the “right way” of doing things in the Internet. I’ve never thought about relying *purely* on BAAS solutions though! We can finally break free from the grip of the back-end guys ๐Ÿ™‚

  • Pingback: Front-end Driven Applications - A New Approach ...()

  • David Griffin

    What you’re describing might be regarded as a web app with a highly capable offline mode. As a Chromebook user, I frequent many of these. However, the unsupported step in many cases is launching the thing in the first place if you’re offline. It depends if you think this is an app that you launch from the web and then reconnect periodically, or one which you launch from an unconnected browser and may go a whole session without reconnecting. If you can make something for mobile that genuinely falls in to the second category then in many cases you’ve eliminated the app. But this assumes you give the same system access to such a program (or that you even need to).

    • I agree. Offline is a part of the puzzle that is pushing people towards a decoupled, non-custom, independent, third party back-end that is optional given web access.

  • David Griffin

    What you’re describing might be regarded as a web app with a highly capable offline mode. As a Chromebook user, I frequent many of these. However, the unsupported step in many cases is launching the thing in the first place if you’re offline. It depends if you think this is an app that you launch from the web and then reconnect periodically, or one which you launch from an unconnected browser and may go a whole session without reconnecting. If you can make something for mobile that genuinely falls in to the second category then in many cases you’ve eliminated the app. But this assumes you give the same system access to such a program (or that you even need to).

    • I agree. Offline is a part of the puzzle that is pushing people towards a decoupled, non-custom, independent, third party back-end that is optional given web access.

    • I agree. Offline is a part of the puzzle that is pushing people towards a decoupled, non-custom, independent, third party back-end that is optional given web access.

  • David Griffin

    What you’re describing might be regarded as a web app with a highly capable offline mode. As a Chromebook user, I frequent many of these. However, the unsupported step in many cases is launching the thing in the first place if you’re offline. It depends if you think this is an app that you launch from the web and then reconnect periodically, or one which you launch from an unconnected browser and may go a whole session without reconnecting. If you can make something for mobile that genuinely falls in to the second category then in many cases you’ve eliminated the app. But this assumes you give the same system access to such a program (or that you even need to).

  • Earl Owens

    The front end has always been the chief design element. Everything else is in support of the UI.

    • Well said. The touch point (i.e. the UI) between the user and the app is the chief cornerstone. Moving the app logic closer to this touch point i think benefits the user.

  • Earl Owens

    The front end has always been the chief design element. Everything else is in support of the UI.

    • Well said. The touch point (i.e. the UI) between the user and the app is the chief cornerstone. Moving the app logic closer to this touch point i think benefits the user.

    • Well said. The touch point (i.e. the UI) between the user and the app is the chief cornerstone. Moving the app logic closer to this touch point i think benefits the user.

  • Earl Owens

    The front end has always been the chief design element. Everything else is in support of the UI.

  • Yellow

    Heading this way with CouchDB running in the browser and KnockoutJS. However it really can’t be used for many systems. Everything on the client means the data and it’s validation is all in the hands of untrusted machines/users. To sanitise and validate a middle-man (backend) is needed on the remote sync. Hard to be open for clients to do all the work, without being open for injection also.

  • Yellow

    Heading this way with CouchDB running in the browser and KnockoutJS. However it really can’t be used for many systems. Everything on the client means the data and it’s validation is all in the hands of untrusted machines/users. To sanitise and validate a middle-man (backend) is needed on the remote sync. Hard to be open for clients to do all the work, without being open for injection also.

  • Yellow

    Heading this way with CouchDB running in the browser and KnockoutJS. However it really can’t be used for many systems. Everything on the client means the data and it’s validation is all in the hands of untrusted machines/users. To sanitise and validate a middle-man (backend) is needed on the remote sync. Hard to be open for clients to do all the work, without being open for injection also.

  • I’ve been struggling with this terminology for months (author of StaticApps.org, co-founder of Divshot here). I’ve mostly decided that Static App isn’t a good term to use because it carries unintentionally negative connotation with it. Not sure I love FDA as a term either, it doesn’t roll off the tongue, but I can’t honestly say I have one that is for sure better. Lately I’ve been considering “Uncoupled Architecture” and “Independent Front-End” as potential terms…who knows.

    BAAS is neat, but the vast majority of advantages to this architecture apply even if you’re building a custom back-end. The important part is the decoupling of front-end and back-end because it allows you to use the front-end as a coordinating agent for an arbitrary number of back-end services. I build all of my apps these days with an independent front-end and a wide variety of back-end tech suited to whatever I’m building. It might be Firebase, or Ruby, or Node, or Go…whatever gets the job done. It feels great to work that way.

    • Thanks for the comment and the work you’ve done at staticapps.org. I think your thoughts here are mostly on point. But what I would like the term FDA to mean, is that you don’t do anything custom to the backend. The front-end is completely in the drivers seat, simply telling the back-end what to be via a service. What’s new is the notion that when I go to build an application I literally don’t think about ruby or node, but about what service I will use. This could be a nuance, but one with large repercussions. The thing that matters here is who fixes what when it breaks. In a front-end driven application the only thing to think about is the front-end. Everything else is abstracted away into a blackbox back-end.

  • I’ve been struggling with this terminology for months (author of StaticApps.org, co-founder of Divshot here). I’ve mostly decided that Static App isn’t a good term to use because it carries unintentionally negative connotation with it. Not sure I love FDA as a term either, it doesn’t roll off the tongue, but I can’t honestly say I have one that is for sure better. Lately I’ve been considering “Uncoupled Architecture” and “Independent Front-End” as potential terms…who knows.

    BAAS is neat, but the vast majority of advantages to this architecture apply even if you’re building a custom back-end. The important part is the decoupling of front-end and back-end because it allows you to use the front-end as a coordinating agent for an arbitrary number of back-end services. I build all of my apps these days with an independent front-end and a wide variety of back-end tech suited to whatever I’m building. It might be Firebase, or Ruby, or Node, or Go…whatever gets the job done. It feels great to work that way.

    • Thanks for the comment and the work you’ve done at staticapps.org. I think your thoughts here are mostly on point. But what I would like the term FDA to mean, is that you don’t do anything custom to the backend. The front-end is completely in the drivers seat, simply telling the back-end what to be via a service. What’s new is the notion that when I go to build an application I literally don’t think about ruby or node, but about what service I will use. This could be a nuance, but one with large repercussions. The thing that matters here is who fixes what when it breaks. In a front-end driven application the only thing to think about is the front-end. Everything else is abstracted away into a blackbox back-end.

    • Thanks for the comment and the work you’ve done at staticapps.org. I think your thoughts here are mostly on point. But what I would like the term FDA to mean, is that you don’t do anything custom to the backend. The front-end is completely in the drivers seat, simply telling the back-end what to be via a service. What’s new is the notion that when I go to build an application I literally don’t think about ruby or node, but about what service I will use. This could be a nuance, but one with large repercussions. The thing that matters here is who fixes what when it breaks. In a front-end driven application the only thing to think about is the front-end. Everything else is abstracted away into a blackbox back-end.

  • I’ve been struggling with this terminology for months (author of StaticApps.org, co-founder of Divshot here). I’ve mostly decided that Static App isn’t a good term to use because it carries unintentionally negative connotation with it. Not sure I love FDA as a term either, it doesn’t roll off the tongue, but I can’t honestly say I have one that is for sure better. Lately I’ve been considering “Uncoupled Architecture” and “Independent Front-End” as potential terms…who knows.

    BAAS is neat, but the vast majority of advantages to this architecture apply even if you’re building a custom back-end. The important part is the decoupling of front-end and back-end because it allows you to use the front-end as a coordinating agent for an arbitrary number of back-end services. I build all of my apps these days with an independent front-end and a wide variety of back-end tech suited to whatever I’m building. It might be Firebase, or Ruby, or Node, or Go…whatever gets the job done. It feels great to work that way.

  • David Griffin

    There’s always a bit of a tradeoff. Moving some logic onto the client means duplication – you can verify correct info in the client before they submit it, for example, but the server has to check it again in case someone tried to flour constraints by spoofing the client app. Then you have to keep two sets of logic in synch. In an ideal world, a common original source code would control both client and server implementations of this logic, even the build process then made Javascript for the client and something else for the server. This may have finally arrived judgubg nby some recent stories.

  • Pingback: Issue #21 – Oct 10, 2014 | Tales from the Front End()

  • trisys

    Very good summary of the design decisions that both a web and mobile developer must make when architecting a modern browser or mobile device application. I consider myself a ‘full-stack’ developer having control over our active directory, hosting platform, SQL Server database, Web API, HTML/CSS, Javascript, PhoneGap, Telerik (+ other tools) however I have been developing professionally for 30 years – what chance for young inexperienced developers? I agree that the FDA concept is perhaps the best way to develop LoB apps today, but only a small number of developers will have the expertise, time and money to pull it off profitably.

  • Pingback: Front-end Driven Applications โ€“ A New Approach to Applications | rinoesposito.me()

  • The most informative text I read for years!

  • Sรถren Norrby

    One of the most infomative texts I read for years!