Cross-Domain API Error!!!!

Cross Domain being a pain??

I have been playing around running my own application infrastructure. I have API's and web clients to maintain.

I have looked and used many different scenario of hosting. The one I have finalised on is Heroku. I'll explain later why i find this a fitting solution for my team. Anyway the way I am running Heroku is having the API hosted by a dyno, and the web client hosted on a separate dyno. This is fine from a deployment point of view, however you may quickly find yourself in the horrible world of cross-domian hell when calling your API from a javascript browser hosted behind a different domain.

Firstly I'll explain a little as to why you get this problem. If you are passing a custom header in your request the browser will check with the API if its all good to send this information. On calls made from your browser code to API's it needs o ensure they are allowed to make these requests on this domain. This is done via a OPTIONS request firing before every API request you make from your browser. This will hit your API. The fun now begins, you as owner of the API can allow access to different domains (or all domains if it is felt necessary)

I am running Go as my back end API layer if you have not guessed from my other blogs. To handle my routing I use Gorilla's pat package
{go get gorilla/pat}
Their documentation shows you can route requests for Get, Put, Post and Delete. As you can see there is no request router for OPTIONS. This you may think is a problem. Do not 'panic' yet. The Pat package also has an Add function. Looking into the implementation of there code you can see that the Get, Post and the others all use proxy the Add function. This means we can add our own REST verb to the router. The syntax for the Add function is

func (r *Router) Add(meth, pat string, h http.Handler) *mux.Route

This is slightly different to the Get request

func (r *Router) Get(pat string, h http.HandlerFunc) *mux.Route

Instead of taking the http.HandlerFunc, Add takes just a http.Handler
If like me you have created a HomeHandler to return status.ok on your API route request you can simply cast the same func as so:

r.Add("OPTIONS", "/", http.HandlerFunc(handlers.HomeHandler))

Your home handler now needs to send its access control

func HomeHandler(rw http.ResponseWriter, r *http.Request) {

log.Println("Home Handler Called")

rw.Header().Set("Access-Control-Allow-Origin", "*")
rw.Header().Set("Access-Control-Allow-Methods", "POST, GET, OPTIONS, PUT")
rw.Header().Set("Access-Control-Allow-Headers", "Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token, ApiKey")
rw.WriteHeader(http.StatusOK)
}

As you can see I have ApiKey as an allowed header. This is all why I'm having to handle the OPTIONS call.

You will need to set up an OPTIONS handler for each path you are using custom headers.

Hope this as wells helps save someones development time in the feature.

Go Web Scaffolding

So this is something I have been getting around to doing for ages now. Today I was forced to do it, and Im glad.

Little back ground into the day:
A mate at work told me he was starting writing a go web service and wanted to ask a quick couple of questions on how to set up the scaffolding. I though

YES, at last, after all this time of me telling him to use go here we are

 So I start to explain what he needs to do to turn his functions into a web service. This all started to go horribly wrong when I noticed the structure of his code would never work. Not giving up I had 30 mins to try and restructure and explain what I was doing. This did not go well and I ended up breaking his project before having to leave. Now I didn't want to leave this as his lasting thought of go so....... I have created a quick Go Web Scaffolding repo. An hour later I went back to him, pleading I do know how to programme and have created a help guide for all his needs. Big success, I feel we have managed to turn things round and recruited another gopher today!

The repo is https://github.com/DigitalInnovation/goscaffolding

Please feel free to clone and comment on any set up structure you feel is required for a set up web service.

My end game is to run a generator that can create scaffolding projects for go.

Simple and Quick way to stub a method

Simple and Quick way to stub a method

Go having functions as first class citizens enables you to override the implementation of a function.  I have just used it to enable me to test a method quickly. (I know I could have abstracted the code out and tested the separate function, but really wanted to give this a go)

So creating a new variable and setting it to be a function is really easy.

var calculate = func (a, b int) int {

     return a + b

}

You can use this variable just like you are calling a function

c := calculate(1 + 2)

Now lets say you want to get a different result in a test. Well you can override the functional implementation.

calculate = func(a, b int) int {

    return 20
}

This now means when this function is called in your code it will return 20 every time, no matter what you pass in. However in your real code, it will run your function you declared in the real code.

This is a simple example. However it could be a quick and easy way of mocking data access layer requests for tests without setting up a mocking framework.

How it helps

Ray Gun Post Panic Recover

Ok so I have created my first Go open source package I can add back to the community.

go_raygun
Usage guide can be found at the bottom of this post.

That being said, it is a working progress and any improvement suggestions are welcome, I will be expanding it to cover more areas.

In this blog I will be explaining what I have learnt from the Go 'defer, panic and recover', Go's runtime package, and Ray Gun.

First RayGun is a real time error reporting cloud service that can be set up in under 5 minutes, as they say anyway. The benefits of this application are greater than what I am using it for.

There are the many supported languages '.Net, Java, Python....' but they also provide a REST JSON endpoint here. This is what I use to post the messages to RayGun.

Secondly defer, panic and recover. There is a good blog on how it works here. I will explain more later in the blog on how I am using it.

Third and final the runtime package in Go. The two functions I use are runtime.Caller and runtime.Stack.  The Stack does what it says, it returns a byte array stack for what ever byte length you set.

stack := make([]byte, 1<<16)
stack = stack[:runtime.Stack(stack, false)]

Deconstructing this it does a couple of things. first it makes an object called stack of a byte array with length 1<<16, the 1<<16 syntax is short hand for binary integer to the power 16. I am using the runtime.Stack function. This populates the stack object created with current stack tract.

note: There is also the ability to run a stack tract from debug.Stack. The way I have explained above is the preferred Go way.

The Caller function allows you to get the line and filePath from the stack. You also have the ability to skip a set amount of callers from top of the stack. I am setting the caller to skip 4 levels.

