Gitlab- Design your GIT repository layout for continuous development and integration

 

GitLab is a web based collaboration tool built on GIT repository. GitLab’s community edition is free and we can setup a private hosted GIT repository on our server. GitLab provides a web based UI to manage the user accounts, repositories, projects and many other services it offers. GitLab runner is a deployment tool, where you can deploy your application using any deployment tool like “Docker” whenever a merge or commit runs on repositories.

Here we consider only the central repository, not the local repository layout. Layout design is applicable to GIT repository hosted on any platforms like GitHub, GitLab etc. When we think about multiple people working on the same project, the design of the repository layout matters. It is up to you to choose your repository layout which is suitable for your development environment. When we have a continuous development and integration on a project, my idea is to use multiple branches for each feature we prepare. GIT’s branching is very cheap and faster than any of the similar version control system.

Here is a layout i like to use with larger projects. In my repository, there is a master branch which is the primary source for the projects. Along with the master branch, i have 2 other branches which exist while there is a development progresses, which are “QA” and “Development”.


/master
/development
/qa


 

To start , all the branches may be blank. We have to create multiple feature branches for each feature developed by the developers. When the feature is completed, it will be committed to the local repo and pushed to remote / central repo (into feature branch).

For example, we have 3 features “Login”, “Customers” & “Products”, the layout of the repository changes as follows :


/master
/development
/qa
/feature-login
/feature-products
/feature-customers

 

When developers finish working on the “Login” feature, the branch is updated with the latest work. Similarly all feature branches are updated by git push command when they are ready for integration. The feature branches are merged in to the “development” branch. There is chance of merge conflicts which has to be resolved by the developers locally or during the merge process. From the development branch, application code can be deployed in to a development server and further developer testing is done. At one point, the development is over and the application is ready for testing. In my case, i have a separate test server, and i merge the development branch in to the qa branch. Test server is ready with the code from the qa branch, testing goes on.

In this kind of approach, the developers should have access to only the feature branches where they work. Al these merging and deployment should be done with an administrative privileged user. After merging the features in to the development, we can remove the feature branch from the central repo. Suppose, Q/A is finished and released the bugs report, again the developers has to checkout a working copy from the development branch and they start fixes the bugs.

After finishes the bug fixes, again the feature branches are merged in to development and when ready for testing, again in to the qa branch. This continues till we have a release for the project which is accepted by the product owner.

Each release can be created using GIT’s tags. Whenever the feature is resealed master branch is updated. Thus, the master branch will hold the latest working project whereas the releases keep track of the versions we create.

In GitLab, for each projects and repositories, there is many features associated and accessible through the web based UI.  We can report issues, create wiki pages, create pipelines to automate the deployment using GitLab runner, host any code snippets etc.

Start using the GitLab and set up your private repository.

Angular – Storing your JWT and use in All Request

Angular JS is one of the top JavaScript framework to build Single Page(SPA) web applications. When you work with single page applications, obviously there is angular services which consume Restful web services written in any server side languages.

Today i would like to share a piece of code to store the token received from a web service and use this token in further calls to the web services in the form of HTTP request header. Token authorization is the widely used authentication mechanism for REST web services. Each time, when you call a protected web service, you have to authorize the calls using the Token (JWT) received from another service.

Following code explains how to do this.

var webapp = angular.module('loginApp', ['ngStorage']);


Above code initialize an Angular app. This will create an angular app with name “loginApp” and we can bind the app to any HTML element. To store the JWT token in local storage, we will use “ngStorage” component. See here :

Assuming we have the Angular services written for authentication, we write the logic to store the token received from the response in our local storage. Following code gives an idea about the login service which calls the actual web service.


this.login_user=function(formData){
var promise= $http({
method : 'POST',
url : 'user/login',
data: $httpParamSerializerJQLike(formData), // convert object to url encoded params
headers : {'Content-Type': 'application/x-www-form-urlencoded'} // post data as form data instead of Json Input
})
.success(function(data, status, headers, config) {
return data;
})
.error(function(data, status, headers, config){
return data;
});
return promise;
}

To execute this, we should write the logic inside the Angular controller of your choice.

