My ability to remember things can drive my wife crazy. Earlier this week, she asked me two questions after I finished telling her a story that I had recalled from my long-term memory: How do you remember such things? Why do you even remember that memory? Honestly, I have no clue how to answer her questions, only that I recognized this ability earlier in my life. We both agreed that if there was a “useless trivia show,” I would be the world champion … hands down. I feel like some events that I experience for the first time are often indexed in the long-term chambers of my brain, later becoming the source of my stories that I feel compelled to share with her. In terms of career implications, it does not take much effort to recall the first time I worked in a programming language or started using a service or framework. Reading about the service provided by —one that promises “Zero DevOps”—made me want to take it for a test drive. Looking over the list of supported languages, I saw an opportunity to create a service in a programming language that is new to me. Render As a result, I decided to give the programming language a shot, in hopes of adding a new deposit to my long-term memory bank. Go The Magic 8-Ball Service To make things fun, consider an example where asks for the creation of a RESTful API that mimics the toy that was invented in 1946: Mattel Magic 8-Ball For those who are not aware, the Magic 8-Ball is a novelty item that performs basic fortune-telling tasks. With the 8-Ball image facing up, the person holding the ball asks a yes-no question, then turns it over to reveal an answer. The reply magically floats to the top out of the dark black ocean inside the toy. The original design contained 20 unique answers, and the acceptance criteria is that only these responses will be allowed in the RESTful API: Ten positive answers are noted with green bullets, and the remaining ten are an equal combination of non-committal (yellow) and negative (red) answers. Consumers of the API simply need to make a standard GET request, which will return a random answer from the list of possible options. For validation purposes, Mattel would also like a second endpoint to retrieve a list of all available answers from this new service. With my design, we can meet these requirements with the following endpoints: GET - randomly returns one of the twenty available answers /answer GET - returns a list of all twenty available answers /answers Getting Started With Go While visiting the on the Go site, I noticed the installation process was very similar to getting started with the Java programming language. The installer used a wizard-like design where I basically just had to click buttons to navigate through the process. Once finished, I used the following terminal command to verify a successful installation: download page ╭─me@johnjvester ~ 
╰─$ go version
go version go1.17.6 darwin/amd64 Using IntelliJ IDEA, I added the and started a new project using the command: Go plug-in File | New | Project … The project name of just seemed right for this endeavor: magic-eight-ball After some research, I found that the provides the functionality needed for a RESTful API written in Go, so I installed it with the following command: Gin web framework $ go get -u github.com/gin-gonic/gin To reference Gin inside my source code, I simply needed to include the following import: import "github.com/gin-gonic/gin" Now we are ready to start building the Magic 8-Ball API. Creating the Magic 8-Ball API The first thing I want to do is establish the data side of the API. For this example, the following JSON structure will make up the response body when an answer is provided: {
  "id" : number,
  "response" : string
} In Go, this JSON payload is defined (as shown below) and added to the file: main.go type response struct {
	ID       int    `json:"id"`
	Response string `json:"response"`
} Since all of the data is static, I added the standard answers to the file: main.go var responses = []response{
	{ID: 1, Response: "It is certain."},
	{ID: 2, Response: "It is decidedly so."},
	{ID: 3, Response: "Without a doubt."},
	{ID: 4, Response: "Yes definitely."},
	{ID: 5, Response: "You may rely on it."},
	{ID: 6, Response: "As I see it, yes."},
	{ID: 7, Response: "Most likely."},
	{ID: 8, Response: "Outlook good."},
	{ID: 9, Response: "Yes."},
	{ID: 10, Response: "Signs point to yes."},
	{ID: 11, Response: "Reply hazy, try again."},
	{ID: 12, Response: "Ask again later."},
	{ID: 13, Response: "Better not tell you now."},
	{ID: 14, Response: "Cannot predict now."},
	{ID: 15, Response: "Concentrate and ask again."},
	{ID: 16, Response: "Don't count on it."},
	{ID: 17, Response: "My reply is no."},
	{ID: 18, Response: "My sources say no."},
	{ID: 19, Response: "Outlook not so good."},
	{ID: 20, Response: "Very doubtful."},
} In order to leverage the responses variable, I added two functions to the file: main.go func getAllAnswers(c *gin.Context) {
	c.IndentedJSON(http.StatusOK, responses)
}

