I have a dreamcode: build apps, not backends –Side View 2013

NO
BACKEND
SIDE VIEW 2013 – BRIGHTON
Alex Feyerke - @espylaub
Hi everyone!
My name's Alex, I'm a freelance web developer in Berlin.
First off, thanks to the the sharps for having me here,
and thanks to all of you for your interest. Brief disclaimer
before we start: I work on a noBackend project called
Hoodie

View Slide

HOOD.IE
so this is all very close to my heart, and the few code
examples I do have come from this project. But it's not
going to be a code-heavy talk or lots of hoodie
promotion, don't worry. If you want hoodie promotion,
come talk to jan or me later.
Anyway.
Today I want to start with an anecdote.

View Slide

I used to do AS3 development. A couple of years ago, I
decided that that ship was not only sinking, it was also
on ﬁre, and so I abandoned it. JS looked good, so I
thought I‘d build something with it, just to get the hang
of it.
At the time, I had the following train of thought:

View Slide

1. tumblr is full of amazing music
2. tumblr is terrible for listening to music
3. I can do better

View Slide

So I built a thing called Whiskie, and all it did was show
you nothing but the music posts from all the tumblrs you
followed.

View Slide

And because tumblr is an incessant torrent of stuff,
Whiskie let you favourite stuff and never lose it again.
But oh.
This meant: data storage. Any I was clueless. I‘d never
written a database query before. So naturally,I wanted to
do this in the simplest possible way. Now, all users had
to oAuth with tumblr because I needed to read their
dashboards, which meant I also had write access for
their tumblr accounts…

View Slide

I had a cunning plan:

View Slide

TUMBLR AS A BACKEND
I ended up using one tumblr draft per user as a JSON
store. Worked wonderfully, until I wanted to implement
public faves, which drove me towards more PHP and
MYSQL. But I‘d gotten a taste of what I wanted, I just
couldn‘t formulate it back then:

View Slide

NO BACKEND
BACKEND AS A SERVICE
And now, years later, these things exist, and that‘s what
I‘m here to talk about

View Slide

DON‘T WORRY ABOUT
THE BACKEND
Building full-featured web applications on the browser
side and not worrying about what goes on on the server.
Now I don't know about you, but to me, this sounds very
desirable.

View Slide

I'm primarily a frontend developer. But in practice, I'm
not. I'm a both-end developer.

View Slide

Many of us probably are. Not by choice, mind you, but
because I don't have any alternatives. At some point, 95%
of my projects require some sort of data storage or user
authentication. This leads us to these old friends:

View Slide

Look at that. I could sit down and work with these
things. But at the same time, these are jobs. Other
people‘s jobs. They make their living with this, and they
know it really well. I can use PHP or Rails, I can ﬁnd,
adapt and use a server-side framework, I can deal with
database schemas and I could probably hack something
together that would work.
But it wouldn't be very good.
It would take me ages.
And, most importantly:

View Slide

I simply don't want to.
It‘s not my job.
It‘s not my expertise.
I don‘t enjoy it.
I would probably ﬁnd a way to make some terrible
security mistakes.
And really, what do I need?

View Slide

1. Sign up users
2. Be able to admin them easily
3. Let them save and load data
4. Let them share it or make it public
5. Maybe send an email or two
6. Let them pay me for the service
My requirements, in fact most people's requirements
aren't outlandish. This is extremely basic stuff. It‘s
actually quite boring

View Slide

1. Sign up users
People have been doing these things for ages. It's not
new. It's not interesting.
It‘s not exactly rocket science.

View Slide

Rocket science is dictated by the natural world. Building
stuff on the web is more or less arbitrary. The rules
aren‘t god-given, set in stone or otherwise immutable.
They‘re agreements between humans. If we want to
change the web, we can. We don‘t even have to ask for
permission.
So, again:

View Slide

1. Sign up users
Why is this so hard?
It shouldn‘t be difficult.
It should, in fact, only take minutes.

View Slide

$('.something').addClass('woot');
Why does signing up a user have to be more difficult
than changing a DOM element with jQuery?

