How Hippokampe was designed?
Hippokampe it’s an unofficial environment based on the Holberton Intranet. The main goal of this project it’s to extends the functionalities and the places where the Intranet can go. One of these places is the console.
The console’s a place where a Software Engineer usually is. So why not that turn that chance into an app? Or also, why not let the community develop features based on its needs?.
Design
Hippokampe it’s an environment so that means it’s composed of different modules developed in different languages but go as the main programming language. This design’s because the scalability and extensions to other platforms was a thing to keep in mind. The principles of Hippokampe are Reuse, Simple, and Easy to Use. Let’s go with the first.
Daemon — Bottom
Thanks to this module all the environment it’s usable. This part doesn’t have the logic but it will have the control of Hippokampe, which means without this, we are not able to run or use any kind of service provides by Hippokampe. That said, we can resume the main function is a service that will be always serving all the features the community may require.
We can say “the daemon to Hippokampe is what a support it’s to a building”, without these two things, none of them are possible. It will also mean the responsibility of this is high and without the proper behavior, it could damage the entire system 😆 😆.
In the end the daemon it’s just a frontend because it will use as a backend the central management tool used in the operating system of the host, to delegate the responsibility to a service that it’s already tested and used by millions and several times.
API — Bridge
The best way to describe it is by naming as “Bridge”. And that is because it will do two basic things, get and export the information but with the parameters of the user. In other words, depending on what the user wants, the information process will get some information and then return it.
a. Get
In the flow exists “get information”, but what it means? how it works?. It means that one needs to get the information from somewhere, and this somewhere on the intranet. It will do that by creating a system that is going to emulate a user interaction to the web page. In technical words, this is called “scrapping and headless browsing”.
The scraping will receive the query from the user and then it will try to resolve the action by acceding to what the user normally will do in the normal case with clicks in the browser. This is not a definition, it’s an example out of “under the hood”.
We need to do this way because the API offered by Holberton it’s limited by features and also because of the necessity to use a Key, which automatically will restrict the range of the users to those who are in the last trimester of the program.
b. Export or expose
After the getting process, we can now serve that information via an API REST. So in the end, once we got the information, Hippokampe creates a bridge to get the information, but this will also depend on the input that it will receive and triggered by the API REST
In other words, the api REST is the mechanism to receive and retrieve the data from the environment. And for that reason, it’s called the bridge.
Applications
This is the best thing because this is when freedom comes from. This will nothing without the API or even the daemon. The existence of both is relevant to the proper work of any application based on this design or with a purpose to extend.
At this moment the only app that it’s using this service is the CLI, which it will allow to use of the API and all the stuff related to Holberton from the terminal.
The idea’s to develop apps such as extensions for editors, phone apps, or even plugins to apps that we normally use.
Conclusion
As we can see in the image, the project is based on Docker. Also, this is how the layout explained looks like. It’s really simple and also, it’s easy to extend or maintain thanks to the composition of different modules.
More information about the project at hippokampe.
