As you may know, I’ve been working on my first NPM package which is simply a SQL Builder and converts the method calls into a SQL string (specifically MySQL at present, but that should include others in the future). The reason I’ve been working on this, is partly to improve my NodeJs skills, and partly because of an idea I’ve been having for a ORM that is hopefully as easy to use as Active Record but has more of a Data Mapper design.
While immersing myself in NodeJs, and to be fair dabbling with real-time events in PHP (powered by Socket.io and Laravel) I’ve been wondering whats the best way to use bi-direction data flow and the WebSocket Protocol.
The traditional way to produce an app is with REST endpoints and the request/response workflow. Now with NodeJs and WebSockets we can totally invert the universe and use pub/sub to provide data to the UI.
I spent a lot of time recently looking into NodeJs and how my PHP experience translates. From performance considerations to traditional PHP esq Interfaces and how to tackle them. Now I’m at the point of how to structure a full-blown application and how traditional design patterns like Service Location, Inversion Of Control, and Factories fit in with the module driven architecture of NodeJs.
In the first post of this series we looked at how Interfaces work, and if NodeJs could/should have them.
In this part I’m going to look at how we can in the context of an app get the benefits of Interfaces without actually having Interfaces, and it centres around service location, proxies and the module system.