jay's old blog

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

Project TD - Day 28 update – Design for the Modules of API Engine



[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]

I have already blogged that the entire app ecosystem depends on what the heart pushes and collects. The heart being the API Engine. I have written multiple times that the whole system must be modular so that parts can be replaced and re-engineered if something goes wrong. Or, if there is an opportunity to make things better tomorrow, then, that option should be readily available.

To that effect, I have come up with a design plan (pictured above) that should drive all engineering efforts towards the API modules. It’s a simple and plan design, but it should be enough to help me. Obviously, it is subject to further revisions if the occasion should call for it.

Pick an API

The API Engine is but a collection of API calls running on a single API server. On one side, it provides access to facilities to end users. On the other side, it has the necessary access to the underlying database. As of now, 12 API calls that would form the first batch of API services that will be part of the API Engine.

The idea is to pick up, one API service (each of them will have their own designs) and then start working on it. First step would be figuring out the design which means, illustrations, finite discussions about its usability with the stakeholders. Once the design is confirmed to work (to the best of data available), then we move on the technical part of it.

For instance, for the patron app, there would be one service that pushes the restaurant data to the server. This would be one API call. So, I would start off by designing the work flow. Show the workflow to as many people as I can (my, mom friends, my tech mentor, the many students who are under charge and of course, random strangers) and collect its feasibility. Use this feedback data, and design the final workflow.

Identify all tech

At this stage, the design and the flow of activities of each identified API has been done. The API design itself is completely independent of the underlying tech that will actually power it. For instance, the design is like I wake up in the morning and decide to have breakfast. The actual activity of eating breakfast might involve many things. I could have a pack of biscuits. Two packs of milk. A luxurious breakfast at my folks place. Or go out and pay a decent amount and generous tip at my favorite restaurant. As you can see, the decision to have breakfast and actually having it, though related, are quite independent of each other.

Similarly, the design is always independent of its implementation. It’s part of the modularity and replacability thing I keep going on and on about. Here, I will be thinking only of implementation and not question the design choices.

Earlier, I mentioned an example API service that pushes data from the patron app to the cloud. So, I need to figure out all the technologies that will make this happen. It would mean, I need to build a web app, android app and a iOS app that has a simple button. This button would collect data (that mean, I need to figure out how to collect data on all these platforms) and trigger a cloud push on button press. Like this, I break down the design into individual components and see how the code would actually work for these things.

Repo it

Once the tech part has been figured, the next part is pretty straight forward. I have already promised that a lot of stuff related to the project would be open sourced. Anybody can use it non-commercial uses. So, I will push the code of the web stuff, the cloud things, the app solution, everything on a public repo.

Tutorial it

The repo will have the code. As is my standard practice, I write pages and pages worth of documentation within the code. However, it helps me (and my career) to have some tutorials that point to the approach I took while converting the design into runnable code.

Unit Testing

Once the repo and tutorial is done, I need to check the individual fitness of the resulting module. This will ensure that the unit itself is independent and will involve writing dummy external connections.

Integration Testing

Once the unit is confirmed to be fit to work, next comes the part about integration. I have to check if this module will work with the rest of the modules. I also need to check to make sure that the system won’t come crashing down when the module dies or goes corrupts or simply stops working for some insane reason.

Once the integration testing is done (if it fails, I will probably have to restart at the design stage and work down from there), I put the module aside, and start over by picking up the next API service to work on.

Rinse and Repeat

This part is useful when, at a later point, if some new tech is introduced which will make things faster. Or perhaps some technology on which the app depends gets rebooted and revised. For instance, Microsoft might replace their existing mobile data service with a new one. Or, Facebook might implement a new login system. There are so many gears moving here man, anything can change.

Anticipating change and being ready adapt is the only way I can keep this engine relavant and allow it to evolve.

Note about Sketchbook from AutoDesk

I have upgraded from hand written illustrations to using the Sketchbook app by AutoDesk on the iPad. For the purpose of drawing, I am using an Amazon Basics stylus. I must confess, there are some serious advantages to using this over the hand written thing. Obviously, the free app has certain limitations. For instance, I can only have 3 layers (which is alright but annoying) and I cannot select components (which is the biggest handicap of the free version). Eventually, I will have to get the pro membership, but I have to evaluate this system first. Once I am satisfied, I will kick things up a notch with the pro membership which provides tools for desktop and android as well. It is fairly inexpensive and should be useful.

The Amazon stylus is extremely basic, and there is a learning curve involved here as well. I feel that it is good enough for now. If this art design thing goes to the next level, I will probably spring for a Wacom stylus for a better control over the designs. For now, I am still trying to figure out the stylus.

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