I think there is a lot of opportunity in that "never" space. Clients, even phones, today are more powerful than servers of not long ago. Why pay google or amazon for CPU when you can get your user's CPU free and provide them a better, faster service? I'm not the only one who things so, sheck out AWS GreenGrass. docs.amazonaws.cn/en_us/greengrass...
Sure I suppose so but in my experience allowing yourself to process data both on the frontend and the backend only introduces unnecessary problems.
I think the most glaring problem is that you need to ask yourself where data should be processed whenever there is a need to process data. Consider a website which stores timestamps in its database. More often than not you'd like to show your users a nice, clean date string instead of a timestamp. Where should that formatting happen? That is data processing too after all. Should it be done client side? Server side? Instead of dealing with that dilemma you might as well process the data where it is - the server side, the backend. In my example of timestamps I like to tell the database in the query itself how I want my date to look like.
Yes data processing requires CPU but how much CPU do you really need anyway? And we're not getting the user's CPU for free. There are lots of people who don't have powerful phones and every millisecond spent in processing data shows. If you really need that extra CPU for data processing (What are you doing anyway? Image resizing? Video compression?) then consider using queues and queue workers.
Since the original discussion is about websites we should talk about JavaScript. You need JavaScript to do data processing client side. You have no guarantee JavaScript will be available client side. Here are some reasons why:
User disabled JavaScript
JavaScript could not be downloaded
User agent may not support JavaScript
User agent may not support the version of JavaScript downloaded
And as for Greengrass, this is what the docs say:
AWS IoT Greengrass is software that extends cloud capabilities to local devices. This enables devices to collect and analyze data closer to the source of information, react autonomously to local events, and communicate securely with each other on local networks. Local devices can also communicate securely with AWS IoT Core and export IoT data to the AWS Cloud. AWS IoT Greengrass developers can use AWS Lambda functions and prebuilt connectors to create serverless applications that are deployed to devices for local execution.
I've never done IoT, let alone use Greengrass, but this to me clearly reads as a backend-frontend setup where the lambda functions are the backend and the device sensors or whatever is collecting the data is the frontend. Even here you're not doing the data processing on the frontend.
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.
I think there is a lot of opportunity in that "never" space. Clients, even phones, today are more powerful than servers of not long ago. Why pay google or amazon for CPU when you can get your user's CPU free and provide them a better, faster service? I'm not the only one who things so, sheck out AWS GreenGrass. docs.amazonaws.cn/en_us/greengrass...
Sure I suppose so but in my experience allowing yourself to process data both on the frontend and the backend only introduces unnecessary problems.
I think the most glaring problem is that you need to ask yourself where data should be processed whenever there is a need to process data. Consider a website which stores timestamps in its database. More often than not you'd like to show your users a nice, clean date string instead of a timestamp. Where should that formatting happen? That is data processing too after all. Should it be done client side? Server side? Instead of dealing with that dilemma you might as well process the data where it is - the server side, the backend. In my example of timestamps I like to tell the database in the query itself how I want my date to look like.
Yes data processing requires CPU but how much CPU do you really need anyway? And we're not getting the user's CPU for free. There are lots of people who don't have powerful phones and every millisecond spent in processing data shows. If you really need that extra CPU for data processing (What are you doing anyway? Image resizing? Video compression?) then consider using queues and queue workers.
Since the original discussion is about websites we should talk about JavaScript. You need JavaScript to do data processing client side. You have no guarantee JavaScript will be available client side. Here are some reasons why:
And as for Greengrass, this is what the docs say:
I've never done IoT, let alone use Greengrass, but this to me clearly reads as a backend-frontend setup where the lambda functions are the backend and the device sensors or whatever is collecting the data is the frontend. Even here you're not doing the data processing on the frontend.