# CorpGo
## A flexible service to deal with data providers

---

TL;DR;

> Corp have a large amount of code, to manage similar or even the exact same result for different endpoints. Since most of this management are made to organize data structuring, conversion, etc., *CorpGo* aims to normalize those areas, bringing a flexible solution to fit most use cases using a low level language which performs way better than Python.

# Are you planning on replace Corp entirely?

**No**

*CorpGo* is aimed to fix a deficiency in our past choices. It will be focused on normalize the data flow between Corp and a Data Provider (as BigQuery), by offering highly customizable features, like data management, structuring and exporting.

# Same page

We strongly believe Corp already does the majority of tasks he'll ever do. It brings consolidated data to present our customer with charts and numbers from a business point of view.

Even though this may seem simplistic and that we're underestimating its importance, we're developers and by closing our eyes for a few seconds, we can all agree that this definition fits just fine.

Also as developers, our job is to solve problems focusing on scalability and easily supporting future implementations. Unfortunately we've failed to achieve this goal.

# Resolution

Today, Corp has an enormous amount of code just to organize the data it gathers in order to return it to the front-end. It may seem silly since it's just consolidated data, but we're talking about having multiple services which formats data in the same way, only with different parameters, or even exporters which does not fit for scalability at all.

We have a single data provider, which brings most data in the exact same format. And we can easily point out all use cases for this data inside Corp. So why we have a massive project containing hundreds of files doing almost the exact same thing? Why we're neglecting this for so long?

# Simplicity over complexity

Well, the answer may be simple. Somewhere down the road, one must have overestimated the project. Maybe for preciosity, maybe lack of knowledge, maybe due a not so good management.

Hell! We're not here to judge the ghosts from past, because at that time things may have made sense for those people. As a matter of fact, that's almost always the reason.

The thing is that today we have a better understanding on Corp responsibilites and we believe it could be way more simpler. And that's why we thought: CorpGo.

We need an interface that contact other data providers (as Calc, BigQuery, and future ones...), being flexibile enough to receive a few configuration parameters so it can transform the response
as requested. Nothing else.

You need a line chart for Swine showing deaths per month? Okie dokie, just give me 3 parameters. Every species needs a line chart, so why are we developing a bunch of logic to organize those data every time a new request comes up?

You need to export this data as CSV? Sure! Send me 5 parameters. That's it. No need to add more logic to the project. Just use the good'ol flexible exporter, mate.

# Ok, you sold your idea, but why Go?

Golang is a low-level, pre-compiled language. Meaning it works close to machine language, so it's faster, it takes less memory to execute and it's way more powerful than Corp current language, Python.

I'll not go further on this technical "battle", but let's agree on the following declaration:

*"At the end, every language becomes ones and zeroes, but most of them are made with specific purposes, and it's a job for the technical leader to wisely choose one that fits the project needs."*

Now I'll let you with the following picture, showing how much time each one takes to solve three complex algorithms.

*(Source: https://www.edureka.co/blog/golang-vs-python/)*

Go is more powerful, will bring more performance to Corp and it will decrease the hardware usage on the cloud, meaning its cheaper to maintain. So it's a win-win for everybody.