Gregor Martynus: Look ma - no backend

Gregor Martynus (@gr2m)was talking at Scotland.js about noBackend, these are my notes from his talk.

It makes sense to question the constraints every day. As front end developers we should focus on what wer'e good at which is building interfaces. 2013 is the year to stop thinking about the back end.

Chris Coyer built an HTML application for creating invoices in 2009. We can now persist data and switch between different invoices using local storage. This isn't particularly difficult for a font end dev today. However, local storage can't persist data between different browsers.

How do we add save as PDF or send as email? We want simple JS methods to call in order to archive this.

The back end here is just an API that can be reused. The API can be used to abstract away browser deficencies - for example taking screen shots.

Before noBackend

We turned an idea into a static prototype. We used a back end to handle functionality and then expose it via a REST API which we then queried with Ajax. Launch this as a free beta as you don't have payments implemented. Based on beta feedback we add in more back end functionality to take payments.

After noBackend

We build a prototype and start generating income.

Now

This is happening right now but it's not still fairly rough. We need to discuss this further - #noBackend noBackend.org.

Some of the tools we need exist:

• remoteStorage.io
• deployd.com
• firebase.com - realtime, scalable and availability.
• meteor.com - not front end only.
• kinvey.com - comes from the mobile area.
• parse.com
• hood.ie

When you do back end as a service you should provide a nice UI for your service

Hood.ie

The approach was to build the JS to provide what front end devs would expect, rather than how the back end works.

Dreamcode

Everyone can do dreamcode. Beginners can do the best dreamcode as they don't know the constraints. This is the best way to define noBackend code - we need to tell the service providers what we want.

• Use case: I want to reset my password.

• Code: resetPassword( email )

• Use case: I want to save a new invoice.

• Code: store.add( 'invoice', properties)

• Use case: I want to export to PDF

• Code: convert( [URL] ).to( [filename] )

Authentication, spam, password resets are hard but the back end guys are really good at it - it should be handled by the API, not the front end.

• Use case: I want to purchase with my credit card.

• Code: purchase('productId').with( { cc: "1234567890," valid: "01-2014" })

• Use case: I want to upgrade to a payed plan.

• Code: purchase( account.upgradedTo('payed') ).with( 'paypal' )

Imagine a coffee machine with this kind of API - within a weeks there would be countless applications using it.

Summary

• Question all contstriaints
• Dream code
• Dream big
• Don't worry
• Be happy