View Slide

account.signUp('username', 'password');
Why can't you just do this in the browser?
That's where the noBackend idea comes in. It makes this
possible. noBackend is essentially about delegation. It
turns something that is difficult and full of pitfalls into a
commodity, where the tricky and/or dull bits are handled
by other people who are better at it than you. And this
makes sense, we do it all the time, in all aspects of life:

View Slide

Distributed version control!

View Slide

Plumbing!

View Slide

And other dirty work.
So:

View Slide

Why not with backends?
Backends are hard, they're made up of a lot of different
components that all have to interact with each other,
there's a variety of languages and syntax in even the
simplest setup, there are arcane conventions and layers
upon layers of obtuse, compounded weirdness that take
years of experience to wrangle with conﬁdence. And
that's before you start scaling.
Sounds like the ﬁrst thing I'd want to get rid of.

View Slide

Well, you can get rid of it. There are architectures and
services that let you more or less forget about the
backend, and just build complete, data driven web
applications from the client side, all in JS. Some of them
even throw in real-time data binding and offline
capability.
Essentially, your backend is a black box with an API. So
noBackend is a bit of a misnomer, of course there's a
backend, it's just not something you have to worry about
if you don't want to.

View Slide

account.signUp('name', 'pw');
Let's look at some examples. I showed you this a minute
ago:
That's noBackend code. It runs in the browser, and it
does exactly what it looks like it does. You can do that a
few seconds after you've generated the app's scaffolding
with a command line tool. It's a real thing, you can use it
today, and it creates a proper user account and
authenticates the new user. Want to store some data?

View Slide

store.add('todo', {
title: "Not panic",
completed: false,
due: 1378806388
});
No setting up a database, no schemas, no conﬁg. Want
to store some data? Go ahead, store some data. The
infrastructure gets out of your way. Want to send a
multi-part email from the browser? Go ahead, it's 2013:

View Slide

sendEmail({
subject: "Your current to-‐do list",
text: currentTodoListToText(),
html: currentTodoListToHTML(),
to: "[email protected]"
});
This is a nice example of the noBackend philosophy. It’s
all about the API, it’s frontend centric, user centric. The
actual implementation might or might not be complex,
why should you care?

View Slide

NOBACKEND
is a design paradigm for architectures/
frameworks that abstract complex
backend operations and technology into
a simple to use REST API.
So there is a backend, but delving into it is optional. Of
course, these things are usually extensible in some form
or another, so you can add functionality with plugins or
packages. And that‘s a pretty good setup, in my opinion.
Right, I think you got the idea. That's all the code you're
going to see from me today.
First, I'm going to tell you why this is cool. Then I'm
going to tell you why it's important.
What's cool:

View Slide

SIMPLICITY AND
ACCESSABILITY

View Slide

· Service or an installable package (runs
server, DB, everything)
· Ideally: One language, one data format
· Simple, built-in deployment
· Very quick to get going
- NoBackend solutions typically come as a service or an
installable package that includes the entire
infrastructure: quick setup, very low barriers to entry
- Where you used to have a tech stack with multiple
languages, data formats, databases, query languages,
server conﬁgurations etc., you now potentially have one
language, one data format, and barely any contact to the
server, unless you want to
- very simple, built-in deployment mechanisms

View Slide

SPEED

View Slide

· Very little config and boilerplate, build
significant things immediately
· Additional perks: offline modes, live
sync, reactive views etc.
· Perfect for rapid prototyping with real
data, behaviours and devices
- Very little config, very little boilerplate code to write.
You can start doing substantial things almost
immediately, there's nothing standing in the way of your
ideas and the interesting problems of your app, which is
what the user does with it
- Different solutions offer different built-in perks which
save lots of development time, such as offline capability,
live sync across devices, real-time data binding etc. And
that's all just there, no additional effort
- Perfect for extremely rapid prototyping and user
testing with real data and behaviours on real devices

View Slide

