
Ask HN: At which point is it worth extracting the front end into its own app? - AsyncAwait
I am in the process of implementing my startup idea and was wondering if&#x2F;when it may be worth making the frontend its own app consuming the backend API.<p>Currently, my approach is the one I see most often with Rails&#x2F;Django apps and that is to have a MVC approach, but other than that to have the Bootstrap front-end be part of the same app as the back-end.<p>While this is currently easier for me to implement, I&#x27;ve been wondering whether having one app being the Rails app and another one being an Angular.js&#x2F;Ember.js client consuming the API provided by the back-end, wouldn&#x27;t be a better, more modular approach, which would allow me; greater separation of concerns, the ability to make visual changes without touching the back-end; the ability to later on hire a front-end developer without also having to share my back-end code, which would make it easier for him&#x2F;her to maintain the front-end.<p>I am capable of working with both of these approaches, altrough I have a bias towards the backend side of things.<p>How do you do it? Is it worth it? Does it only benefit larger enterprises?
======
MalcolmDiggs
That's how I prefer to structure my apps these days. It lends itself more
naturally to the "disposable front-end" idea (a la Guy Kawasaki's writings). I
prefer to push as much business-logic into the API as I can, and have the
client be thin and quick. I also prefer to have the API be rock-solid (well
tested, documented, etc) while the front-ends are more experimental and less
stable.

In the very early stages of a startup (MVP phase) this might arguably be
overkill. But as the team grows, you'll be happy that the backend and frontend
folks are in different repos (as they probably have very different development
methodologies). And as your userbase/traffic scales up, you'll be able to
allocate server resources very efficiently.

An added benefit is that (depending on the front-end you use) porting to
PhoneGap/Cordova and making a mobile app out of it is a breeze.

One word of caution as you jump into single-page front-ends: It's worth your
time and effort to figure out an elegant SEO solution early on. I prefer
prerender.io, but there are many good options.

~~~
jfaucett
I would also add to your comments that it really depends on the startup idea I
think. If its not anything that really needs to be realtime, or has minimum
interactivity on the frontend and web is the only platform that matters, or if
its an idea with lots of textual content i.e. newssite then separating it out
into a pure frontend is probably not the right choice.

I'd also add that running full integration tests and getting a continuous
deployment solution working becomes a very non-trivial tasks the more
separated your services are. Just something to keep in mind.

Having said all that I agree in the general case and for everything I build
these days as well its a backend api with various gui components
(mobile/desktop/web) that consume it, which has all the benefits you
enumerate.

------
ulisesrmzroche
In the Lean Startup order, going by canon, you should start with your front-
end and then build the back-end to make it work. So you can actually start
right away with the microservice oriented architecture. This will buy you a
lot technically in the long-run, so it's usually the best choice. The basic
pattern is an app/api split, but it can be extended to describe other parts of
your app.

Separation of concerns at macro scale is a great idea just like it is at
functional level. Even something like dependency management works so much
smoother. But yeah, I agree with all the benefits that everyone mentioned in
this thread.

------
benologist
There's other advantages to separating it, like:

1) if you make your api public then you dogfooding ensures it's robust and
functional and full-featured

2) if your front end is static, you can throw it up on amazon s3 or I'm
playing with a static site hosting service I found here on hn called
[http://netlify.com](http://netlify.com), you never have to worry about how
much traffic that part will get.

3) you can bundle your html interface for mobile apps

------
a12b
You have to do that choice on start because it's so annoying and a waste of
time to do the switch later on. Particularly, that's definitely depends of
your app. Is your app really heavy on the frontend side? If yes it's worth it
to start with a frontend framework. Otherwise I prefer to have a traditional
approach.

