Search code examples
apifrontendbackendbusiness-logic

Understanding the "Backend"

What exactly is backend code? Is it just APIs? Is there business logic in the backend?

For instance, if I have a timesheet app and the user enters their time for the day, is the logic to add that information to the database all in the frontend? And the backend is just for exposing an API to add/update information to the database? For this simple timesheet app, generally speaking, what would be in the frontend vs the backend?

Solution

  • This is a very broad question/topic, but I'll try to explain my view on those terms and how to decide where to put what:

    In general, the "front-end" is what the user will see. To make this possible, that code has to be "stored and executed" on the users device. I'm quite certain that this means (experienced) users will be able to look into the code of the frontend and might be able to understand how it works. (I'll later explain more about why that is relevant.)

    The "back-end" on the other side is usually provided as an "as is" service that somebody is offering, which is reachable via one or multiple of the many available communication protocols and its interface is usually documented in some way, even if it's not public. The most prominent examples nowadays are REST APIs and Graphql APIs. As you already mention, centralized state management (e.g. storing data) can be an essential part of that (, but it doesn't have to). When "making a call" to the back-end, some code gets executed on some server and the response (if any) is the only new information the frontend or user get to know.

    What goes where?

    There are many aspects to consider to make the decision what part of the code goes where. There is no silver bullet: I'm sure examples of all possible combinations can be found.

    • There can be many different front-ends for a single back-end, based on user preference (e.g. browser based, mobile apps, command line interface, ...).
      • They can have different release cycles and update mechanisms, so changes to the back-end might need to stay backwards compatible.
    • For security, operational or data consistency reasons, you might need to implement handling of wrong/invalid input in the back-end, especially if the (kind of) communication protocol changes. Especially since offering a frontend also means that it's possible to know how to call the back-end, so it's also possible to call it differently (be it on purpose or by accident).
    • Since operations between front-end and back-end are most likely async, certain error handling (like connection issues) can only be handled on front-end side.
    • Authentication and authorization / secrets management: If you back-end is only an API to the database, it needs to know the right credentials, so they need to be delivered to the user in some way and can be inspected (and potentially "mis"used)
    • same for business logic: there might be intellectual property or strategic reasons for not delivering it into the hand of users or potential competing companies.

    And of course you need to consider how much resources you have available to implement a solution that suites your needs.