FOCUS
- Start development in the browser, near the user, where
the unique aspects of your app are. Build the user-facing
features quickly, validate or dismiss them, experiment
and pivot at will without worrying about infrastructure or
data schemas. Find out whether the idea is actually
worth spending time on.

View Slide

FLEXIBILITY
Many solutions let you host wherever you like (as they
should), which includes a box in the corner of your
office. You could have auto-updating, self-hosted and
secure, device-independent enterprise software
packages running on a small noBackend-Server. Setting
that server up is just as simple as running the noBackend
stuff on your own machine.

View Slide

We spend so much time on
the internet that we should all
have our own digital home
online. So far we are only
guests in a couple of gigantic
hotels with barb wire around
them.
—Bastian Allgeier
The Future of the Web — A Draft
…
And there are developments in this direction. Of course
you can cobble together a bunch of open source projects
on a mac mini, but better, more user friendly alternatives
are appearing:

View Slide

here‘s a small german company called protonet building
servers for small businesses:
That‘s a server. It has one button. You press it, and you
get a self-hosted environment for chat, ﬁlesharing and
groupware. Why should this be any more difficult?
But we were talking about ﬂexibility, and that takes other
forms as well:

View Slide

Backends as swappable commodites
uniﬁed by a consistent interface
noBackend potentially makes the backend part of an app
a swappable commodity. As long as the API is the same,
what goes on behind it doesn‘t matter, what it‘s
implemented in doesn‘t matter. And that means you can
switch at will.
But noBackend offers some new approaches to old
problems, too

View Slide

ONE BACKEND
PER USER
You build your app as static HTML (hosted on gitHub
pages, for example), the users host their data
themselves, on Dropbox, google drive or with
remotestorage.io or similar.

View Slide

· Scales easily
· Data privacy is easier to guarantee
· Multiple apps could access the same
user store
Each user only has one calendar, one address book, one
todo list, that all apps can access and work with.

View Slide

SPIFFY!
So noBackend brings a large increase in simplicity and
comfort for people like us, but it can also do a lot more.
I think we can all agree that the internet isn‘t doing so
well at the moment: huge, centralized services, ads,
bullshit startups, ubiquitous surveillance… not good. But
noBackend might be able to help a bit.
Let‘s go back in time for a second:

View Slide

Now, you should all know this: The Internet has its
origins in Arpanet…

View Slide

…a military network created to facilitate more efficient
use of geographically distributed computing resources.
The "survive a nuke"-aspect was actually never a design
goal, but more generally avoiding single points of failure
was. Equipment and connections were unreliable
enough, even without Soviet Russia throwing ICBMs at
them.
So we got packet switching and TCP/IP, and we also got
this image:

View Slide

Now, on a technical level, this is still somewhat accurate,
that's how the web works. In practice, the individual
nodes aren't of equal size, some are veritable
supernodes:

View Slide

The big ones are what you'd expect: many of them are
google sites, the second largest one is facebook, then
yahoo.com, apple.com etc.
These are pretty signiﬁcant points of failure now. Not
necessarily in an reliability/uptime sense, but in a more
general security sense. If an antagonistic third party can
access anyone's data in these large nodes, they must be
considered broken. As we know, this is the case.
So, ideally, the web, even the social web, is properly
distributed, to avoid these kinds of things in the future:

View Slide

We must make […] what I
call “social machines”, in
which people can collaborate
together, but do it in a way
that’s decentralised, so it’s not
based on one central hub.
—Tim Berners-Lee
And I think we can all agree with that.
But how would that work? Well, here‘s a popular idea:

View Slide

I dream of a future where
everybody has their own
server – just not the one you'd
think of.

View Slide

It could be your computer at
home, a little box next to your
TV, maybe a gaming console
or a small server somewhere
in a data center.

View Slide

That's not important. It would
be like having a mobile
phone – it might even be your
mobile phone.

View Slide

Your own server would be so
easy to use and easily
integrated with your existing
devices that even your granny
would have one.
—Bastian Allgeier
The Future Of The Web — A Draft
That orange protonet box is a very small step in that
direction.
So let‘s see what noBackend can do to help. It can:

