3 ms·

Well depends what you call "backend", I tend to think of it as the business code that the interface operates with. Namely the API. I work in finance, so there t

by d--b 6y ago

Well depends what you call "backend", I tend to think of it as the business code that the interface operates with. Namely the API. I work in finance, so there the backend consists of gathering data and applying statistics on it. The frontend is a presentation of the data and a way to interact with it. The webserver code that renders web pages definitely belongs to frontend dev.

Silhouette 6y ago
Personally I would call code running on the user's device the front end and code running on some server or other remote device the back end. YMMV. Maybe this explains the difference in our perspectives. To me, other than perhaps the very first data collection where maybe the source is only accessible from the back end, whether things like statistical analysis or rendering of the results happen on the front or the back end is something you will decide on its merits for each project, not something that is necessarily tied to the mechanical programming skills or libraries on one suffer or the other.
- deleted 6y ago
  [deleted]
- bcrosby95 6y ago
  This would mean server side rendering is back end development. Traditionally working in templated languages was considered a front end job despite being translated server side.
  - Silhouette 6y ago
    Perhaps, but once you start generalising there are lots of grey areas and overlapping possibilities, which I suppose is my main point here. For example, say you're working on a web app that controls some device. On the back end, you might not be talking to a database, at least not in the sense of SQL or NoSQL we usually mean in the context of web apps. Maybe instead you're integrating with some internal API that controls the hardware. In that situation, maybe you're exposing that internal functionality to the front-end web app via some HTTP-based API, which might be substantial but is mostly a wrapper for the internal functionality with things like security incorporated. Who should be responsible for that middle layer? Do you have a separate person/team whose responsibility is just to bridge between the front-end code and the internal API? Should the person/team responsible for the front-end also be responsible for the HTTP-based API it talks to, and hand off to some other person/team who work on the hardware-facing code behind the internal API? Should the internal team also be responsible for the HTTP-based API? I don't think there are any "right" answers in a situation like this. You probably have people with front-end skills. You probably have people with low-level hardware hacking skills. Some or all of those people might also have back-end skills. You've certainly got three distinct but related areas here. Depending on the project and the mix of people you have available, there are several potential ways to handle this situation that might be effective.

by d--b 6y ago

Silhouette 6y ago

Personally I would call code running on the user's device the front end and code running on some server or other remote device the back end. YMMV. Maybe this explains the difference in our perspectives. To me, other than perhaps the very first data collection where maybe the source is only accessible from the back end, whether things like statistical analysis or rendering of the results happen on the front or the back end is something you will decide on its merits for each project, not something that is necessarily tied to the mechanical programming skills or libraries on one suffer or the other.

deleted 6y ago
[deleted]
bcrosby95 6y ago
This would mean server side rendering is back end development. Traditionally working in templated languages was considered a front end job despite being translated server side.
- Silhouette 6y ago
  Perhaps, but once you start generalising there are lots of grey areas and overlapping possibilities, which I suppose is my main point here. For example, say you're working on a web app that controls some device. On the back end, you might not be talking to a database, at least not in the sense of SQL or NoSQL we usually mean in the context of web apps. Maybe instead you're integrating with some internal API that controls the hardware. In that situation, maybe you're exposing that internal functionality to the front-end web app via some HTTP-based API, which might be substantial but is mostly a wrapper for the internal functionality with things like security incorporated. Who should be responsible for that middle layer? Do you have a separate person/team whose responsibility is just to bridge between the front-end code and the internal API? Should the person/team responsible for the front-end also be responsible for the HTTP-based API it talks to, and hand off to some other person/team who work on the hardware-facing code behind the internal API? Should the internal team also be responsible for the HTTP-based API? I don't think there are any "right" answers in a situation like this. You probably have people with front-end skills. You probably have people with low-level hardware hacking skills. Some or all of those people might also have back-end skills. You've certainly got three distinct but related areas here. Depending on the project and the mix of people you have available, there are several potential ways to handle this situation that might be effective.