In the Tech industry talk about full stack development with the idea that one person can develop everything involved in a web app. To be honest, full stack development has a lot of different moving parts and we need to "separate our concerns" when we're building an app -- this is a (hopefully) quick look at what those concerns are.

At a very high view, I like to break down the different areas like this:

• UI: The presentation layer, such as the raw HTML and browser itself.
• UI Functions: A library of code that builds the experience by fetching data and doing lightweight manipulation of that data
• API: The security layer where you access data
• Services: Functionality that usually lives in the cloud, behind the security layer, doing more complex manipulation and orchestration
• Data Sources: Databases, data lakes, flat files…

The front end is really two different things -- it's the basic static things like HTML, images and stylesheets that the UI knows how to render, and then whatever functions you're writing to support that UI. Then there is a function library. This might be a framework like React or custom code in JavaScript or server-side like node.js or PHP.

The thing to remember is that this front-end is usually purpose built for a very specific use. The code is driven by the user experience, and is often disposable, meaning, once the project is over it will never be revisited. Personally, I believe we should create re-usable presentation functions, but we need to understand the constraints of branding, specific business goals, and the viability of reusing those tools later.

As we move to the back end tools we find the API, the services that are doing the heavy lifting, and the data sources that the services rely on. These back end tools are more performance driven than user experience with metrics like response times and scalability coming to the forefront.

The APIs and the services that the APIs expose should be much more reusable where different front end tools can "mix-and-match" in different ways for different business goals. They should be very generic and not be aware of what you're trying to do for the user on the front end. Think of them as building blocks, and the building blocks can be used in new, and unexpected ways.

Keep in mind that API is sort of the piece that sits between the front end and those back-end services and it acts as kind of a gatekeeper managing things like identity-based-security, that is, who is allowed to access different kinds information and why. This level of security shouldn't be handled in the front-end function library because these rules need to be able to scale and change and those building blocks need to be able to change.

The API can also handle routing to different services in different data centers or even to different vendors or services, but the UI tools should just talk to the one API, with one set of rules, which improves our auditing, security and analytics.

While the API allows a dynamic way to connect to different services, the services themselves should be tightly coupled with the data sources -- one service one data source best case. Obviously there's still some orchestration that might have to happen where it has to reach out to different things to build trigger events and build a more complex response, but it should be as tightly coupled as possible. Services should be scalable outside of the tools you're using to build your front end and they should still be security aware and identity aware because these things need to be audited in a way that you simply can't do on some of the front end tools.

But, what does all this mean if you're going to build all of these different pieces yourself? What are you going to have to do so for one simple function?

The UI is going to call one of the functions you've built for the front-end experience. That function, in turn is going to make a request to the API with the proper formatting and security embedded in the request so the request can be verified as a valid consumer with a valid request.

Now the API layer sends a request to the backend service which in turn might have to grab some data from the data source before it does a little bit more processing and orchestration to complete the transaction.

The service then sends a payload back to the API which then relays that back to the UI function that made the original request and finally the function can do a little bit of formatting to make it pretty for whatever UI frontend is being looked at by a human being.

So, when we talk about the separation of concerns what we're really talking about is using that API as sort of that wall between the frontend and the backend. The UI is all about creating an exceptional experience to solve a business problem for your customers.

The functions you build for that user experience can be reusable tools for like displaying tabular data or rendering maps while also managing identity for this particular user.

As long as it has the right keys to get through that lock at the API then you can get to all the data server stuff that happens out in the cloud but in reality from a front-end development you shouldn't even have to worry about backend infrastructure.

And that's what we mean by separating concerns.