var data_post = { email:"someData",password:"someData"}
dataService.login_user(data_post).then(function(promise){
if(promise.data.error==0){
console.log('Login Success');
console.log('Token '+promise.data.token.token);
$localStorage.token = promise.data.token.token;
$localStorage.$save();
$state.go('app.homescreen'); // switch the View // optional//
}else{
console.log('Login Error');
}
});

From the above code, when there is a successful response from the login service, the token received is stored in the local storage.

$localStorage.token = promise.data.token.token;
$localStorage.$save();

Now, we have successfully stored the token received from our login service. In all further request to the web services, we will send the token in HTTP header. To do this, we will create an HTTP interceptor in our main JavaScript file where we initialized the Angular app.


webapp.config(["$httpProvider", function ($httpProvider,$localStorage,$q,$injector) {
$httpProvider.interceptors.push(['$q', '$localStorage','$injector', function ($q, $localStorage,$injector) {
return {
'request': function (config) {
console.log(config.headers);
config.headers = config.headers || {};
if ($localStorage.token) {
config.headers.Authorization = 'Bearer ' + $localStorage.token;
}else{
// alert("No token");
}
return config;
},
'responseError': function (response,dataService) {
if (response.status === 401 ) {
//Do something //
}
if(response.status === 402) {
//Do something
}
if (response.status === 404) {
//Do something
}
if (response.status === 500) {
console.log("An Internal Server error occured ");
}
return $q.reject(response);
}
};
}]);
}]);


We have 2 interceptors, one for HTTP request and the other for HTTP response error. In the request part, if we have a token present in our local storage, we send it along with other HTTP request headers . This will execute for all outgoing request to the web services.

config.headers.Authorization = 'Bearer ' + $localStorage.token;

In the response error section, we identify the HTTP status code. Most of the web services return status code 401, 402, 403 etc which are related to token authentication, expiry etc. This should be a good method to check the status code and decide what to do. In our case, we may refresh the token when we detect a token expiry, and we can write the logic inside the if block.

Finally, this is based on Angular version 1 .

Concept : Restful Web Service Design using Laravel

Concept – Experimental

Laravel is most suitable for the design of service driven applications. I would like to share a design concept which may be useful for building services which are loosely coupled and communicate each other through dependency injection. Before we speak about the web service design, we should be familiar with some design pattern available with Laravel and some of its architecture components.

Service Providers

Service providers are the central place of all Laravel application bootstrapping. All of the application logic, Laravel’s core services are registered through the service providers. In our example design, all of the web services are registered through service providers. You can see the service provider classes loaded in the application by looking in to the provider’s array in app.php file in Config folder .

Service Container

Service container is the powerful tool for handling the dependency injection. Class dependencies can be injected in to class through constructor.

Contracts

Contracts are set of interfaces that define the core services offered by Laravel. We can define a contract for our services which are part of the application logic and bind an implementation of the concrete class through a service provider. This will ensure much higher level of abstraction.

Repository Design Pattern

Repository allows all your code to use objects without having to know how the objects are persisted. The repository contains all the knowledge of persistence, including mapping from tables to objects.

My Design Concept for Web Services

Coming back to the web service design, i am interested in serving my services as RESTful web services. To protect the services, i use a token based authentication (JWT) .

As an example, i have to build 3 independent services, which are :

1. Token Service (which handles the authentication and authorization activities)

2. Location Service (which can perform CRUD operations on my “locations” table)

3. Customer Service (which can perform CRUD operations, search, listing etc on my “customers” table)

To provide the services to consumers, URLs are setup with Laravel routes (route.php) and assigned Controllers inside /Http/Controllers folder. Some of the URLs as follows :


/api/v1/token/create/ (Create token)
/api/v1/token/refresh (Refresh an expired token)
/api/v1/location/create (Create a new location)
/api/v1/location/get/?mode=all (Retrieve all locations)
/api/v1/customer/create (Create a customer record)
/api/v1/customer/get/?byId=1 (Retrieve a specific customer information)


Layered design for my web services.

I have all my services to be designed in such a way that, design should decouple the services and provide an abstraction to hide the implementation. Here i adopted a folder structure to place my web service logic and placed inside the default “app” folder.

 

This is how i designed my web services application structure. All of the web service logic are written and placed inside the “/app/Layers/Services” folder and they used the namespace App/Layers/Services. All these services implements the interfaces defined in “Contracts” folder which are linked to implementation (Concrete classes) through the Service providers placed inside “Providers” folder. All of my 3 services can be used in respective controllers through the contracts only. Since it is registered as service providers, these services can be injected in to the class through constructor (DI). For example, to use the Location Service methods inside my Location controller, i can inject the service as follows.


