51–60 of 164 posts
Smaller applications, in the Big Data sense, will still be used on site. At least say, 10 years down (yeah, pulled that figure from my ass).
So no. I don't believe that back-end development will be obsolete. Middle is the new back.
Earlier quoted context omitted.
Sounds like your framework sucks. With an orm and some sort of json serialization that's literally just: Put bagel in toaster. Update the db model. Add a migration. Update the viewmodel db model translation in relevant requests. Get bagel and butter it. Commit. Test the migration on a staging db if feeling paranoid, cause it's just adding a column. Push to master. Update production. Take last bite of bagel. If you ar…
> cause it's just adding a column This kind of mentality is why most applications are shit and broken. And why most hires are worthless. And everyone is not working on a cookie cutter over-bloated rails website. Sorry but this kind of remark simplifying our job always pisses me off.
In a system of any complexity, changing your data model is an activity that requires due diligence to mitigate any downstream risk.
Some people don't like the word much, but "serverless" is going to become a bigger deal. You'll write your code, complex or simple; you'll hand it off to some cloud system; you'll write a bit of configuration; you're done. Likely the configuration part will become less and less required. You won't think about hardware, scaling, load balancing, etc, it will just happen for you. The data store being used will be abstra…
This model isn't "serverless", it's PAAS. It's not much of a future. Heroku is useful for prototyping, not scale. (Edit: Doesn't mean it can't be more popular though - the web is full of prototypes) "Serverless" as in AWS Lambda has very specific use cases. The people who are serving websites on Lambda or something are not only doing it wrong, they are wasting money while locking themselves in to an architecture that…
WebAssembly will not revolutionize anything. It's like java where people claim it's as fast as native code, and yet every single program runs like a dog and takes 100 times the resources. Only worse because it runs in a browser.
Some people don't like the word much, but "serverless" is going to become a bigger deal. You'll write your code, complex or simple; you'll hand it off to some cloud system; you'll write a bit of configuration; you're done. Likely the configuration part will become less and less required. You won't think about hardware, scaling, load balancing, etc, it will just happen for you. The data store being used will be abstra…
Earlier quoted context omitted.
It's the classic "Can't you just add another checkbox here?" situation. Yes, I can add a checkbox there. But I have to add the code to include that setting in the API that the front-end calls, to give you a way to retrieve it and change it. Then I have to add code to the data access layer for this new setting. Then I have to write the SQL scripts to add columns/tables for this new setting, as well as change scripts t…
Sounds like your framework sucks. With an orm and some sort of json serialization that's literally just: Put bagel in toaster. Update the db model. Add a migration. Update the viewmodel db model translation in relevant requests. Get bagel and butter it. Commit. Test the migration on a staging db if feeling paranoid, cause it's just adding a column. Push to master. Update production. Take last bite of bagel. If you ar…
Earlier quoted context omitted.
It's the classic "Can't you just add another checkbox here?" situation. Yes, I can add a checkbox there. But I have to add the code to include that setting in the API that the front-end calls, to give you a way to retrieve it and change it. Then I have to add code to the data access layer for this new setting. Then I have to write the SQL scripts to add columns/tables for this new setting, as well as change scripts t…
Sounds like your framework sucks. With an orm and some sort of json serialization that's literally just: Put bagel in toaster. Update the db model. Add a migration. Update the viewmodel db model translation in relevant requests. Get bagel and butter it. Commit. Test the migration on a staging db if feeling paranoid, cause it's just adding a column. Push to master. Update production. Take last bite of bagel. If you ar…
When your tables have millions of records for enterprise customers, it's significantly more involved than you describe
Some people don't like the word much, but "serverless" is going to become a bigger deal. You'll write your code, complex or simple; you'll hand it off to some cloud system; you'll write a bit of configuration; you're done. Likely the configuration part will become less and less required. You won't think about hardware, scaling, load balancing, etc, it will just happen for you. The data store being used will be abstra…
"Serverless" such as AWS lambda removes the ability to take advantage of so many Computer Science principles that are integral to writing a fast backend. From one request to the next there is no CPU cache optimization, in-memory caching, and no IPC to other useful programs. Serverless has it's niche for some tasks such as responding to events, but to do any heavy lifting I'd take a handful of beefy VMs over unlimited…
Earlier quoted context omitted.
This model isn't "serverless", it's PAAS. It's not much of a future. Heroku is useful for prototyping, not scale. (Edit: Doesn't mean it can't be more popular though - the web is full of prototypes) "Serverless" as in AWS Lambda has very specific use cases. The people who are serving websites on Lambda or something are not only doing it wrong, they are wasting money while locking themselves in to an architecture that…
People host their blogs on AWS lambda for less than dollar per month [1] compared to "standard" $5 or so for VPS. How's that a waste of money? Docker and containers are also a paradigm change, but the world seem to have adopted it just fine. [1] https://news.ycombinator.com/item?id=11644042
Some people don't like the word much, but "serverless" is going to become a bigger deal. You'll write your code, complex or simple; you'll hand it off to some cloud system; you'll write a bit of configuration; you're done. Likely the configuration part will become less and less required. You won't think about hardware, scaling, load balancing, etc, it will just happen for you. The data store being used will be abstra…
"Serverless" such as AWS lambda removes the ability to take advantage of so many Computer Science principles that are integral to writing a fast backend. From one request to the next there is no CPU cache optimization, in-memory caching, and no IPC to other useful programs. Serverless has it's niche for some tasks such as responding to events, but to do any heavy lifting I'd take a handful of beefy VMs over unlimited…
Everyone is ditching those beautiful and smart CS principles on FE by switching to hybrid apps, walking entire DOM on every update, etc.
There's no reason same wouldn't happen on backend. In fact it already has - interpreted languages, GC, micro services.
For better or worse progress in software always meant worse efficiency, because hardware was always forgiving that.