
NoBackend: Front-End First Web Development - aespinoza
http://www.infoq.com/news/2013/05/nobackend?utm_source=feedly
======
intellection
<http://nobackend.org>

<http://nobackend.org/dreamcode> Interesting gists of ideal code:

\- user accounts / authentication <https://gist.github.com/gr2m/5463426>

\- data persistence <https://gist.github.com/gr2m/5463475>

\- data sharing <https://gist.github.com/gr2m/5463525>

\- emails <https://gist.github.com/gr2m/5463552>

\- file conversion <https://gist.github.com/gr2m/5463605>

\- payments <https://gist.github.com/gr2m/5463675>

<http://nobackend.org/examples>

\- <http://css-tricks.com/editable-invoice-v2/>

\- <http://gr2m.github.io/EditableInvoice/>

<http://nobackend.org/solutions> < known live projects

------
onemorepassword
> _It's a different approach that especially fits applications that hold most
> of its logic in the frontend, where the user experience is the most
> important feature._

This is the part I have a bit of an issue with when it comes to all the hype
about front-end development. I've been involved in web development since 1994,
and software development since the 80's. I've so very, very rarely encountered
applications to which this applies.

When I mention this, people come up with examples like GMail or Twitter,
obviously not understanding the the front-end part, however impressive in the
case of GMail, is just that: a front-end, a client for an application so much
more complex.

I sometimes feel front-end experts have no idea about what happens on the
back-end. All those API-calls are not being handle by some magic genie.

Or maybe I'm wrong and I've missed something essential.

~~~
asolove
I think that your point of view is actually a really good reason for front-
end-first development. As a front-end developer, I accept that the back-end
portion of modeling, storing, and scaling the data is a much harder (or at
least much different and very hard to me) task that generally requires much
more investment before you get much useful feedback.

So when working on a new product, it's worthwhile to build as much of a facade
interface as you can to quickly and cheaply explore how it feels to use the
product. Then you can iterate rapidly with something concrete in front of your
stakeholders, and when they're happy, you can just build the back-end once,
from a solid foundation of domain knowledge.

It also works out well socially. Some people (who tend to congregate in front-
end) work well with vague ideas about a user experience and instructions to
explore the product on their own. Others (who congregate in back-end these
days) want firmer ideas about the product and usage so that they can exercise
their creativity in solving the technical problem well. Front-end-first is a
great way to let everyone do the part of the job that they like.

~~~
onemorepassword
The word you're looking for is "prototyping".

I'm not being sarcastic (well, okay, a little), I pretty much agree with most
of what you wrote (of course depending on the project at hand), except the
notion that this is something _new_.

Also, just working on the front-end/user experience doesn't give you, and
certainly not the back-end developers, a "solid foundation of domain
knowledge". That only happens if they are deeply involved in the same process,
and front-end- _first_ suggests exactly the opposite. A front-end, no matter
how wonderful and detailed, is still way to vague to serve as specs unless the
application is very simple.

~~~
sanderjd
What separates this idea from prototyping in my view is that they are
suggesting keeping the "prototyped" UI as the real deal and then building a
back-end to support it, rather than re-building the front-end along with the
back-end. The back-end is developed using all of the well-documented places
where the front-end needs support as a spec.

------
wwweston
So, I've been working a bit on a simple RSS reader in a spare hour or two over
the last few days, just to experiment with some ideas, and one of the things I
decided to do at some point was create a small backend service that just
generated a gibberish feed -- ordered dates with news item frequency I could
set, proper RSS, but nonsense text and a pictures of/links to cats.

This was _after_ I already had a "real" backend (could grab/merge RSS feeds),
but I still found it useful in focusing on some front-end features, and I
wonder if I might even have been farther along from a prototyping standpoint
if I'd made that approach from the start.

If this is true for some problem domains, my guess is that it's possibly more
true for those (such as feed gathering) where the backend tech issues are
mostly simple or solved problems and most of the novel work to do is in the
realm of UX.

~~~
mcintyre1994
I think, to generalise a bit, you should probably work on your hardest problem
needed to launch. If that's an awesome UX, you should probably make sure
that's possible, and especially with front-end stuff validate that it's
usable. If your backend has unsolved problems that are needed for launch, you
probably want to make sure they're solvable before you spend ages implementing
the frontend.

------
legedemon
I have some validation finally. I have called this approach frontend-first and
have evangelized it internally in my teams. But NoBackend is, catchy.
Basically, I rally my team to build up as much functionality as they possibly
can w/o writing any server side code and demo it to the stakeholders and have
their final confirmation before starting to write anything on the server. The
demo at this point pretty much resembles the live application!

There are some more innovating ideas listed on the site. This sure looks
promising.

------
aespinoza
This is indeed an interesting approach. Backend as a Service usually fixes the
problem for the developer. Which is to make it easy on the developer to create
distributed systems. BaaS improves UX in a small way by just making things
faster and more accessible. But the focus is still the developer.

The no-backend approach removes the backend all toghether, by focusing on UX,
basically on the end-user. This is an amazing idea. Not because of how
revolutionary the technology is, but mostly because it is a very creative way
of improving the user experience.

