[Ongoing series of blog posts to inform
potential developers, users and (hopefully investors) about this new app
ecosystem I am architecting, designing, developing and deploying. More details
at this page]
At the core of any ecosystem is the API system. The API is
consumed by the apps, that are in turn used by the users. They could be the
apps used by the operations team. Apps used by the administration team that
oversees user content that is pushed. Apps that are used by the restaurant
owners and of course restaurant patrons. All of them will interact with the
cloud storage that actually serves and takes data over a collection of API
That is why, the choice of technology used to build the API
is important. As much as possible, the whole eco system will take a modular
approach to development. If some technologies should die (which happens more
often than you might think), we should be able to remove things and replace
them without affecting the rest of the components in the ecosystem.
Although the API system is also modular (at the end of the
day API calls are but simple web routes) and follow the remove and replace
principle. Still though, rewriting the API itself will be a huge task. That is
why, if I am going to choose an API technology it must be something that I will
keep for a long time and only replace it if I have no other choice.
There are quite a few technologies out there that can be
used build RESTful API’s – Node.js, PHP, Python, Rails, Dot Net and Java.
First up, I am not a big fan of PHP. Because, with all due
respect, PHP HELL.
That leaves other technologies of which I am not going for
Java because, I have already invested a lot on c sharp and I am not going to
spend an equal amount of time on Java, unless it is a matter of survival.
Python, Node.js and Rails are things that I am familiar with
but it makes sense for me to leverage on my existing dot net skills, which is
where DOT NET based API building comes into the picture. As it is, the project
uses a lot of Microsoft technologies (except for the android mobile, almost
everything else depends heavily on Microsoft related technologies) and using
the same thing for API reduces total effort time.
However, as far as planning goes, if it comes down to using an
alternative, I would side with node.js. It seems to be the one that is much
more modern and well document among other alternatives. So, that would be the
[Last Updated February 10th 2017]
Follow me on twitter, facebook and instagram for more