jay's old blog

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

Project TD - Day 59 update – Core Tech – Web api module and migrating to new blog



UPDATE 2!!!!

Alright, my new blog is now up and running. Find it here - https://thesanguinetechtrainer.com 


UPDATE!!!!

Okay. This is weird for me. For the last few days, BlogEngine.NET (the software that powers this blog) has been acting crazy. I have spent a good chunk of time troubleshooting (after all, I am myself a dot net developer and this thing was built using dot net, and I have come to a realization that, there is not fixing this. No one else is facing this issue.

I dont think it is a connection issue to the web server, because the blog itself is running just fine.

I dont think it is a database issue, because the blog does not use a database.

I thought there would be a easy way to export my blog to elsewhere, but nope. This blogengine software is not popular enough to merit that.

and, since I cannot create new posts (fortunately, existing posts can still be edited and updated) I am updating an existing post. I suppose I should be happy that at least this is working.

I am currently exploring both wordpress and medium as my next blogging software. I like the look of medium, so I will probably go with that. I still dont know how I will move all the stuff from this blog to the new medium blog, but right now, I need a place to write and publish. Or else, I will lose my mind. and fast, at that.

--------------------------------------------------------------------

When discussing the API engine, I put a flowchart in place that dictates how I would work on the different modules of the entire app ecosystem of project TD. Then, I further broke down the api engine into simpler modules, which I have discussed here. Here is that list, for reference.

  1. 1.       Build and Deploy an API
  2. 2.       POST and GET to the API
  3. 3.       PUSH and PULL from the API to the Data Service
  4. 4.       Google Maps API on Android, Web and iOS
  5. 5.       Facebook Login API on Android, Web and iOS

Obviously, I realized that some changes were needed, and here is the revised list of the simpler modules.

  1. 1.       Build and Deploy API (this includes the POST, GET, PUSH and PULL from the above list)
  2. 2.       Android app that works with the above API.
  3. 3.       iOS app that works with the above API.
  4. 4.       Web app that works with the above API.
  5. 5.       Google Maps API on Android, Web and iOS
  6. 6.       Facebook Login API on Android, Web and iOS

From the above list, 1 and 4, are completed. I mean, in software, there is no such thing as completed, but it is completed to acceptable levels. This blog, talks about 1 and 4, and I will move on to item 2/3/5/6 next.

As I have already decided, much of the back-end stuff, that is the API, is being built using .NET and that means, I get to use my favorite language c # for all of this. That much is done. I am using web api 2 technology for this. Since I don’t wish to manually create the tables for this service, I am using entity framework, version 6, to act as the agent between the api app and the database. For the database, I am using Microsoft SQL server, and for the hosted web app where the api would live, I am using an IIS server, powered by Microsoft technologies. All the server components are hosted on Microsoft Azure, and the cost, so far, (at the time of this writing) less than 500 rupees per month. Of course, this is a test server, and the load on it has been kept at extremely low levels. I am sure the actual cost when the full api ecosystem launches will be in triple or even quad digits.

While building this api, I ran into Knockout JS. I hadn’t used that one before. I also ran into attribute routing, which is a fun feature and I am surprised that it is a recent addition. I sort of assumed that it was always there. I also learnt about action names, but I think attribute routing sort of makes it redundant, but it is good to know it is there. Of course, the current api only communicates in text data, which might become a problem later when I wish to deal with multi media. However, from what I heard, the necessary modifications should not be a problem.

I am not currently satisfied with the way the web app works. It takes raw data, JSONifies the data on its own before consuming it. The web api does have components that return data in both raw format and JSON string format, so perhaps at some future time, I will build a web app that works with the JSON calls. For now, though, I will stick with the default web app built using Knockout JS.

The api is living on the cloud, and I have now completely abandoned the (soon to be retired) classic azure management portal. The new azure portal is sort of heavy on the system and it has this sliding interface which makes it difficult to work with. Especially as more azure components are loaded. However, it has all the new stuff, and for good or bad, Microsoft has been pushing the new portal for at least 3 years now. I guess, it is time for me to go with the change. I still don’t like it, but it is the future, so I am bending backwards for that.

As always, my tech guru, mika has been wonderfully helpful while building this. I want to thank him for his help, and hopefully, I will return the favor someday.

Alright, enough of the diary writing. You can find the two repos related to the above components, here and here. You can find the web app demoing the api, running at this link. Obviously, the repo has all the comments I can put and relevant links and stuff.

Alright, that is all for now.

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