Lately I've been working quite heavily in website development using D. More specifically Vibe. Coming from a PHP background this has shown to me just how different the two ecosystems really are.
Vibe is definitely one of the larger D based projects. Having other projects spawned off it e.g. dub. Without Vibe I definitely would not have chosen to work in D for web development at all. It is pretty much lets get as much in that framework without overpacking it mantra! Its not limited to just web development. It does have a nice little serialization library and Mongo database client.
So what exactly is missing from Vibe that would normally expected in a web server framework?
I discovered very early on that the default router was ok but it wasn't at a level I find acceptable. It was based upon registering functions/methods manually to the route it would handle. But what I want is a class based method. By class based it means I can group routes and disable them at compile time very very easily.
Now I first made the router using quite an inefficient means but it worked. I improved upon it based upon an issue that was raised for Vibe. That issue spawned a few new UDA's. Specifically RouteGroupIds. Basically what it does is allow for appending of ids on to the path. Instead of manually writing it out.
For my design I utilised UDA's for specifying e.g. the route and filters. To me at least if you have a router attributes come into it heavily. Its meta data that configures how it works.
My current design of the router hasn't changed much. But the way it works has. Heavily relying on templated functions to grab e.g. the path at compile time. From experience this seems to not break as easily. I had to rewrite it mainly because it decided to fail quite spectacularly on Windows. But yet work on Linux fine. Before this I had worked on my ORM which I will get to.
The ORM (Dvorm) is a different story. During the same issue as the router for Vibe it was mentioned how binding of data to database was to work (not for my one). And it occurred to me about a week later that I am manually creating the database implementation of a data model. So instead of doing that why not create an ORM to handle it? Sure it'll take about a week to do but why not.
The time it took me to actually build it would equate to about five days worth. This is very acceptable. If I were to compare this to PHP I would say that is awful. Now with PHP you don't have the option of doing anything at compile time. With D you can only do reflection at compile time. Couple this compile time function execution and mixins and you suddenly have the reason why it becomes longer in development time.
With D you have to think about three periods of time when code can execute. During compilation, at the start of execution and at execution when you need it. Three big time frames that you just _don't_ have with other languages. It makes it far more powerful. For example you can remove a lot of the runtime code just because of the compile time ness of it.
I think the extra time it takes to develop such a library is worth it. You just can't get the performance out of PHP even if you wanted to or any other language in fact. Most languages simply don't support the compile time features D does. I just can't sing the praise of that enough.
I'm actually very pleased with how Dvorm turned out. Its completely database independent. Although I think at some point I would like to fix the Mongo database provider so that it builds the query as requested. Instead of compounding it together in the store.
There is also a few other features I want to add e.g. Mysql provider and count on query. But nothing too major.
An issue I had while rebuilding the site after the initiation of the ORM and moving to Windows for testing instead of a VM. Was that my session storage broke. My next version of that was database independent thanks to Dvorm. It also meant that even without the actual session system I would have session storage in the database.
Unfortunately Vibe has very low capability for iterating development fast. But given enough time I believe it'll get a lot better with shared library support once that has been fully added to the compilers.
Hosting may be a problem in the future, however slap on a load balancer on top and have a few nodes and it'll run very well.
I really believe that D is a great choice for medium to large web development projects. It has a lot of features including unittests built in that simply aid in making sure less bugs escape development.
Libraries may be lacking currently but once they are built there really shouldn't be anything holding anyone back from choosing D for their next big web service!
At this point in time though development of the libraries most commonly wanted does add extra time upon development a lot. But if done to D communities standards should mean a very clean interface and easily expanded upon. Meaning less maintenance on site itself and easily added upon.
No comments:
Post a Comment