Thursday, 4 April 2013

Part 4: Functionality overview

Okay. enough with running around theoretical circles, time to get straight to sources and check what vibe.d actually does provide. Aim of this part is to provide a small overview of available modules and usage options. Most likely anyone who has been trying to use vibe.d on their own will know everything mentioned here.

As most D libraries, it is distributed in source-based form with few extra linker dependencies like libevent or ssl. Some install shell scripts are provided with sources, but native packages do exist at least for Ubuntu and Arch Linux. What install script actually does, other than adding some users and/or groups, is adding "vibe" script to run path. This is the one you actually want to use when starting vibe.d experiments, as it does all magic related to basic dependency tracking and application building, all you need is simply run "vibe" in project root folder. Of course, you can provide all needed paths and libraries manually, simply building via (r)dmd - in fact, that is exactly what I do. No special custom stuff happens here, it is all based on plain D module system.

Main vibe package does consist from the following sub-packages:
  • core : In fact, this the only crucial package. After all, vibe.d is an asynchronous I/O event-based framework, and this is the essence of it. Event drivers, concurrency modules, some basic utility like logging. It is quite reusable, so that you can build your own service on top, not necessarily even web service.
  • crypto, textfilter, utils : obvious straight-forward utilities that hardly deserve any special comment.
  • inet, mail : same, but for protocol handling. You won't notice them unless doing some advanced stuff.
  • data : json module is of most interest here. It has no other vibe dependencies and is much better than std.json in my opinion, at least considering API. His binary brother, bson, is also here, mostly for MongoDB driver, but it is also quite usable schema-less binary serialization format on its own.
  • db : only MongoDB and Redis are available by default. mySQL driver exists in the form of dub package. One one of most lacking areas in my opinion, adding PostgreSQL is on my TODO: list, but I am not doing any real web dev now, so.. Anyway, adding new drivers is quite easy, requires some knowledge about core event framework though.
  • http : of course, most of functionality here is obvious from name, but there are also few special stars here - rest and form modules do some impressive compile-time reflection magic to provide very convenient means for REST API and HTTP form generation based on D types. Those are worth separate article.
  • stream : abstraction used by inner vibe.d implementation. I don't think it is supposed to be used in application code.
  • templ : everything related to Diet templates lives here. This is important one, as you most likely want to use some template system if your web application does produce any HTML at all. I have no idea how good this specific one is, as it not my domain of knowledge, but worked for my simple experiments. It is worth stating that Diet templates are prepared for use at compile time and are thus very fast but consume hell lot of compiler resources.
  • vpm : will probably vanish at some moment. It is initial implementation of simple package manager for vibe.d and is now superseded by dub, more generic one that is pushed as a possible standard D package manager.
Any additional packages for use with vibe.d can be found in vpm/dub registry : http://registry.vibed.org . Activity is growing there quite rapidly as vibe.d gets wider attention.

What is easy to notice here is that current vibe.d distribution organization is far from perfect. It suits for a wide variety of different applications and often full load of modules is not needed. Sub-packages are mostly independent from each other but there is no solid distinction between ones more oriented on inner implementation and user ones. In some way it highlights weaknesses in current D module system, but main idea here is that vibe.d can benefit from being split into smaller more distinct packages so that you can chose ones you need via dub. It is not yet known for me how this change may look like - I have simply summarized different comments on topic from Sönke Ludwig, one of the main vibe.d developers.

I'll give a more detailed overview of some especially interesting modules in next parts.

No comments:

Post a Comment