function __construct(LocationServiceContracts $location){
$this->locationService = $location;


}

Then i am able to invoke the methods from Location Service as follows :

$this->locationService->createLocation($args);

You can see the constructor points to “LocationServiceContracts” instead of the actual implementation of “LocationServices.php” resides in Services/LocationServices folder. This is done through a register() method in my LocationService provider which create a binding to the actual implementation. This approach is helpful when you have to switch the implementation without modifying the application logic.

You might notice that i have a “Response” service provider, and i would say , this service is responsible for sending response back to the service consumer in the form of JSON objects. As stated above, using contracts for this Response service provider, we can switch to another implementation. If you need the service to return a pure text as response, create a Concrete class and change the implementation binding in register method of Response service provider. Easy right ?

Again, very important, see the “Repository” folder which carries out the database related operation. Repositories take care of table to objects mapping . I used Laravel’s Eloquent models and linked with repositories. Each repository has functions to do carry out the database related operation. For example, getCustomerById($id) method, retrieves a specific customer object selected from “customers” table, but executed using an Eloquent model.

Dependency injection is used in my web services to communicate with other services. For example, the Location services and Customer services are protected using a token authentication. Each time the other two services are executed, they ensure the presence of a valid token using the Token service injected in to the respective classes.

To conclude , the above design was experimental and found to be a reliable implementation of service oriented design using Laravel.

 

Replace Laravel’s Default Password Hash (Bcrypt) with Base64 Encode

Laravel is one of the most popular Framework used for developing web applications and console based applications using PHP. Default password hashing used in Laravel is bcrypt. When you think about using another password hash mechanism, you will see, it is very easy to implemen since Laravel provides facility to create service providers easily. This below example gives an insight on how to create a service provider which replace the default password hash with Base64 Encode.

To start with we will create a class and write our password hash logic here. Here i created this class and placed in app/Lib folder . The class uses the App/Lib/CustomHash namespace. You can place the class inside any of the directories inside “app” folder and put an approprite namespace. This is the beauty of this framework which helps to create directory structure as per our choice. Composer will take care of the “autoloading” operation.

I have the following code block placed in my CustomHasher.php file.


namespace App\Libs\CustomHash;
use Illuminate\Contracts\Hashing\Hasher as HasherContract;
class CustomHasher implements HasherContract {
/**
* Hash the given value
* @param string $value
* @return array $options
* @return string
*/
public function make($value, array $options = array()) {
return base64_encode($value);
}
/**
* Check the given plain value against a hash.
*
* @param string $value
* @param string $hashedValue
* @param array $options
* @return bool
*/
public function check($value, $hashedValue, array $options = array()) {
return $this->make($value) === $hashedValue;
}
/**
* Check if the given hash has been hashed using the given options.
*
* @param string $hashedValue
* @param array $options
* @return bool
*/
public function needsRehash($hashedValue, array $options = array()) {
return false;
}
}


In the above code, you can see the class actually implements “HasherContract” which is a contract to the hash service offered by Laravel.
Actual password hash resides in the make() method . I have used the base64_encode() function as the password hash. Now our password hash service is ready. We can offer this feature as a service to other application logic. We can achive this by creating a service provider.

Here i create a filder CustomHashServiceProvider.php inside app/Providers directory. Code inside the CustomHashServiceProvider.php file as follows:


namespace App\Providers;
use Illuminate\Hashing\HashServiceProvider;
use App\Libs\CustomHash\CustomHasher as CustomHasher;
class CustomHashServiceProvider extends HashServiceProvider
{
public function register()
{
$this->app->singleton('hash', function () {
return new CustomHasher;
}
}


From the above code, register() method binds the CustomHasher class with the service container and makes it available to the other part of the application. Next we should add this service in our app config file. Modify the app.php file inside config directory.
In the providers array, remove or comment following line .

Illuminate\Hashing\HashServiceProvider::class,

Add below line of code.

App\Providers\CustomHashServiceProvider::class

Now the default password hash method is replaced by the base64_encode function through our service and we are done !

You can see the implementation in GitHub