View Slide

· Redistribute data and services
· Enhance data security and sovereignty
· Provide infrastructural independence
· Empower people to build and run their
own software
· browser-based applications + locally
installed software = <3
- redistribute apps and user data away from central
nodes and single points of failure (either through 1
backend per user or by enabling more people to do their
own thing)
- decrease the number of enormous data silos that can't
talk to each other
- through this, enhance data security and sovereignty
- provide infrastructural independence from large,
compromised services with their own agendas by turning
them into swappable commodities
- empower people to build and/or run their own
localized tools and solve their own problems
- bring together the best parts of browser-based
applications and locally installed software

View Slide

DECENTRALIZE.IT
Bastian, who I just quoted, is forging ahead with this,
publicly working on a concept for a platform that could
do all of these things. So check it out at decentralize.it!
I‘m a big fan of this idea, because it‘s keenly aware of
the problems, one of them being: security and
decentralization aren‘t actually selling points for non-
nerds. We have to make platforms so compelling on
other fronts, because privacy isn‘t sexy.

View Slide

THE CRUX
And that‘s the crucial point, isn‘t it? The self hosting, the
app developing, the one backend per user, it all has to
compete with the incredibly polished products of
enormous companies.

View Slide

It has to compete on the levels of functionality, user
experience, design, critial user mass and convenience,
all of which are perceived as more important than
security and integrity. It's a hard sell, and we're not
going to get there by continuing to building stuff by
nerds for nerds.
I don‘t know how many UX people FB has, but they have
UX people. Most open source projects don‘t even have a
designer. And if they do, it‘s usually as an afterthought.
„Hey you: Make this look nice„
But that‘s nowhere near enough:

View Slide

Design is not just what it looks
like and feels like.
Design is how it works.
—Steve Jobs
So design has to be part part of the entire process. And
what this means, to put it very bluntly, is that OS
generally isn't for normal people. OS is for people who
think this ->

View Slide

represents an exciting opportunity. That's not a majority
opinion. The majority wants an iPhone. And that doesn't
make the majority stupid or wrong. They just want a
good experience. They want to be empowered, not
encumbered.

View Slide

We need to make it easy,
convincing and enjoyable to
move our personal data away
from the big players.

View Slide

We need great self-hosted
applications, which we can
use to manage our emails,
personal pictures, documents,
private messages with friends,
blog posts, etc.
—Tom Dale
Progressive Enhancement is Dead
We've got to build better tools. And not only tools to use
on the web, tools to make the web, too. Simpler tools
that make general purpose computing more accessible.
And yes, this is our job as frontend people, because

View Slide

The browser transformed from
being an awesome interactive
document viewer into being
the world’s most advanced,
widely-distributed application
runtime
—Tom Dale
Progressive Enhancement is Dead
We need to empower people to code and produce things
they can actually use in a modern world, in their world,
on __any device with a browser__, just like the apps they
use everyday.
So back to making the web: noBackend removes the high
barrier of entry to producing what I now consider the
most generally useful realm of programming: web
applications. And the barrier is high:

View Slide