_, filePath, line, _ := runtime.Caller(4)

 The reason I am skipping 4 is so that I return the Caller from where the panic happened. The comes back to explaining how I am using defer, panic and recover.

defer: If you are from a c# background like me it is similar to a finally block. defer will always happen at the end of the function no matter what happens in child functions. The most common use of this is opening connections. As soon as you open a connection you create a defer that closes the connections.

panic: A panic is raised when a runtime exception happens. When a panic happens it stop on that line of code and ends the function. (any defer's that are on that method will still be called, it is important to not set any defer's in this method if you are using this goRayGun package as it will return an incorrect value from runtime.Caller)

recover: The recover function can be called in defer via a inline if statement.

if r := recover(); r != nil { }

Recover will check to see if a panic has been raised. r is of type interface and needs to be type cast to be used. In Go you can call a panic passing in an object. However if you get a runtime panic it will always return an error object with the error message.

errorMsg := r.(error).Error() 

go_raygun set up

As you will be able to see in the from the github link at the top there is an example of how to use the package. In short though, you need to set up the RayGunConfig.json with your application and RayGun settings and save this into the same directory as code you are using it for. The first thing you have to do is create an instance of the package. I have added an interface for the package if people want to use it, (this will enable mocking as explain in my last blog and will be helpful when testing your application). I have not used the interface in my example as wanted to keep it as simple and small as I could.

Before you can use the RaygunRecovery function you must first call LoadRaygunSettings. This only has to be done once from your main function as long as you declare a package global instance of the goraygun package.

Once it is set up you can use the RaygunRecovery in a defer before you call any function that could panic.

An extension I am looking to do is pass back an error object from the defer. This could be done by passing an error pointer object to the defer. I will keep you updated, but if anyone would like to create a fork of the repo could work paired on it.

Note: I have made some amendments.

1) It is now possible to have one defer in your code and any functions below will be caught by the RaygunRecovery.

2) I am now parsing the stack trace into an array of stack events, passing them to Raygun. This helps in determining where the panic came from and the root it had taken. 

Go Package set up with testing in mind

Hi all,

I am going to attempt to explain how to set up a package in Go with the option to Mock the methods in the package for testing. I say attempt because I am still learning Go and the best practice way of doing things, so apologies in advance.

This link to stretchr/testify is required for the following examples. A massive thanks to these guys for making my life a lot easier.

I am going to use very simple examples and more comment the structure than anything, will post an update of code once completed.

So first thing, want to create a package that I am for simplistic reasons going to call 'mypackage.go'.

In this file we are going to create an interface that will expose our public methods outside of this package.

type IPackage interface{
     Method1(string obj) error
     Method2(string obj) string
}

Now we need to create a struct to implement this interface

type Package struct {
}

Next we create the functions we are going to use, and make sure you use a pointer to the struct you have just crated.

func(p *Package)Method1(string obj) error {
        //add all the code needed here
}

func(p *Package)Method2(string obj) string {
        //add all the code needed here
}

Ok we have now created all we need to on our package, we can move onto implementing this in our code that is going to need testing, by mocking of this package.

In a new go file first thing we need to do is create a reference to the package. Create a var to the interface package

var package IPackage

Now instantiate the interface with the concrete struct.

package = new(Package)

Using this object you can access the functions we created.

err := package.Method1("hello")
string := package.Method2("world")

So far we have created a package with an interface for public methods, then used this package and the exposed methods in our code.

The next thing we require to do is test our code in our app, not in the package. To do this we require the ability to Mock the Methods in our package, giving set responses.

In the standard Go testing file import the stretchr/testify API.

Now we need to set up our mocking on the package and methods so when they are called in our app code we can control the response.

So lets create a mock object struct.

type MockPackage struct {
       mock.Mock
}

Next create a local var of our struct

var mockPackage *MockPackage

Next we set up the methods we want to mock. This only need to be done once for each method and just sets how it takes the arguments in and what it is set to return.

func(p *MockPackage)Method1(string obj) error {
       args := p.Mock.Called(obj)
       return args.Error(0)
}

func(p *MockPackage)Method2(string obj) string {
       args := p.Mock.Called(obj)
       return args.Get(0).(string)

Finally we get onto the fun bit. Using these mocked methods in our tests, setting the expected results, enabling us to test the areas that we really want to test in our code and not the package code.

lets create a test

func TestMethod(t *testing.T){

       mockPackage := new(MockPackage)
       package = mockPackage

       mockPackage.Mock.On("Method1", mock.Anything).Return(fmt.Errorf("mock error"))

       //now do your code here, if's, loops.....logic that need testing in your app.
       err := someMethodtoTest()

      //can use testify to assert variables.
      assert.NotNil(t, err, "should have found error")

       assert.Equal(t, true, mockPackage.Mock.AssertNumberofCalls(t, "Method1", 1), "Method1 not called the correct amount")

}

The first thing you need to do is 'override' the real object calls with the new Mock object. This is done by creating an instance of the Mock object and then setting the real object to it. This will make it so that every time the real object is called it will use your Mock methods instead.
The Mock methods are then each set up meaning that when in the code "Method1" is called and containing anything as its variable it will return an error. Then we call the code in our app that we want to test. Lets say our code we want to test is that when our Package Mehtod1 is called and returns an error, we want to bubble that error up to this method. Using the assert.NotNil method checks the error returned.

The second assert is very useful so I have given an example. It uses two asserts in one. First it does an Equals assert, then it uses a second assert to gain the count of the method called.

There are many more examples on their Git hub site and API documentation, this as explained more of a simple set up of your package and how to use in code and tests.

Hope this has helped. comments are always welcome. I will be uploading code snipping as soon as I can.