WEEK 5: ENTRY 2

 Having successfully deployed my Kurbenetes yesterday, today I started implementing the HTTPS GO Request Post. As my project will be using the Big Query API to query the data and post the result to my server, I was needed to make that client-server post request. Unlike the GET HTTPS Request, the POST request function accepts three parameters. The Go inbuilt Post function accepts these three parameters:  The URL address of the server, the content type of the body as a string, and the request body that is to be sent using the POST method of type. The documentation was pretty easy and simple to comprehend, so I had less problems implementing the POST functions. However, I had to restructure my code to meet my project goals. Unlike the documentation, I was not hard coding the data I needed to post to my server. Mine was a two-way procedure: I had to first write a query in the Swagger API, then pass that query as the request body in the Post Function. Then, that query will be posted to my server.


Even Though I had all the  functions I needed, my coding was failing. And again, it was the same mistake I made with the GET Request Function: I failed to log the error so that the logs will identify what part of my codebase the error is coming from. I must mention that Go has a very powerful Error Package called Logrus, which does a great job in logging errors. The syntax is very simple, since the post function body requires two variable declarations: response body and error, I just had to make an if conditional saying if the error is not nil, then log the error. By the way, the response body is what is posted to my server. This way, I was able to see the error that was making the code fail. It was a 403 error, which is an authorization failure. It turns out that not every employee has permission to query to have access to the firm’s Cloud Database like the Big Query. Therefore, I had to wait to be granted permission from the manager's manager because he is the project owner.


Overall, today was a combination of realizing how important it is to learn from previous mistakes and the appreciation of where I am now on my project. I felt bad when I fail to log the error, so I intend to reduce this type of hindrance because they shouldn’t be recurring. So too, I am more confident to say what i am doing unlike the previous weeks’ sessions. This could be because I am now understanding my project and developing a relentless attitude.

Comments

Post a Comment

Popular posts from this blog

WEEK 4: ENTRY 3

  Today at my internship, I was assigned the issue of troubleshooting why my GET request Golang code is unable to generate the data from my http server. Since it was a combination of k8s deployment and Golang go, it was trickier and harder than I envisioned. The k8s was mainly used to orchestrate the objects that are needed to generate keytab from my pods. After several debugging: comparing and contrast the referred file I used as a source code coupled with looking up the errors on Stack flow (suggested me to delete my deployment and redeployed), I was still unable to fix the issue. Partly was because I did not understand what the error message was pointing at. Thus, I had to consult a member of the k8s team, who figured out that my deployment.yaml file was missing some configurations that needed to generate my key-tab. Simply, I needed the key-tab in order to be able to make the HTTP Get Request get my desired data.   Although the recommended solution from my consultation wor...
Read more

WEEK 6: ENTRY 3

  At my internship today, I continued unmarshalling the Json data I got back from Big Query API. Having tried replicating the data on the Go playground and using the Go unmarshall function yesterday, I did develop a better understanding of the json structure. I used Go’s struct to do the unmarshalling. Unlike the json data I got from my query, the documentation’s json data does not have any schema metadata and so I thought the same approach would not work. Little did I know that the schema data can be ignored when unmarshalling json data and that you can only concentrate on the part of the Json you want to unmarshall. When I consulted my buddy, he hopped on a zoom call with me and we did pair programming. I was the driver while he was the navigator, basically explaining what we were doing because he has more knowledge on Go and Json data manipulation. Working with him gave me more skills and confidence in what I was doing. He helped in not just using the Go struct, but also in tryi...
Read more

WEEK 7: ENTRY 1

  It sometimes feels like we are not good enough when our tries don’t work. Well at my internship today, I worked on resolving the json unmarshalling issue I was stuck with last Friday. After several back-and-forth consultations with my buddy and manager, I finally got a better understanding of how they wanted me to present the data. Basically, the data should be in a simple json array that could be manipulated easier. This is because as the json comes in key:pair format, I would need to extract all the keys and use those keys to send an HTTPS request to Elasticsearch Rest API.  Even though the approach was well defined and clear to me, I still struggled to implement it using the Golang Struct and Maps. One of the obstacles I had was because after unmarshalling the json data, the output was in a Golang interface type, which was not iterable like say a slice. A Golang slice is the equivalent  of a python array. Therefore, to overcome that barrier, I created an empty slice ...
Read more