This is the strangest topic I’ve ever used in an article so far. After I wrote it I pondered on whether to change it or not, but I think it fits perfectly to my experience — so I decided to keep it.
Well, I’m new to Software — specifically web development. I started it from a very small PHP application where I had to implement a Pharmaceutical grocery display. I had to connect my application with a centralized database where it was accessed by both a desktop application (A Point of Sale) and a web application. I used vanilla PHP without any framework — at that time I thought that it was a great piece of software that I wrote because it worked perfectly.
I had projects after this but non of them covered the whole workflow of an application.
After all these, I had a Full Stack project where I had to develop a developer’s profile analyzer. I was given the problem domain and unlike previous projects I had been involved, I had to choose the technology stack, dependencies, adapters, and APIs. Here onwards, I’m gonna confine my article to this particular project.
A little about the application itself
The application is without a doubt a simple one. So I decided to make the UX at its best and utilize the cream of latest technologies to its best.
Choosing the technology stack
Well, most of us do dive straight into the implementation. That’s the gut feeling of developers — nothing we can do about it. But in my opinion, how an engineer should view at a problem is not towards the implementation. He/she should focus on the Design. That is where all your infrastructure lies. A design could be anything — a scribble on a piece of paper, or a Lucid Chart document, a flow chart, a graph or anything. For examples — a component diagram for Angular, and a layered diagram for MVC, class diagram for OOP, etc. Well, even though there are standards for depicting these designs, I believe if you come up with a diagram which describes your infrastructure properly, you should go with it. The chances are that from this, you might, of course unknowingly, have followed the standard already.
So I decided to scribble out a design and then choose a technology. Thus, I chose MVC as the overall application architecture.
Choosing a framework for V (View) was a little difficult because of the vast technology array that is present today. I had a major conflict of choice with React and Angular (I knew that Vue is a little hard documentation wise) because both are component based (I had a component based architecture for View in my design). I chose Angular because I like the way how they implement the concept of Separation of Concerns (I know this has a little doubt on how Angular implements this with the core concept itself. But anyway I chose to go with it).
Choosing a server-side framework was not that difficult — I wanted to learn java so I chose Spring Boot :D
Then I decided on the dependencies I wanted to use. I decided to have some adapters to make requests to APIs easier (Probably faster than the general Rest Template class). Since Angular is so popular these days, you can find almost any dependency that you look for in npm repositories. So I found the dependencies I looked for.
I would not go to the dark side of the planet here — but I will dive into the important parts; the issues I faced and how I overcame them.
Different versions of Angular modules
Angular comes up with a bundle of modules. The issue is some of them are deprecated. You got to be intelligent enough to filter out the deprecated ones and utilize the correct module. For an example,
Http module is replaced with
HttpClient in Angular 4 — thus you might as well use
HttpClient instead of
Http . (I would not go into the differences in both modules here). The most effective way to do this is to have a look at the official documentation. This is very important for any other framework as well. I recommend choosing a well documented technology when you select your technology stack because eventually, you’re going to need help.
Adapters / Wrappers
When you’re dealing with external web APIs, you’re going to get into Paginated Responses. The standard is, that if you are implementing a RESTful API, it is better to have paginated responses because it consumes less from your servers per a request. So when you consume from external REST services, you’re going to need to traverse through pagination. GitHub themselves use something called Hypermedia Link Headers which consists of a
next parameter if you have more responses left. Usually in these kinds of situations, you can use the Iterator design pattern. Or you can find helper interfaces for pagination like
PageIterator in adapters. Using the proper wrapper/adapter at the correct place can save you a lot of time. This does apply the best for very high end projects like Data Mining and Machine Learning. You have plenty of external libraries where you can get use (for examples Numpy, Tensorflow, Scikit Learn, etc.) and you can get use of them unless you need a customized version of these libraries. So it is wise to use a third party library whenever it is possible but keep in mind that some of these libraries can run out of support — so make sure you check their GitHub repository for issues, projects etc.
Best practices are obviously, come from practice. But you have another way to get best practices into your knowledge base — that is, by reading. When I was writing code in my project, I had like three or four ways in my mind to implement one function — but I checked the internet to absorb the best practice. One example would be to have a service layer in between the controller and the database! Such small thing but it can make your code look cleaner and smarter. So always try to sit back, relax and read morning blog posts on coding, and technology. I have a great deal of knowledge accumulated from morning blog posts of Medium (Which I recommend to everyone) and if I can do it, you all can.
I feel like that this article is getting a bit longer so let us continue this at the next one :)
Click here to read Part — II.