Can somebody please show a enlightening example of, so called,

"revamp of the REST interface generator"

added to release 0.7.26 at:

http://vibed.org/blog/posts/vibe-release-0.7.26

I want to use vibe.d to add a modern dynamic web-interface to my knowledge graph I'm currently developing.

More specifically I would like an interface that makes rich use of dynamic HTML. When the user changes the contents of a search/command-line text-field the client logic shall on the fly (after a certain delay) lookup related information with vibe.d-server and present the user with relevant hits or completions in a another part of page (HTML div-block).

Does anybody have a similar vibe.d-project to be inspired from, in this regard?

On Monday, 30 November 2015 at 10:08:17 UTC, Nordlöw wrote:
> Can somebody please show a enlightening example of, so called,
>
> "revamp of the REST interface generator"
>
> added to release 0.7.26 at:
>
> http://vibed.org/blog/posts/vibe-release-0.7.26
>
> I want to use vibe.d to add a modern dynamic web-interface to my knowledge graph I'm currently developing.
>
> More specifically I would like an interface that makes rich use of dynamic HTML. When the user changes the contents of a search/command-line text-field the client logic shall on the fly (after a certain delay) lookup related information with vibe.d-server and present the user with relevant hits or completions in a another part of page (HTML div-block).
>
> Does anybody have a similar vibe.d-project to be inspired from, in this regard?

I have written a mpd (Music Player Daemon) client in D and just finished the web app (bar a couple of features).

All of the rendering is done on the client and only json data is transmitted between server and web app. Just finished the WebSocket part so if anybody changes the music/volume/playlist, all clients update the interface.

The code could use a cleanup/refactoring but everything is working.

The D parts of interest are the MpdApiInterface1 and MpdApi1 classes in source/app.d

For the JS parts you can start with source/index.js, but its full of ES6 classes and react code. So that might not be your cup of tea. In index.js there are mainly React Classes (basically html renderers) and React Container Classes (basically code handling input changes).

In the source/actions folder there are some js files that call the server and modify state (volume/song). In the source/stores folder, some js files that only retrieve data.

The js architecture if influenced by react/flux/facebook's, but I am toying with it to see what fits for me. Specifically I rely a lot on RxJS for the observables.

For the project I decided to put js and d files in the same folders. That might not have been a good idea. Also dub has some issues with one of the D dependencies that I haven't updated in months.

Code can be found here: https://bitbucket.org/skoppe/mpc/src

On Monday, 30 November 2015 at 20:05:42 UTC, Sebastiaan Koppe wrote:

> Code can be found here: https://bitbucket.org/skoppe/mpc/src

Looks good.  Have you looked at Redux and Webpack?  I am working on a Redux example and we have switched to Webpack and Redux at work and it is nice.

On Monday, 30 November 2015 at 20:23:48 UTC, David DeWitt wrote:
> Have you looked at Redux and Webpack?  I am working on a Redux example and we have switched to Webpack and Redux at work and it is nice.

I know about both yes. Webpack would probably beat browserify, but I haven't gotten the time to migrate myself. Their hot code reloading looks good though.

Isn't redux the client side for GraphQL? I followed it a bit but it being so fresh, decided to wait.

A GraphQL interface generator for vibe.d would be nice.

On Monday, 30 November 2015 at 20:38:12 UTC, Sebastiaan Koppe wrote:
> On Monday, 30 November 2015 at 20:23:48 UTC, David DeWitt wrote:
>> Have you looked at Redux and Webpack?  I am working on a Redux example and we have switched to Webpack and Redux at work and it is nice.
>
> I know about both yes. Webpack would probably beat browserify, but I haven't gotten the time to migrate myself. Their hot code reloading looks good though.
>
> Isn't redux the client side for GraphQL? I followed it a bit but it being so fresh, decided to wait.
>
> A GraphQL interface generator for vibe.d would be nice.

Redux is luscious!!!  It is a flux-like implementation but you dont have to deal with individual stores as the app's state lives in a single object tree. Once you go thru it you'll like it.


https://github.com/rackt/redux

https://github.com/xgrommx/awesome-redux

Am 30.11.2015 um 11:08 schrieb Nordlöw:
> Can somebody please show a enlightening example of, so called,
>
> "revamp of the REST interface generator"
>
> added to release 0.7.26 at:
>
> http://vibed.org/blog/posts/vibe-release-0.7.26
>
> I want to use vibe.d to add a modern dynamic web-interface to my
> knowledge graph I'm currently developing.
>
> More specifically I would like an interface that makes rich use of
> dynamic HTML. When the user changes the contents of a
> search/command-line text-field the client logic shall on the fly (after
> a certain delay) lookup related information with vibe.d-server and
> present the user with relevant hits or completions in a another part of
> page (HTML div-block).
>
> Does anybody have a similar vibe.d-project to be inspired from, in this
> regard?

This would be more targeted to the web interface generator (vibe.web.web), which is not affected by the changes mentioned above, but the interface is pretty similar. For a very simple example, you can have a look at this:
https://github.com/rejectedsoftware/vibe.d/tree/master/examples/web_ajax

On Tuesday, 1 December 2015 at 07:04:25 UTC, Sönke Ludwig wrote:
> Am 30.11.2015 um 11:08 schrieb Nordlöw:
>> Does anybody have a similar vibe.d-project to be inspired from, in this
>> regard?
>
> This would be more targeted to the web interface generator (vibe.web.web), which is not affected by the changes mentioned above, but the interface is pretty similar. For a very simple example, you can have a look at this:
> https://github.com/rejectedsoftware/vibe.d/tree/master/examples/web_ajax

I have seen a lot of sites using this approach. I feel that once complexity increases (more dynamics, popups, real-time validation, spa) it runs into some maintenance issues.

Let me elaborate. In the beginning all html is generated on the server. Then more features are added and slowly more html is generated/manipulated in the client. Now you have this split-brain were html is generated both on the server and the client, but both in different languages, with different template engines. To put it simply, it doesn't scale well.

The solution would be to shift the generation of html to the client (for example see trello, digital ocean, etc.). The only issue there is that the first page load takes longer. This can be solved by rendering the first page on the server. With nodeJS this is easy since you can reuse the same code, with D this is a little harder.