func getRandomAnswer(c *gin.Context) {
	rand.Seed(time.Now().Unix())
	c.IndentedJSON(http.StatusOK, responses[rand.Intn(len(responses))])
} The function simply returns the responses list in JSON format, and the function randomly picks one of the twenty options and returns the value in JSON format. getAllAnswers() getRandomAnswer() Finally, the function sets up the endpoints and the port used by the service: main() func main() {
	router := gin.Default()
	router.GET("/answers", getAllAnswers)
	router.GET("/answer", getRandomAnswer)

	port := os.Getenv("PORT")
	if port == "" {
		port = "8080"
	}
	if err := router.Run(":" + port); err != nil {
		log.Panicf("error: %s", err)
	}
} That’s all that is required to meet the acceptance criteria established by Mattel. To start the application, we run the following command from the terminal: ╭─me@johnjvester ~/projects/jvc/go/magic-eight-ball 
╰─$ go run . The logs that displayed included those noted below: [GIN-debug] GET    /answers        --> main.getAllAnswers (3 handlers)
[GIN-debug] GET    /answer         --> main.getRandomAnswer (3 handlers)
[GIN-debug] Listening and serving HTTP on :8080 I can test the API by sending curl requests with the following command: ╭─me@johnjvester ~ 
╰─$ curl http://localhost:8080/answer This is the response I received: {
    "id": 6,
    "response": "As I see it, yes."
}% With the Go service running without any issues, I uploaded the code as a new project on GitLab: https://gitlab.com/johnjvester/magic-eight-ball Now I’m ready to see how Render works. Deploying to Render Via GitLab Getting started with Render was quick, easy, and free. I simply opted to use my GitLab credentials, which made things easy when selecting projects to deploy. To get started, I selected the New button on the Render dashboard and chose the Web Service option: I selected my project on GitLab: magic-eight-ball Within the Render platform, I decided to call my service and kept the defaults for all of the other options: jvc-magic-eight-ball Scrolling down, I opted to keep this service running on the free plan: Then, I clicked the Create Web Service button. Within a few minutes, the showed me that my service was up and running: Render dashboard I sent a request to the URL for my service on Render ( ), and I received the following response: https://jvc-magic-eight-ball.onrender.com/answer {
    "id": 5,
    "response": "You may rely on it."
} Within just a few clicks, I deployed my first RESTful API written in Go to the Render platform—and this didn’t incur any costs. More importantly, the Render approach did not require any DevOps skills or knowledge for me to complete my task. Conclusion The introduction of this article talked about my ability to retain and recall historical events several years (if not decades) later. The fact that this entire experiment took less than an hour of my time—from start to finish—is certainly worthy of becoming another one of those events. Starting in 2021, I have been trying to live by the following mission statement, which I feel can apply to any IT professional: “Focus your time on delivering features/functionality which extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” - J. Vester In this article, not only was I able to produce a functional API quickly with very little source code, but I was also able to deploy the project to a cloud provider simply by performing a series of small steps. Zero DevOps was promised, and Zero DevOps was delivered. This allowed me to focus my time on providing features to my customers. If you are interested in the full source code, just navigate over to GitLab: https://gitlab.com/johnjvester/magic-eight-ball Knowing that I currently have APIs and applications running in the Heroku ecosystem, I plan to start looking into what a conversion from Heroku to Render looks like in the next few weeks. So far, I am quite impressed with what Render has to offer. Have a really great day! First published here

Ball

Heroku

Yellow

How to Transition from Full-Stack Developer to Web3 Pioneer in 2022

The Rewards Card System is Broken and Here is How I Tried to Fix It

I ♥ writing code. Find me on GitLab.

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - Hackernoons Tech Storyteller of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Salesforce

Too Long; Didn't Read

Spend Zero Time on DevOps with Render PaaS

Spend Zero Time on DevOps with Render PaaS

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

5 Signs You’ve Built a Secretly Bad Architecture (And How to Fix It)

The Noonification: How to Deal With Flapping or Broken Tests (11/29/2023)

The Noonification: Delving Into OpenTelemetry Collector (11/18/2023)

The Noonification: How to Implement a Merkle Tree in Solidity (11/12/2023)

105 Stories To Learn About K8s

104 Stories To Learn About Continuous Integration

5 Signs You’ve Built a Secretly Bad Architecture (And How to Fix It)

The Noonification: How to Deal With Flapping or Broken Tests (11/29/2023)

The Noonification: Delving Into OpenTelemetry Collector (11/18/2023)

The Noonification: How to Implement a Merkle Tree in Solidity (11/12/2023)

105 Stories To Learn About K8s

104 Stories To Learn About Continuous Integration

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps