HN Explorer

Ask HN: At which point is it worth extracting the front end into its own app?

5 points by AsyncAwait ↗ HN
I am in the process of implementing my startup idea and was wondering if/when it may be worth making the frontend its own app consuming the backend API.

Currently, my approach is the one I see most often with Rails/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.

While this is currently easier for me to implement, I've been wondering whether having one app being the Rails app and another one being an Angular.js/Ember.js client consuming the API provided by the back-end, wouldn'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/her to maintain the front-end.

I am capable of working with both of these approaches, altrough I have a bias towards the backend side of things.

How do you do it? Is it worth it? Does it only benefit larger enterprises?

5 comments

[ 3.5 ms ] story [ 21.9 ms ] 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, you never have to worry about how much traffic that part will get.

3) you can bundle your html interface for mobile apps

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.

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.