ANIMATED GIF OF DOG
JUMPING INTO HEDGE
AND BOUNCING OFF
HILARIOUSLY
The simplest form of traditional web application a
beginner might be able to deploy requires you to write
HTML, CSS, probably JS, PHP and MYSQL. People work
highly paid, full time jobs just doing the ﬁrst two. This
may not seem so bad to us, but to most people, this
might as well be actual rocket science. Just getting
everything set up locally and remotely is a task that will
deter, if not defeat many beginners.
(the dog gif is here: http://gifeye.com/3805)

View Slide

And, like water and electricity, people in general tend to
follow the path of least resistance, and that path is to get
someone else to solve their problems instead of learning
how to run MAMP (which is supposed to be simple
already!) and write a SQL query.
And that‘s a problem. Making the web is still too hard.
Using the web used to be hard, too, but it‘s been made a
lot more convenient and simple, by the wrong people,
regrettably, but hey. But by and large, the web is made
by professionals.

View Slide

But that's not the point of the web, is it? It‘s not TV, it‘s
not there to be consumed passively. And yes, people
upload immense amounts of photos, video and audio per
day, but that‘s not making the web. We‘re the ones
making it. But…

View Slide

The web is not just for web
developers!
—Adam Brault
Enough is enough
He's right! The web is an amazing system that can do so
much for so many, and yet to most people it's just a
photo scrapbook where they tell the government where
they are and who they're with. We're letting one of the
greatest feats of human ingenuity degenerate into an
interactive lifestyle magazine that spies on you.
One way to remedy this is to put creative power back
into the hands of individuals. That was the point of the
web all along:

View Slide

This is for everyone.
—Tim Berners-Lee
2012 Olympics opening ceremony
And when he says everyone, he means everyone: Not just
professionals and corporations, everyone. And there are
notable precedents for efforts to put computing power
into the hands of amateurs. Back in the 1980s, Apple
gave us HyperCard

View Slide

View Slide

Both Danny Goodman and
Bill Atkinson have stated
publicly that they got
programming questions from
every kind of person: small
business owners, school
teachers, ski bums, taxi
drivers, etc.

View Slide

Hypercard let non-
programmers build simple
apps, and so a lot of apps
were created that would
never have been created if
app-creation was left in the
hands of professional
programmers.

View Slide

And many of those little apps
were tailored to what the
creator needed at that
moment, in a way that could
never happen if a
professional programmer
drew up some spec.
—lkrubner
Hacker News thread on Hoodie
…or listened to market reasearch. HyperTalk is
apparently what inspired Brendan Eich when writing
JavaScript. There were even hardware add-ons for
HyperCard that could exchange signals with external
devices, much like ->

View Slide

…Arduino shields…

View Slide

or the Tessel, which just got funded recently.

View Slide

In the 70s, there was SmallTalk, which was similarly
appealing to all sorts of people (provided you had access
to the hardware). At a glance, it looks a tiiiiny bit like
CoffeeScript, with its pleasant lack of curly braces and
semicolons. It's easy to learn, has an integrated editor/
debugger/execution view setup (*cough* browser) and
thus a very low barrier of entry.
Smalltalk and HyperCard were interesting because they
made programming accessible, people from all walks of
life could write useful little things with them and take
advantage of the new powers digital technology brought
them. Except back then, nobody had the hardware.

View Slide

Where's the equivalent of that today? I'd say the closest
thing is JS and frontend web tech. You can write, run,
debug and use your code in one place, the browser, and
you can modify the code while it's running, too. Plus, it's
platform independent and networked, and you can put it
on the web, from where it can be run by practically
anyone who can ﬁnd it. You can also ﬂy drones and
control other hardware with it. That's an extremely
powerful tool.
So what we should do is: make powerful tools accessible,
easy to set up, quick to get started, and delivered with
encouragement instead of kept to ourselves with
monkish elitism:

View Slide

Learning to program should
be about play, it should be
getting things up and running
in an afternoon and seeing
what happens, it should really
just be about poking things.
—Tef
Programming is terrible
Again, I think noBackend tech can be hugely helpful in
this regard. So helpful, in fact, that it's one of Hoodie's
design goals to make its use attractive and intuitive to
beginners and non-professionals. And we came up with
a process to help us achieve this.

View Slide

DREAMCODE
Hm, that doesn‘t really do it justice…

View Slide

DREAMCODE!
At Hoodie, we call the process dreamcode. When we
designed the initial API, we sat down and each wrote
hypothetical apps that worked with a ﬁctional noBackend
API, which reﬂected what we thought were the most
intuitive, simple and sensible ways of working from the
frontend. We didn't start with the system's capabilites
and simply exposed them to the users, we started with
the users' requirements and built backwards from there.
We wanted people to have a good experience with it.

View Slide

Dreamcode is essentially user centered design for APIs.
For us, this was crucial, because our target audience for
1.0 isn't developers like us. We're aiming for non-
developers, non-professionals. We want the beginners
and amateurs, the people who'd usually shy away from
code. We've made data driven app development so much
simpler and more convenient, and it would be a great
waste to not expose all that to a greater audience. We
want the power, simplicity and accessibility of smalltalk,
hyperCard, even Excel, in the web realm.

View Slide

WE ARE
DESIGNERS
To do this, we (as in: developers) need to know the
fundamentals of design process and design thinking. Not
because we need a sweet website for our project or a
nicely typeset docs page, but because using what we
build, from ﬁnding it, to learning about it, to getting it
running, to working with it, to failing with it, to asking
for help for it, to succeeding with it: all of that is user
experience.

View Slide

WE ARE EXPERIENCE
DESIGNERS
And it pays off to design towards that experience,
because that's what google and apple and facebook do,
and what developers, left to themselves, tend to forget.
How many brilliant engineering projects on the web go
underused and ignored because the engineer thought: "I
didn't have a three-point getting started guide, why
should anyone else?"
So we are experience designers ->

View Slide

WHETHER WE LIKE IT
OR NOT
As programmers, what you produce needs to be
designed to the users' needs, and how you present it
needs to be tailored to the intended audience, which is,
far too often, exactly one person, the author. And it
needs to offer a good user experience, even if it's just a
snippet of code. And that's just a matter of economy:
every time a developer saves time by leaving something
obtuse and complicated in their code, that time gets
wasted many times over by every user who has to ﬁgure
it out ﬁrst.
So, in short: Don't believe in this open source mantra of
trickle-down technology:

View Slide

In technology, some of us
share a similar philosophy to
trickle-down economics.

View Slide

We believe that when a
technically-savvy elite of
enthusiasts build tools and
technologies for themselves,
that technology will eventually
trickle down and help less
technically-savvy members of
society.

View Slide

And, just like trickle-down
economics, it doesn’t work.
—Aral Balkan
Trickle-down technology
Calling it the open web is all well and good, but at the
moment it's more like an open window in the second
storey and you have to bring your own ladder. It‘s not a
welcoming, open door.
noBackend is a great opportunity to help more people
shape the web. And don't worry about your job and your
status: It's not a complete replacement for all tech stacks
ever. It's not a magic solution that aims to make backend
devs obsolete overnight. Yes, of course traditional
setups still have their place, if you're a high-traffic web
app that uses six different types of databases noBackend
isn't going to make your engineering team vanish. It's
just one more solution that brings a number of
promising beneﬁts that are good for the web, good for
us, good for everyone.
So, in closing:

View Slide

WHAT IS NO BACKEND?

View Slide

WHAT IS NO BACKEND?
Tech that brings speed, simplicity and
ﬂexibility to web app development, for
us and everyone else.

View Slide

WHAT IS NO BACKEND?
Tech that liberates and empowers by
simplifying and lowering barriers of
entry

View Slide

WHAT IS NO BACKEND?
Tech that distributes applications and
kills data silos

View Slide

WHAT IS NO BACKEND?
Tech that can make the web the platform
for entry-level general purpose
computing and learning about code

View Slide

WHAT IS NO BACKEND?
Tech that requires us to think more like
product managers and designers, so we
can build good experiences for other
humans
All of these things are good things.
It is our job to make making the web more accessible to
more people. That is our power. There is no-one else. If
we can help people understand it, they can make the
web. If they make the web, they will care about the web.

View Slide

The more people care
about, understand and
make the web, the better
off we'll all be.
The more people care about, understand and make the
web, the better off we'll all be. Because, as Jeremy Keith
said yesterday: The web is good for our species. And we
have to take good care of it.

View Slide

THANKS!
Alex Feyerke – @espylaub
Thank you for your time.

View Slide

I have a dreamcode: build apps, not backends –Side View 2013

I have a dreamcode: build apps, not backends –Side View 2013

Alex Feyerke

More Decks by Alex Feyerke

Other Decks in Programming

Featured

Transcript