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

Presented at Side View in Brighton, November 9th, 2013

The way frontend coders work with data is still very much determined by historical technical necessities and sentiments instead of by how they would like to work. We’re proposing a friendlier, more frontend-centered approach to building data-driven applications, where the backend adapts to the frontend developer’s dream code. At the end of this lies the wish many frontend devs have: “I wish I wouldn’t have to worry about the backend anymore.” Well, your time is coming. Plus a lot more.

Transcript

1. 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
2. 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.
3. I used to do AS3 development. A couple of years ago, I decided that that ship was not only sinking, it was also on fire, 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:
4. 1. tumblr is full of amazing music 2. tumblr is terrible for listening to music 3. I can do better
5. 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.
6. 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…
7. I had a cunning plan:
8. 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:
9. NO BACKEND BACKEND AS A SERVICE And now, years later, these things exist, and that‘s what I‘m here to talk about
10. 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.
11. I'm primarily a frontend developer. But in practice, I'm not. I'm a both-end developer.
12. 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:
13. 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 find, 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:
14. I simply don't want to. It‘s not my job. It‘s not my expertise. I don‘t enjoy it. I would probably find a way to make some terrible security mistakes. And really, what do I need?
15. 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
16. 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.
17. 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:
18. 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.
19. $('.something').addClass('woot'); Why does signing up a user have to be more difficult than changing a DOM element with jQuery?
20. 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:
21. Distributed version control!
22. Plumbing!
23. And other dirty work. So:
24. 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 confidence. And that's before you start scaling. Sounds like the first thing I'd want to get rid of.
25. 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.
26. 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?
27. store.add('todo',  {    title:  "Not  panic",    completed:  false,    due:  1378806388 }); No setting up a database, no schemas, no config. 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:
28. 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?
29. 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:
30. SIMPLICITY AND ACCESSABILITY
31. · 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 configurations 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
32. SPEED
33. · 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
34. 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.
35. 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.
36. 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:
37. 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, filesharing and groupware. Why should this be any more difficult? But we were talking about flexibility, and that takes other forms as well:
38. Backends as swappable commodites unified 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
39. 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.
40. · 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.
41. 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:
42. Now, you should all know this: The Internet has its origins in Arpanet…
43. …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:
44. 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:
45. 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 significant 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:
46. 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:
47. I dream of a future where everybody has their own server – just not the one you'd think of.
48. 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.
49. That's not important. It would be like having a mobile phone – it might even be your mobile phone.
50. 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:
51. · 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
52. 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.
53. 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.
54. 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:
55. 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 ->
56. 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.
57. We need to make it easy, convincing and enjoyable to move our personal data away from the big players.
58. 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
59. 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:
60. 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 first 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)
61. 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.
62. 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…
63. 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:
64. 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
66. 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.
67. 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.
68. 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 ->
69. …Arduino shields…
70. or the Tessel, which just got funded recently.
71. 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.
72. 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 find it. You can also fly 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:
73. 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.
74. DREAMCODE Hm, that doesn‘t really do it justice…
75. 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 fictional noBackend API, which reflected 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.
76. 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.
77. 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 finding 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.
78. 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 ->
79. 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 figure it out first. So, in short: Don't believe in this open source mantra of trickle-down technology:
80. In technology, some of us share a similar philosophy to trickle-down economics.
81. 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.
82. 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 benefits that are good for the web, good for us, good for everyone. So, in closing:
83. WHAT IS NO BACKEND?
84. WHAT IS NO BACKEND? Tech that brings speed, simplicity and flexibility to web app development, for us and everyone else.
85. WHAT IS NO BACKEND? Tech that liberates and empowers by simplifying and lowering barriers of entry
86. WHAT IS NO BACKEND? Tech that distributes applications and kills data silos
87. WHAT IS NO BACKEND? Tech that can make the web the platform for entry-level general purpose computing and learning about code
88. 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.
89. 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.
90. THANKS! Alex Feyerke – @espylaub Thank you for your time.