No Backend

In the .Net world if you were to create a web application historically you’d be developing the full stack: web pages, an API (of sorts), business logic and database.

As JavaScript MV* frameworks have become more prevalent a .Net web dev may use one of these frameworks, such as Angular or Knockout, to create a the UI but often will still be creating the rest of the stack.

As part of learning more and more about JavaScript I’ve come across the concept of “No Backend” or “backend as a service” where a company may provide all the server side functionality you might need (different companies often offering different levels/types of services).

Often in presentations, articles and blog posts the reasoning for using a No Backend service is often outlined as:

• As a frontend developer I know HTML, CSS & JS inside and out, I enjoy working with that stack.
• Although I can write server side code I don’t enjoy it and its not my main focus.
• So why not let somebody who is focused on server side dev create that code which I can then consume through an API

 

Why should I use this?

Putting myself in the shoes of a purely frontend developer this sounds like a really good idea, it offers me the benefit of being able to host my content using a static web server in something like Harp.js, simplifying my hosting needs and allowing me to focus on creating the application/site rather than having to deal with “infrastructure”.

A downside is the fact it may cost me more than if I were to host everything myself, but since most of the services are cloud based if my application took off I shouldn’t have any problems scaling.

Isn’t this what mobile app devs already use?

If you were thinking I’ve seen this idea before you wouldn’t be wrong, mobile app developers have been using this sort of service for a while and of the services listed on the noBackend website the majority of them provide samples not only for JavaScript but iOS, Android and often other platforms as well.

In the mobile sphere these services are know as Mobile Backend as a Service or MBaaS and have been around a couple of years so there are lots of companies that are offering this type of functionality. The services grew out of the need for mobile apps to store information, manage user accounts, push notifications, etc without the app developer needing to purchase/rent/host the infrastructure themselves.

What’s in a name

Although I came across this under the name noBackend I’ve seen other names for the same thing, recently Cody Lindley was tweeting about this subject and had this to say:

leaning heavy towards term FDA = frontend driven apps (i.e. static apps) given frontend replaces the backend in terms of authority & func

— cody lindley (@codylindley) March 11, 2014

But it doesn’t stop there, one of the better resources around this type of app is A Field Guide To Static Apps where, unsurprisingly, this type of app is called a static app.

With the various different names out there for this type of application I wonder if there will ever be a single name, leaving people in the situation of having to understand that the various names are in reality all the same thing.

Is there anything to worry about with this approach?

Looking at this there are two things I would be concerned about: security & lack of control over the platform.

Security

My main concern is around security, in this respect mobile apps using the same/similar service are in the main no different, and couple of things that stand out for me:

• Is the communication between your site and the service using Https or is it all Http? How can you tell? Can you force it to be Htttps?
• Most of the services use an api key to identify my site to the service. This api key needs to be in my code but what is to stop somebody taking the api key for my app and creating a bot to sign up thousands of users either costing me, potentially, a lot of money or impacting my existing users?

Control

If a 3rd party is handling all your server side functionality then you aren’t fully in control of your application, consider:

• You are reliant on that 3rd party to be available if its unavailable there is nothing you can personally do to try and resolve the situation.
• As you don’t necessarily have direct access to the data you use (is it really your data anymore?) is it being backed up? who at the service can access your data?
• What happens if the service you use happens to shut down?

On that last point recently PayPal brought StackMob and gave users 1 month notice that they were closing it down leaving anyone using the platform to find alternative arrangements and migrate any existing data whilst of course trying to support their existing customers.

Is this the future of front end development?

Just as the use of MBaaS has grown over the last few years I wouldn’t be surprised to see noBackend to increase with more sites making use of these services especially where speed to market is a factor.

NoBackend frees the developer from the need to worry about creation of the whole server side of the application, and for some this will be the best way to get their app out there and in front of potential/paying customers.  It doesn’t remove the backend entirely but changes it from a “build from scratch” exercise to “configuration only” task.

You can also tell that a subject is gaining traction when conferences devote significant time to it and the QCon conference in San Francisco (Nov 2014) is devoting an entire day to noBackend 

I think any dev should keep an eye on this area to see how it evolves, the services that are offered and the companies that are in, or come into, the market.

It is just possible we are seeing the future of front end development

 

Additional resources

Popup? Frontend Apps - A New Frontier!
A Field Guide To Static Apps
noBackend
noBackend:Front-End First Web Development
Look ma, no backend (video) &  (slides)
I have a Dreamcode: Build Apps, not backends (video)

CodeProject