Backend is important, it’s just the last of components

This post belongs to a broader mini-series on how we do Single Page Apps. So I advice to have a quick look there to know context a bit

Let’s recall why backend is important?

  • backend serves persistence, so all your data changes are stored safely, and you can go back to it any time
  • backend often is the guardian-of-the-secrets between frontend and external services like Facebook API, Pusher API. We do not want to publish secret API keys to the Pusher (realtime websocket communication) to anyone with View HTML Source power
  • in times where browser is the VM and console.log is available to everyone, backend validates user actions in environment isolated from end-user
  • backend used to contain application business logic that was meant to be reusable by different views (desktop, mobile, REST APIs, …), but failed to deliver in understandable way
  • it’s the place for fancy tricks to optimize resources usage and allowing service to run fast and failure free

So why would anyone want to skip backend in order to do what ..?

Well, it happens there are many cool things we can gain by treating the backend as just another plugin to our overall architecture and infrastructure. When we start thinking about it as an optional component many new ideas raise

  • first of all, in times when even-my-wife-can-code (RailsGirls) it is important (from a customer point of view) to get working software earlier. “Earlier” – means to work in limited time on limited things; to prioritize features; to focus on customer oriented benefits. Which are: simplest, working software prototype
  • in times where we all fail to deliver software up to the initial spec it is important to get customer feedback as early as we can. We achieve that by doing MVP products with most valuable, but minimal enough set of features. So we need to skip some parts first. What to skip?
  • time is money, losing time is losing money. Why would we develop things in areas of backend, persistence, load balancing, etc.. when nowadays products often change, pivot or are even abandoned if it’s a better option
  • it looks OK to deliver what customer wants, but it’s lot cooler to deliver what customer needs!
    What does customer need? I suppose often he/she doesn’t know. It’s fine. It is also our (devs) responsibility to work with the customer and advice on solutions, ideas, possibilities, alternatives. To propose and educate the customer within product scope. But how customer can know if what he wants is what he/she needs? Let’s validate the product. Does the product make sense at all? So let’s develop early a functional product that we can use and work
  • we cooperate with many developers and not everybody knows the Rails stack. It appears it’s not so easy for a newbie to install MySQL, Rails, irb, bundle, rvm, compile gems, watch Coffee to JS, etc..
    Why should devs struggle with it when it’s possible to just to run static index.html in the browser? Why should a developer start with infrastructure problems if they can start with solving customer problems first?

One conclusion from above is we may skip software parts not essential to a customer

In order to have a working app:

  • we cannot skip the view – we need to show, use, click in the app. So this part is essential
  • we cannot skip the domain. We have to understand and code underlying business and processes of the customer. So business domain is – again – essential
  • it’s the browser world, so the frontend, JavaScript code is a must. Better to have code (html, JS, css) natively in the browser, than to generate and concatenate it via a MVC framework

The parts that we can can skip and we do are:

  • persistence in database on the server side
    Each of our apps first has a persistence limited to current user session. With ability to provide different data states initially we’re able to play different game/app scenarios
  • routes
    As there is no backend, nothing to route. Our frontend code talks to middle layer first, a thing called “server side adapter”. Only production server side adapter talks to URLs. Initial in-memory-adapter talks to simple plain old JS example objects
  • controllers
    As we develop domain logic inside usecases, and they drive the behaviours and use cases and the glue connects different layers/services, there is no need for this structure. Or at least it looks different.

How we achieve it?

  • having server side adapters for communication from frontend to backend.
    We tend to have 2: in-memory-adapter, that is violatile and with CTRL+R will start fresh set of data. But also starts with predefined set of data. Easily configurable. Running in browser only. In plain, old JS variables, arrays, hashes.
    And real server-side-adapter (production ready) where full blown implementation is delivered. It connects to backend via Ajax calls to server url resources.
    Both share same API. It’s just that in-memory is being delivered first and needs almost zero programming efforts
  • separating domain and view completely. They don’t know each other. This separation gives better understanding of the domain in early stages. And allows to modify it more freely.
    Independent view is easier to be delivered earlier. View developers have its API defined clearly and can focus in these areas only. We can also replace view implementations in the whole system with little efforts (let it be DOM/CSS implementation or Canvas)
  • “unit” testing of domain from command line.
    For JS/Coffee code we use Mocha or Jasmine. The former one allows to write test-first within the first hour of the project
  • in multiplayer games we tend to load domain multiple times and simulate multiplayer locally in the browser.
    It’s lot of fun and effective and a mind-opener

Do we need persistence or any external services implemented at the stage of demonstrating a working app to the customer: sure not … yet!