A look at the shifting boundaries of the web development stack
This was originally posted as an answer on Quora: How do frontend code and backend code interact with each other?
Let’s start with quick definitions followed by state of the art best practices.
Table of Contents
HTML (Hypertext Markup Language) tells the browser “what” content is, eg. “heading”, “paragraph”, “list”, “list item”.
CSS (Cascading Style Sheets) tells the browser how to display elements eg. “the first paragraph has a 20px margin after it”, “all text in the ‘body’ element should be dark grey in colour and use Verdana as its font”.
All things that run on a server ie. “not in the browser” or “on a computer connected to a network (usually the internet) that replies to other computers’ messages” are backend.
The state of backend-frontend interaction
There are two main architectures today that define how your backend and frontend interact.
The first is straight up HTTP requests to a **server-rendered **app. This is a system whereby the browser sends a HTTP request and the server replies with a HTML page.
Between receiving the request and responding, the server usually queries the database and feeds it into a template (ERB, Blade, EJS, Handlebars).
Once the page is loaded in the browser, HTML defines what things are, CSS how they look and JS any special interactions.
Communication using AJAX
Nowadays, responses are also done in JSON format.
This means that your server needs to have an endpoint* *which replies JSON/XML to requests. Two examples of protocols for this are REST and SOAP.
Client-side (single page) applications
AJAX allows you to load data without refreshing the page. This has been pushed to the max with frameworks such as Angular and Ember. These apps are bundled, sent to the browser and any subsequent** rendering **is done on the client-side (browser).
These frontends communicate with the backend over HTTP using JSON/XML responses.
React and Ember (amongst other) libraries and frameworks allow you to render an app on the server (backend) as well as on the client (frontend).
When set up like this, the app uses both AJAX and server-rendered HTML to communicate frontend to backend.
Beyond frontend and backend
The web applications you’re going to build are going to need a network connection less and less.
Progressive web applications are loaded once and run forever (ish). You can have a database in the browser. For some use cases, your applications literally only needs a backend on first load and then just for syncing/safeguarding of data. This persistence layer means that most of the logic is into the client-side application (frontend).
Backends are becoming more and more lightweight. Technologies like document stores and graph databases mean that there’s a lot less going on in terms of re-aggregation of data by the backend service. The onus is on the client to specify what data it needs (graph databases) or to fetch all the different fragments of data it needs (REST APIs).
I mean we’re now building backend services that don’t even run all the time, just when they’re required, thanks to serverless architectures like AWS Lambda.
The complexity is shifting across the frontend/backend boundary. We now have the choice, depending on what sort of application we’re building, to make our client hold the complexity or to keep it on the server.
Each option has its pros and cons. Namely the server is an environment that is more stable and has less unknowns but it’s always a network call away. Certain users have the latest browsers and can profit from a client-side application that does most of the work with a snappy UI but you may be alienating users who don’t run the latest browser on an optic fibre internet connection.
At the end of the day, having all these options is a good thing. As long as we focus on building great experiences and products using the right tool for the job. Hopefully you have gained a bit more understanding of the state of web development today.
Get The Jest Handbook (100 pages)