Skip to content

Instantly share code, notes, and snippets.

@qrli

qrli/battle-of-front-and-back-ends.md

Created January 29, 2019 13:50
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save qrli/5200adc5a2e1482490fa54695e8c041b to your computer and use it in GitHub Desktop.
Save qrli/5200adc5a2e1482490fa54695e8c041b to your computer and use it in GitHub Desktop.
Download ZIP
Battle of Front and Back Ends
Raw
battle-of-front-and-back-ends.md

Battle of Front and Back Ends

From a front-end centric view, back-end is just a database. From a back-end centric view, front-end is just the UI. When the two groups of developers work together, there is a battle of the middle ground — the business layer.

As a back-end person:

  • I’d think the front-end landscape changes too fast. The JavaScript we write today will become a technology dinosaur in 5 years. But our business logic typically lives for much longer.
  • Also, the front-end tool chains are often much loose compared to back-ends. It is indeed good for quick iterations and delivering fast, but it will be much harder when the project becomes large enough, and when we need frequent refactors.
  • And for protecting IP, keeping business logic in back-ends feels more secure, than obfuscated JavaScript code in browsers.

However, the front-ends are clearly taking over the trend:

  • They are really trying hard to provide a native feel, on both desktop and mobile devices. The latency of calling back-ends often appears to be too high for responsiveness, so front-ends typically need to duplicate some of the business logic. E.g. input validation, result preview. When the amount of code become non-trivial, it would be worse to maintain two copies in different languages, which could be inconsistent.

Rather than web pages, it is more like the heavy client in traditional client-server architecture, where the client is very capable and only communicates to server when necessary. The computers and browsers are now capable enough so that many of the heavy client applications can be done in browser.

I can argue that the validation at back-end is still necessary from security point of view, if that’s a concern. But they will simply run a node.js/express.js server which shares the same code as front-end.

  • And, as the front-end is very capable, it is much easier to just implement a new requirement locally at front-end, than adding some new back-end APIs and deploying a new back-end microservice, if not a monolith. It is especially true when the back-end belongs to another team. I have to agree.
  • The client has reasonable computation power, and it does not cost money in our pockets like servers.

So, it feels like the answer is as always: it depends. And the battle goes on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment