By Cheng Junior

In the beginning of my career as a software engineer, I used some of the best well-known frameworks of the time to develop in Java for WEB, such as: Struts, Hibernate, JSF, Spring… Even without having any notion of how a WEB application worked, these solutions helped me a lot, because they made the coding process much easier and established an abstraction layer in which I didn’t have to worry. This made me able to deliver in a very productive way, even with little experience.

After that, I changed companies and started working with Rails. That, so far (December 2019), is the most magical framework I’ve ever known. With almost no code written, I could build a system almost entirely. With one command, it was possible to create an entire CRUD with SQL tables and HTML-based interface.

After a few years using Rails, it was time to leave it behind and start using the Golang language. Go is a relatively new language, similar to C but with memory safe, garbage collection, structural typing…

At that point, of course, I invited the team to look for Go’s version of“Rails”. There were few available. Some were only simulating Rails. However, none was good enough for us to adopt. And then I came across a situation so far new to me: developing systems using a language that doesn’t have a well-established framework. How will it be now without Gandalfs and Dumbledores conjuring up the magic for me? The magic is over!

That’s when we decided to become the wizards. We created a complete Golang framework: dependency injection, HTTP(S) server, cache, route management… After the first version, we applied it in the first project and sent it for production. From then on, we had to maintain the project and the framework. In the course of time, other needs appeared and the effort to develop was huge, because we had to code in the project and the framework. We realized then that we had created a monster… difficult to maintain, with high coupling, not very flexible and with many unnecessary features!

So we decided to take a few steps back, and start from basics. What do we need to do to build my own system? A web application needs an HTTP service and a set of HTMLs. Simple, huh? So we created a project with nothing, no magic. Just using Go’s native API. Then we started to gain flexibility and the power of customization.

Can opening the code so much to the developer increase the risk of him inserting bugs in the architecture? Yes, it can. But we need to call the shots for us developers. Possessing the knowledge and mastery of what’s going on there is our obligation. It makes us understand and gives us the possibility to make decisions that are not always the usual ones. We developers have to be John Wick, we have to take the responsibility for ourselves and not leave it in the hands of other people.

But what about security, where does it come? One way to protect yourself is by reducing the attack surface. In this case, the less code your system has, the lower the chances of functional bugs, as well as security bugs (vulnerabilities). In other words, the leaner your code is and the less libs it uses, it is less likely to have vulnerabilities. In addition, when you have full knowledge and command of the code, in case any security bug arises, you will be in full condition to fix it. Now, if you are using some heavy witchcraft, only the wizards will fix it. From now on it’s 0-day. If the wizard is of the Dungeon Master type, or if it is some kind of magic that few wizards are keeping, the problem is even bigger.

Nobody wants to reinvent the wheel. Not every project has the possibility of not using some framework. But if you need to use a magic for whatever reason, here comes what is necessary to do:

  • See if there is a reasonable amount of people using it;
  • Have a good understanding of how it works;
  • Keep an eye on updates;
  • Try to keep it up to date;
  • See if it is still being kept and with a good update frequency;
  • Sign safety lists that address this framework.

As Golang has a very rich native API, we were able to develop much of what we needed. But we still use a few low-coupling libs on time. Besides that, we try to make everyone on the team understand what the full system execution flow is like, giving everyone the power and responsibility of developers.