0

I'm pretty experienced with developing both frontend as well as backend applications, with a variety of programming languages and frameworks. I know the problem space and concepts involved in both quite well.

Still I find my thinking around the differences in application architecture and also the differences of the common problems that both have to solve to be quite fuzzy. I'd usually consider myself at least competent in making interesting and/or relevant distinctions and communicating them. But somehow I'm drawing a blank here, even in properly describing what I'm even looking for in this question.

So, for example, user interfaces tend to have to react a lot more to events (e.g. reacting to a users' click or touch).

Additionally, user interfaces, both SPAs, as well as mobile apps (but even simple websites, really), tend to have a lot state, whatever that would mean in more precise terms. Sometimes, backends are architected in a way where the only event that they need to handle is a request. All state is setup at the beginning of the request, and cleaned up / discarded after the response (e.g. PHP). Other backends obviously are more long-lived, keeping state in memory across requests.

Both, frontend and backend, access data/state. A backend might query a database, another service, or a cache. A frontend might send a request to an API, have a local cache, use a state container like Redux, or even have a database-like abstraction on its own (I believe PouchDB and/or Apollo might count here).

What are the conceptual differences in data/state between frontend and backend, if there are any? What are differences in the usual patterns of interacting with data/state in frontend and backend, if there are any?

I feel like in describing all of this I'm missing either the entirely obvious distinctions, or the more subtle differences in approaches and the problem space.

When I search for "frontend vs backend development", there are tons of introductory articles describing what a frontend is (=user interface) and what a backend is (=everything that is not the user interface). I'm not looking for the answer that frontends are concerned with drawing pixels to the screen, but rather something more "meaty" -- which I seem to be unable to describe further.

I'm asking this question here hoping that some people can share their approaches to making sense of this. I also hope that this question is appropriate to this forum and counts as answerable. I appreciate any input and approach to this, if just to see what kind of responses this vague query produces.

[EDIT] Ah, obviously asynchronicity and callbacks are two things that are much more common topics when dealing with user interfaces (because it's important to not block the main UI thread and keep the app responsive).

1 Answer 1

1

For me, an application architecture spans front- and backend. When you have requirements and define the modules and data structures passed between them and the user interaction it needs to support, choosing a front-end methodology usually is part of the architecture. Do I run native on the client, do I run in a browser as HTML5/javascript, do I run WebGL or a server rendering technique... It's really a function of where data originates, where is it processed, and how does it flow through the system. For example, an online game is going to have textures installed locally and exchange game state with a server or service.

When thinking of browser-based clients, I think of them in terms of constraints

  • I can't choose the tech stack, it's going to be HTML5/js/DOM etc. (WebGl nonwithstanding)
  • The resources available are unknown
  • I have no local storage
  • I have to be interactive (which usually means fast, request/response patterns)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.