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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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.

Slide 3

Slide 3 text

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:

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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.

Slide 6

Slide 6 text

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…

Slide 7

Slide 7 text

I had a cunning plan:

Slide 8

Slide 8 text

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:

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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.

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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:

Slide 13

Slide 13 text

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:

Slide 14

Slide 14 text

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?

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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 People have been doing these things for ages. It's not new. It's not interesting. It‘s not exactly rocket science.

Slide 17

Slide 17 text

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:

Slide 18

Slide 18 text

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 Why is this so hard? It shouldn‘t be difficult. It should, in fact, only take minutes.

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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:

Slide 21

Slide 21 text

Distributed version control!

Slide 22

Slide 22 text

Plumbing!

Slide 23

Slide 23 text

And other dirty work. So:

Slide 24

Slide 24 text

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.

Slide 25

Slide 25 text

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.

Slide 26

Slide 26 text

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?

Slide 27

Slide 27 text

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:

Slide 28

Slide 28 text

sendEmail({ subject: "Your current to-‐do list", text: currentTodoListToText(), html: currentTodoListToHTML(), to: "alex@thehoodiefirm.com" }); 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?

Slide 29

Slide 29 text

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:

Slide 30

Slide 30 text

SIMPLICITY AND ACCESSABILITY

Slide 31

Slide 31 text

· 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

Slide 32

Slide 32 text

SPEED

Slide 33

Slide 33 text

· 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

Slide 34

Slide 34 text

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.

Slide 35

Slide 35 text

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.

Slide 36

Slide 36 text

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:

Slide 37

Slide 37 text

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:

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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.

Slide 40

Slide 40 text

· 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.

Slide 41

Slide 41 text

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:

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

…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:

Slide 44

Slide 44 text

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:

Slide 45

Slide 45 text

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:

Slide 46

Slide 46 text

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:

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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.

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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:

Slide 51

Slide 51 text

· 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

Slide 52

Slide 52 text

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.

Slide 53

Slide 53 text

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.

Slide 54

Slide 54 text

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:

Slide 55

Slide 55 text

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 ->

Slide 56

Slide 56 text

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.

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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:

Slide 60

Slide 60 text

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)

Slide 61

Slide 61 text

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.

Slide 62

Slide 62 text

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…

Slide 63

Slide 63 text

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:

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

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.

Slide 67

Slide 67 text

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.

Slide 68

Slide 68 text

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 ->

Slide 69

Slide 69 text

…Arduino shields…

Slide 70

Slide 70 text

or the Tessel, which just got funded recently.

Slide 71

Slide 71 text

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.

Slide 72

Slide 72 text

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:

Slide 73

Slide 73 text

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.

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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.

Slide 76

Slide 76 text

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.

Slide 77

Slide 77 text

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.

Slide 78

Slide 78 text

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 ->

Slide 79

Slide 79 text

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:

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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.

Slide 82

Slide 82 text

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:

Slide 83

Slide 83 text

WHAT IS NO BACKEND?

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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.

Slide 89

Slide 89 text

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.

Slide 90

Slide 90 text

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