Obviously not all websites would benefit from this approach, but there is a
large application for it. For most application, a hybrid approach would bring
the best results.

Zumero (<http://zumero.com/>) for example keeps the data on the user device
for mobile applications. It makes sure the application stores everything in
the device, so that apps don't require an external backend.

In the case of Websites, ExtJs (<http://www.sencha.com/products/extjs/>) has
its store, which represents a local storage for web applications. It is not
persistent, but there are ways to keep it in the user machine.

Don't dismiss the idea because it seems radical, try to integrate it into your
app and I am sure you will see the advantages.

------
zimbatm
I was first introduced to the "wishful thinking" idea when watching the SICP
lectures. It's introduced quite early on in lesson 1 or 2. It really changed
how I approach new problems and now I use it all the time.
[http://groups.csail.mit.edu/mac/classes/6.001/abelson-
sussma...](http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-
lectures/)

In a way "dreamcode" is basically the same: you determine what you want to
build and infer the API dependencies that you will need. It makes sure that
all the API that you're going to build are going to be used.

------
rdbhost
These #nobackend folks are late to the game! Rdbhost has provided for no-
server-coding web apps since 2010.

See <http://www.rdbhost.com>

------
Tactic
Form follows function. That said, I find it best to divide the tiers and
document where they meet ahead of time. Then develop each tier independently
to the spec. That makes it so much easier when it is time to
maintain/iterate/swap out one of the parts.

Front end first, back end first... it doesn't really matter. You shouldn't be
designing one to the other. Function first :)

------
grimtrigger
We're already seeing the rise of backend as a service through products like
Disqus, Video/youtube, and google analytics. If you're looking for problems to
solve, find something you hate doing as a developer and find a way to jam it
into an iframe/javascript snippet.

~~~
aespinoza
I wouldn't consider any platform that exposes an API a Backend as a Service. I
do understand where you are coming from, but Backend as a Service providers
are more like iKnode, Parse, Kinvey and Firebase.

~~~
camus
i found Baas really hard to test , especially when you need to upload some
bits of business logic somewhere ... I tried a bit with couchdb and couchapp,
but i never figured out how to unit tests attached documents. Parse works a
bit the same way. How do you do testing on Baas ?

~~~
aespinoza
On iKnode you can test your backend with simple Javascript Unit Tests. We have
a sample in our Javascript SDK:
<https://github.com/Structum/iKnodeSdk/tree/master/Javascript>

What you do is you create your Backend App in iKnode like this one:
[https://github.com/Structum/iKnodeSdk/blob/master/Javascript...](https://github.com/Structum/iKnodeSdk/blob/master/Javascript/UserService.cs.txt)

Then you write your Unit Tests in Javascript like in here:
[https://github.com/Structum/iKnodeSdk/blob/master/Javascript...](https://github.com/Structum/iKnodeSdk/blob/master/Javascript/UnitTests/iKnodeSdkTest.js)

You can also run any other Unit Test framework against iKnode, for example we
have:

\- C# with Microsoft Unit
Test:<https://github.com/Structum/iKnodeSdk/tree/master/C%23>

\- Objective-C with Unit Tests:
[https://github.com/Structum/iKnodeSdk/tree/master/Objective-...](https://github.com/Structum/iKnodeSdk/tree/master/Objective-C)

------
benbusse
@aespinoza Check out dreamfactory.com, we just launched an open source backend
service platform.

~~~
aespinoza
Checking it now. I work for a Backend Service platform called iKnode. So I
already have a backend for my apps.

~~~
benbusse
Great, would love any feedback. We're mainly targeting enterprises. I'll check
out iKnode.

~~~
aespinoza
Definitely. I would value some feedback from you as well.

------
ww520
I'm curious. How are user accounts managed? How does authentication work? How
are the user data stored and shared on different browser sessions?

~~~
lojack
> "... falling back to using server-side components only to implement the
> features the browser does not yet support."

Depending on the problem, that could be a prime candidate for falling back to
the backend.

------
nick2021
The author is taking an existing concept that is not new at all and describing
it in a fancy way to make it sound like a great new thing.

This reminds me of how UX designers talk about their job. Their job importance
can be measured in X and they are always trying to make it sound important as
X squared. Please front end guys, do not do this.

~~~
brianfryer
They are proud of what they're doing. Please, let people share their ideas and
implementations. It's okay to rehash "older" concepts and present them to new
audiences (who may not have been exposed to them).

If this isn't new to you, contribute to the conversation with additional
examples or insight.

An oldie (but goodie) was on the front page today:
<http://www.thingist.com/item/4372/>. There might be some valuable & relevant
lessons to glean.

------
camus
i've always been front-end first. creating the html/js first then the server
api out of it , then finally chosing the persistance layer.

So nothing new here. that's called building up to bottom . You focus on a few
user scenarios and you just make them happen.

then you refactor your obviously nasty code , and thanks to tests , nothing
breaks on the client.

That's why i like microframeworks too instead of bloated stuffs. They can grow
with your needs instead of having all these unusefully layers of code packaged
together, and they are still good enough for team work.

~~~
r00fus
What do you prefer in terms of microframeworks?

