D Web Services Application Potential?

[yawniek via Digitalmars-d]

On Wednesday, 29 July 2015 at 14:17:34 UTC, Sebastiaan Koppe 
wrote:
> On Wednesday, 29 July 2015 at 07:30:50 UTC, yawniek wrote:
>> In times of reactive frameworks it makes no sense anymore to 
>> render html in the backend.
>
> Nowadays with the many client-side dom manipulations it is 
> tempting to just do it all in the client. But in terms of speed 
> it also makes sense to do an initial render on the server, and 
> only render the delta's on the client.
>
> On Wednesday, 29 July 2015 at 07:30:50 UTC, yawniek wrote:
>> backends/services should concentrate on data transformations 
>> (and security etc).
>
> Yeah, it makes it easier for frontend development to transform 
> data into a nice structure.
>
>> in my opinion also the REST style apis will come to an end as 
>> we can easily have
>> stateless apis these days ( 86.62%of browsers have websockets 
>> already according to http://caniuse.com/#feat=websockets ).
>
> Was a big fan of REST - but since it is hard to aggregate 
> requests, you end up making too many - so am looking for 
> alternatives.
> When you say stateful, what exactly do you want to keep between 
> requests?
>
>> The whole ghetto around maintaining state over http for a web 
>> application is nuts if you think about how native applications 
>> work.
>
> Care to elaborate?

check how volt or meteor work
e.g. https://www.youtube.com/watch?v=P27EPQ4ne7o
the idea is that you don't to the whole MVC pattern twice.

the controler or similar objects reside on the server side, 
reacting on events from both, backends AND frontend/views to then 
act and push data out to be rendered.
aka the data from the backend will not be transformed[0] again 
within the client prior to being consumed by the rendering logic.


[0] meaning that there is no datatype specific code or other code 
that can't be hidden away in a generic framework. you may 
transform it from msgpack/protobuf to javascript object etc..