Those technologies allow developers to leverage the cloud as much as possible - hence focus on building applications, not complex backends.
Of course those are not always possible as sometimes the API's are your selling point.
Leverage external tools instead of building your own
Let's be honest. As developers we like to re-invent the wheel. There are hundreds of programming languages. Dozens of libraries that do the same thing, for each language.
Break out of this loop, re-use what you can and focus on delivering the needed value.
The art of keeping things simple
Developers also love to over-engineer things.
Product owner needs to show the users birthday on the settings page? Well of course it can't be done without having a few microservices communicate in the backend through a service bus. And all indexing in Elastic needs to be changed before you can get that data. Frontend... you'd better forget about it... we need to spend a month first to configure webpack for the new birthday-settings microfrontend. Also the frontend will depend on the i18n microservice that is being refactored so that will take some time.
Seriously now, don't do this. Build things in a simple and easy to maintain way. Challenge over-complicated designs.
Well, going for serverless if you have a simple business site to do, with no DB, no processing, means you will inevitably overcomplicate a simple website.
I think most of the problems I see nowadays in frontend dev sphere are a result of overcomplicating everything and unconcious love for wasting time by devs. ;)
Yeah I know what you mean I wouldn't go serverless unless you actual need server side code. Would use static site generators if I see a use for them (ex build from markup files) or simple HTML files.
Yeah, and as someone with serverless experience (both native aws click through console, SAM, Serverless framework) i know it can be a timehole where suddenly you spend 75% setting up and maintaining serverless instead of focusing on the core of what you want to achivee.
I would personally treat serverless as cost & performance optimization (after MVP is done and works). For those who are not fluent with serverless tech, and only recommend going serverless from the start for advanced users who did it at least couple of times.
Im a big advocate of serverless, just not for novices and not when there is a deadline on their head - this probably wont end well for most :)
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.
Go for Serverless or JAMStack approaches
Those technologies allow developers to leverage the cloud as much as possible - hence focus on building applications, not complex backends.
Of course those are not always possible as sometimes the API's are your selling point.
Leverage external tools instead of building your own
Let's be honest. As developers we like to re-invent the wheel. There are hundreds of programming languages. Dozens of libraries that do the same thing, for each language.
Break out of this loop, re-use what you can and focus on delivering the needed value.
The art of keeping things simple
Developers also love to over-engineer things.
Product owner needs to show the users birthday on the settings page? Well of course it can't be done without having a few microservices communicate in the backend through a service bus. And all indexing in Elastic needs to be changed before you can get that data. Frontend... you'd better forget about it... we need to spend a month first to configure webpack for the new birthday-settings microfrontend. Also the frontend will depend on the i18n microservice that is being refactored so that will take some time.
Seriously now, don't do this. Build things in a simple and easy to maintain way. Challenge over-complicated designs.
I think your second point invalidates the first one. ;)
Might be, depends how you interpret the words :) What do you mean?
Well, going for serverless if you have a simple business site to do, with no DB, no processing, means you will inevitably overcomplicate a simple website.
I think most of the problems I see nowadays in frontend dev sphere are a result of overcomplicating everything and unconcious love for wasting time by devs. ;)
Yeah I know what you mean I wouldn't go serverless unless you actual need server side code. Would use static site generators if I see a use for them (ex build from markup files) or simple HTML files.
Yeah, and as someone with serverless experience (both native aws click through console, SAM, Serverless framework) i know it can be a timehole where suddenly you spend 75% setting up and maintaining serverless instead of focusing on the core of what you want to achivee.
I would personally treat serverless as cost & performance optimization (after MVP is done and works). For those who are not fluent with serverless tech, and only recommend going serverless from the start for advanced users who did it at least couple of times.
Im a big advocate of serverless, just not for novices and not when there is a deadline on their head - this probably wont end well for most :)