Foreword

This post will be a rather short one. Though I will be releasing two other posts about how to build a front-end using two different approaches. One will be dynamically rendered upon hitting the endpoint of the site. The second, however, will be static generated.

Either version has its benefits, we will be discussing these in the two posts.

HTTP

Throughout this post, we will be learning to setup our HTTP front of the Trello API. This way we can use our own server as a proxy to manage Trello cards and lists.

You might be wondering: "Why go through the trouble of making an API to proxy Trello?". I do see where you come from, though, we do not want to expose our private key and token for others to (ab)use. This way we will also have more control over caching and what to display the user. As you saw, if you have read the previous post, we convert Markdown to HTML, so that we can display the data.

Jamstack

What we are doing, exactly, is living by the rules of the JAM-stack, or rather, use some of the rules.

The JAM-stack is an acronym meaning "Javascript, APIs and Markup". This is all good, but why should I not simply write a static HTML page with the HTML already formatted, so that we won't need to use Trello? Remember, we are doing this as a Proof of Concept, which is why I have chosen to use a project management tool, like Trello as it supports Markdown. A lot of other tools do provide Markdown too, but in my understanding, Trello is the most popular one with more than 50 million users!

Back on the JAM-track. We use the JAMstack as quite a few frameworks out there, in the real world, are using this approach, such as Sapper which is built upon Svelte. A framework I very much enjoy using. It can be used to generate static sites, or even dynamic ones! This is of course, what I have chosen as the Framework.

The API

Let us get into the code. We should, like always, start with the package declaration and imports of packages.

As you see, on line eight (8), we are using a new package called Fiber, this is a fast and fun-to-use framework for easy setup of a HTTP-API or complete website in Go.

Fiber has been inspired by Express; the node package written in Javascript. It is based on fasthttp, which is the fastest HTTP-package for golang.

Next, we will initialize the main function, along with a new fiber-app.

Quite simple, alas you cannot get permission to run the app, as we have a declared - but unused - variable called "app". So let us use that app-variable, and setup a HTTP-listener on a port.

Now, we can run it, as easy as typing the standard go run command. Sadly, this will not work either. We forgot a pretty important argument to our command, namely the PORT environment-variable. Let us add it, and see what will happen.

Yes! That is it!

Now setup the missing routes, so we can make requests towards our newly created proxy-API for Trello.

That was fun, right? Eh, not really. It still does nothing, we should add some logic to our "/pages"-route, so that we can fetch some data.

It is quite simple, however, we still won't be getting any data, if we call it. Even though it is supposed to fetch all cards, and return the HTML.

Why? Because we have not added any data to Trello. Though, before we get to that, we should at least implement the second route, for a single page. As you see, it is mostly the same code, we are just adding and modifying it a bit. First of all, you see a new variable introduced at line 31 which is what page we are requesting. You might have noticed that the s is missing of GetPages, we also provide the new variable as an argument for GetPage.

Trello

To get data of Trello, we need to have some, so let us add a new list onto the Board with the Identifier we found in the first post.

I have put in some sample text, modified it to fit our markdown needs, and it is done.

If we have this figured out properly, this will render as.

Let us try requesting our API. First, give http://localhost:3000/madco/pages a try. It should return all the cards.

As you see, the HTML is written out as we imagined! It is great! But, I found a bug in our code from the previous post. Instead of having the parser out of the loop, I have moved it into the loop. Like so.

I moved line 47 to 49. This will make it work. Sorry for the mistake!

Now, why not making a second request for a single page?

As you see, it works as smooth as a smoothie! Though, the loading times are not the best. Which is why I keep talking about caching. The ~600ms it takes to get the data back from the request is simply how long a website should take to load. As for UX.

We will be connecting this API to a front-end in the next couple of posts, also, as I said in the beginning, I will be doing it in two different ways.

End

Thanks for reaching the bottom, it means a lot to me, that you take the time. Here is a few links the the previous posts.