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