@DanielEinars — great question! Personally, I got into software development because I wanted to bring my UI/UX designs to life. As I've been learning all that encompasses (the industry is near-endless), I found that front-end has a lot of back-end needs. Some examples that come to mind for me are:
understanding the logic model of authentication (and knowing how to render this in the app)
knowing how data is stored in a db and how to call that into the front-end
general understanding of how data is persisted across a user account
I found that designs will stay designs until we bring in the front end. Front-end will stay front-end until we bring in the back-end. Back-end will stay back-end until we can deploy the app.
If you want to scale software and apps, working with DBs will be a must 😊 But that's not to say front-end is INCREDIBLY valuable because it is!!! They're the ones that make our apps amazing and fun too use and keep us coming back for more. BUT....to scale software, back-end and db skills will be an absolute must!
Hmm, I see your points. In my mind I'd never directly interface with a database from the front-end (web) but always via a specific REST API, which is implemented in a separate service. It would handle all the complex storing logic, authentication & authorization and only expose the bare minimum to keep public exposure to a minimum. In the end I don't really care what specific DB is running in the backend, but how I interface with the REST API to satisfy my frontend requirements. However, if I'm in the backend I do very much care about which DB is running where since that will effect scalability.
I don't have a whole lot of backend experience but I do know that I have to mentality switch thinking when going from web to backend from
"One user uses this website at a time"
To
"What happens if suddenly 10'000 separate users use this backend simultaneously."
Being informed about DB options empowers you to make the right decisions in the long run on my view.
Thanks for sharing btw, it's a great read!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
@DanielEinars — great question! Personally, I got into software development because I wanted to bring my UI/UX designs to life. As I've been learning all that encompasses (the industry is near-endless), I found that front-end has a lot of back-end needs. Some examples that come to mind for me are:
I found that designs will stay designs until we bring in the front end. Front-end will stay front-end until we bring in the back-end. Back-end will stay back-end until we can deploy the app.
If you want to scale software and apps, working with DBs will be a must 😊 But that's not to say front-end is INCREDIBLY valuable because it is!!! They're the ones that make our apps amazing and fun too use and keep us coming back for more. BUT....to scale software, back-end and db skills will be an absolute must!
Curious to hear what you think too!!
Hmm, I see your points. In my mind I'd never directly interface with a database from the front-end (web) but always via a specific REST API, which is implemented in a separate service. It would handle all the complex storing logic, authentication & authorization and only expose the bare minimum to keep public exposure to a minimum. In the end I don't really care what specific DB is running in the backend, but how I interface with the REST API to satisfy my frontend requirements. However, if I'm in the backend I do very much care about which DB is running where since that will effect scalability.
I don't have a whole lot of backend experience but I do know that I have to mentality switch thinking when going from web to backend from
"One user uses this website at a time"
To
"What happens if suddenly 10'000 separate users use this backend simultaneously."
Being informed about DB options empowers you to make the right decisions in the long run on my view.
Thanks for sharing btw, it's a great read!