jay's old blog

this blog will be deleted soon - please visit my new blog - https://thesanguinetechtrainer.com

Choice of Technology for API



[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 calls.

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 alternative. Yeah.

[Last Updated February 10th 2017]

Follow me on twitter, facebook and instagram for more updates. Thanks!

Comments are closed