My Handler

Let me begin by saying that "Promise Collection Methods" is not something I've seen mentioned elsewhere but is my own way of referring to the various methods of the that work with multiple promises. They are: Promise API Promise.all Promise.allSettled Promise.any Promise.race I've used many times in the past, and I was of the other methods but had not taken the time to actually build a demo of them. This weekend, I changed that. After spending a few hours in Sanctuary grinding my Necro character, I put down the controller and picked up the laptop. Here's what I built. As a note, everything shown here works in modern browsers, but you can check MDN for more information on compatibility if you need it. Promise.all aware The Helper Functions Before getting into the important code, I built some methods to help me test things out, help me display stuff, and so forth. First, I knew I was going to build this on CodePen (I'll be embedding it below), and I wanted something would visually display in the browser, so I added this HTML: <div id="log"><pre></pre></div> And wrote this little utility: const log = s => { document.querySelector('#log pre').innerHTML += s + '\n'  }; This lets me then use in my code and have it rendered out to the browser instead of the developer console. log("like, whatever") Next, a function to handle returning promises with different times and optionally in an error state: const makePromise = (name, secs, fail=false) => {
	return new Promise((resolve, reject) => {
		setTimeout(() => {
			if(!fail) { log(`Good result for ${name}`); resolve(`Resolve from ${name}`); }
			else { log(`Bad result for ${name}`); reject(`Fail from ${name}`); }
		}, secs * 100);
	});
} Here are a few examples of it in use: makePromise('Todd', 3);
makePromise('Scott', 1); This will create two promises. One resolves in three seconds, the other in 1. Next: makePromise('Ray', 2, true); This will be rejected as an error in two seconds. Also, note that I use the method here so I can see stuff resolving in real time. This will become important later. log Finally, I wrote a simple delay function: const delay = x => { 
	return new Promise(resolve => setTimeout(resolve, x*1000));
} This will let me stuff like: delay(4); As a quick and hacky way to delay a few seconds. In theory, I could have made make use of it, but I didn't bother updating it. Alright, let's get started. makePromise Promise.all The method has the following behavior: all Given an array of Promises, resolve when all are done, or immediately when any throw an error. It resolves with an array of results that match the results of inputs. Here's my first test: log('TEST ONE - Promise.all(all good)');
let test = [
	makePromise('alpha', 3),
	makePromise('bob', 1),
	makePromise('charly', 3)
];

results = await Promise.all(test);	
log('Results from test with Promise.all');
log(JSON.stringify(results)); Looking at the code, you can see that will return before and . Here's the output: bob alpha charly Good result for bob
Good result for alpha
Good result for charly
Results from test with Promise.all
["Resolve from alpha","Resolve from bob","Resolve from charly"] Notice that even though the order was different than the input, the results match the input, which is great. Now, let's throw an error into the mix: log('\n\nTEST TWO  - Promise.all (one bad)');	
test = [
	makePromise('alpha', 3),
	makePromise('failwhale', 1, true),
	makePromise('charly', 3)
];

try {
	let results = await Promise.all(test);
} catch(e) {
	log(`Expected failure in test: ${e}`);
} I wrapped the call in a to handle the rejection. Here's the output: try/catch TEST TWO  - Promise.all (one bad)
Bad result for failwhale
Expected failure in test: Fail from failwhale
Good result for alpha
Good result for charly Notice that my handler fires as soon as the error occurs, but the other promises are still running. You don't have to use . Since the result of is itself a promise, you can use the method of Promise instead: try/catch Promise.all catch log('\n\nTEST TWO A - Promise.all (one bad), modified handler.');	
Promise.all(test).then(results => log('all good')).catch(e => log('one bad')); This returns, as you would expect, just . one bad Promise.allSettled While is good for when you're pretty sure everything is going to work out ok (and remember, a Fetch call to an API may run just fine, but the API itself may return with an error), you may find [ ] method a bit more flexible. It's behavior is: Promise.all allSettled Given an array of Promises, resolve when all are done and report on the success or failure of each Promise. This means you can now rely on knowing when everything is done and handle the success or failure of each one by one. Here's an example: log('\n\nTEST THREE - Promise.allSettled (all good)');
test = [
	makePromise('alpha', 3),
	makePromise('bob', 1),
	makePromise('charly', 3)
];

results = await Promise.allSettled(test);	
log('Results from test with Promise.allSettled');
log(JSON.stringify(results,null,'\t')); The result now is a bit different: [
	{
		"status": "fulfilled",
		"value": "Resolve from alpha"
	},
	{
		"status": "fulfilled",
		"value": "Resolve from bob"
	},
	{
		"status": "fulfilled",
		"value": "Resolve from charly"
	}
] Now we get both the value from the as well as a flag. Here's an example of a failure. First, the calls: resolve status log('\n\nTEST FOUR - Promise.allSettled (one bad)');
test = [
	makePromise('alpha', 3),
	makePromise('failwhale', 1, true),
	makePromise('charly', 3)
];

results = await Promise.allSettled(test);	
log('Results from test with Promise.allSettled');
log(JSON.stringify(results,null,'\t')); And then the result: [
	{
		"status": "fulfilled",
		"value": "Resolve from alpha"
	},
	{
		"status": "rejected",
		"reason": "Fail from failwhale"
	},
	{
		"status": "fulfilled",
		"value": "Resolve from charly"
	}
] You can see the failure in the second result. Woot. I think this is my favorite so far. Going on... Promise.any The method works like so: any Given an array of Promises, resolve when any of the Promises resolves, or reject if all of them fail. This one's kind of interesting. It's basically the "try really hard for something to work" collection method. Here's a first example: log('\n\nTEST FIVE - Promise.any(all good)');
test = [
	makePromise('alpha', 3),
	makePromise('bob', 1),
	makePromise('charly', 3)
];

results = await Promise.any(test);	
log('Results from test with Promise.any');
log(results); In this one, is the winner: bob TEST FIVE - Promise.any(all good)
Good result for bob
Results from test with Promise.any
Resolve from bob
Good result for alpha
Good result for charly Next, here's one with an error. It's the quickest, but keeps trying: any log('\n\nTEST SIX - Promise.any(one bad)');
test = [
	makePromise('alpha', 3),
	makePromise('bad bob', 1, true),
	makePromise('charly', 3)
];

results = await Promise.any(test);	
log('Results from test with Promise.any');
log(results); And the output: TEST SIX - Promise.any(one bad)
Bad result for bad bob
Good result for alpha
Results from test with Promise.any
Resolve from alpha
Good result for charly Finally, here's one where they all fail. log('\n\nTEST SEVEN - Promise.any(all bad)');
test = [
	makePromise('alpha', 3, true),
	makePromise('bad bob', 1, true),
	makePromise('charly', 3, true)
];

try {
	let results = await Promise.any(test);
	log(results);
} catch(e) {
	log(`Expected failure in test: ${e}`);
	log(e.errors);
} Notice I log - this is an additional value thrown by the method that contains an array of all the messages from the failed promises. (It's an ). e.errors AggregateError Here's the output: TEST SEVEN - Promise.any(all bad)
Bad result for bad bob
Bad result for alpha
Bad result for charly
Expected failure in test: AggregateError: All promises were rejected
Fail from alpha,Fail from bad bob,Fail from charly Promise.race For the final method, I'll cover, has this behavior: race Given an array of promises, resolve or reject with whatever happens first. Here are a few examples. First, all good: log('\n\nTEST RAY EIGHT - Promise.race(all good)');
test = [
	makePromise('alpha', 3),
	makePromise('bob', 1),
	makePromise('charly', 3)
];
results = await Promise.race(test);	
log('Results from test with Promise.race');
log(results); And the output: TEST RAY EIGHT - Promise.race(all good)
Good result for bob
Results from test with Promise.race
Resolve from bob
Good result for alpha
Good result for charly And here's one with a 'bad' winner: log('\n\nTEST NINE - Promise.race(bad guy wins)');
test = [
	makePromise('alpha', 3),
	makePromise('worst bob', 1, true),
	makePromise('charly', 3)
];
try {
	let results = await Promise.race(test);
} catch(e) {
	log(`Expected failure in test: ${e}`);
} And its results: TEST NINE - Promise.race(bad guy wins)
Bad result for worst bob
Expected failure in test: Fail from worst bob
Good result for alpha
Good result for charly Pretty simple to understand, I think. The MDN docs have a of how to use to add timeouts to network calls. great example Promise.race Demo You can see all of the above yourself at the following CodePen, but you may want to open it up in a new tab. https://codepen.io/cfjedimaster/pen/bGZmRXB?embedable=true Also published . here

Exploring JavaScript Promise Collection Methods

As my readers know, I've been updating some of my earlier Vue.js examples to demonstrate how they would work with . Normally I post these "conversions" when I see one of the Vue posts pop up in my stats. Today I noticed this entry was "trending" - . I thought it would be a great candidate for showing an Alpine version. Let's take a look. Alpine.js Vue Quick Shot - Downloading Data as a File While I won't repeat everything from the previous post, I'll quickly cover how it worked. First, it makes use of the attribute of the anchor tag. This will take a normal link operation and instead ask the browser to download the resource at the URL. To do this with client-side data, you can create an anchor tag with , set it to point to your data, and then emulate a event. I used this a few days ago in an Eleventy article: . download createElement click Adding Download Support in an Eleventy Site In the original article, I first demonstrated downloading a JSON file. But as most humans don't speak JSON, I then used to convert it to CSV. I'm going to follow the same flow for this update. Papa Parse First Version - Downloading JSON Data For the first version, we're going to look at a tabular set of cats. I will not make you scroll past the gratuitous picture of a cat on a table. Heh, I lie: Ok, so our data: "cats":[
	{"name":"Alese", "gender":"female", "age": 10},
	{"name":"Sammy", "gender":"male", "age": 12},
	{"name":"Luna", "gender":"female", "age": 8},
	{"name":"Cracker", "gender":"male", "age": 7},
	{"name":"Pig", "gender":"female", "age": 6}
] The application begins by simply rendering this into a table. (Not a sortable or paginated one, but check out my other posts for examples of that.) I started off with this HTML: Alpine.js <div x-data="app">
	<table>
		<thead>
			<tr>
				<th>Name</th>
				<th>Gender</th>
				<th>Age</th>
			</tr>
		</thead>
		<template x-for="cat in cats">
			<tr>
				<td x-text="cat.name"></td>
				<td x-text="cat.gender"></td>
				<td x-text="cat.age"></td>
			</tr>
		</template>
	</table>
</div> Alpine is used to loop over the array. Here's the initial JavaScript: cats document.addEventListener('alpine:init', () => {
  Alpine.data('app', () => ({
	cats:[
      {name:"Alese", gender:"female", age: 10},
      {name:"Sammy", gender:"male", age: 12},
      {name:"Luna", gender:"female", age: 8},
      {name:"Cracker", gender:"male", age: 7},
      {name:"Pig", gender:"female", age: 6}
      ]		
  }))
}); Now I'm going to add a download button that will trigger the download process: <button @click="download">Download</button> I then added my handler. This code is a bit simpler than the previous version which added to anchor to the DOM, invisibly, and then clicked. download() {
	let text = JSON.stringify(this.cats);
	let filename = 'cats.json';
	let element = document.createElement('a');
	element.setAttribute('href', 'data:application/json;charset=utf-8,' + encodeURIComponent(text));
	element.setAttribute('download', filename);
	element.click();
} If you read my previous article involving , the biggest difference here is creating the data URL string that has the original data encoded into a string. You can test this version yourself here: Eleventy and downloads https://codepen.io/cfjedimaster/pen/YzjzaGz?embedable=true Second Version - Downloading CSV For the next version, we just need to convert the JSON data to CSV. Once again I'll use as it makes this trivial. Instead of Papa Parse let text = JSON.stringify(this.cats); We can use: let text = Papa.unparse(this.cats); I then made two more changes. First, the filename: let filename = 'cats.csv'; And then the mime-type: element.setAttribute('href', 'data:text/csv;charset=utf-8,' + encodeURIComponent(text)); That's literally the entire change. Now when clicking download you get a CSV that can be opened in Excel. My previous post had a screenshot of that but as this was before you could use Dark mode in Office, I figured I'd update it with a new one: Here's the entire example: https://codepen.io/cfjedimaster/pen/yLqLKoj?embedable=true Also published . here

Downloading Data as a File with Alpine.js

In a I was explaining the basics of setting up GO application for REST API. Now I'll go into details by first creating configurable server, adding http router (mux) and some DB interaction. Let's get (the party) started! previous post indoors The application is now running in docker, can respond to code changes and reload for instant feedback. For handling http requests I will add another dependency, http router (mux). You can read more about it . here This is a lightweight, high performance HTTP request router that is easy to use and has everything most api's will need. $ go get -u github.com/julienschmidt/httprouter Time to create the server. I'll place it in directory as it could potentially be reused: pkg/ server ( ) Server {
	srv *http.Server
} { &Server{
		srv: &http.Server{},
	}
} {
	s.srv.Addr = addr s
} {
	s.srv.ErrorLog = l s
} {
	s.srv.Handler = router s
} { (s.srv.Addr) == { errors.New( )
	} s.srv.Handler == { errors.New( )
	} s.srv.ListenAndServe()
} { s.srv.Close()
} package import "errors" "log" "net/http" "github.com/julienschmidt/httprouter" type struct * func Get () Server return * func (s *Server) WithAddr (addr ) string Server return * func (s *Server) WithErrLogger (l *log.Logger) Server return * func (s *Server) WithRouter (router *httprouter.Router) Server return func (s *Server) Start () error if len 0 return "Server missing address" if nil return "Server missing handler" return func (s *Server) Close () error return As usual, function returns pointer to our server instance that exposes some public methods that are pretty self explanatory. It will become more obvious when I put this server to work in the main program. Get Server will need routes and handlers to communicate with outside world. I'll add that next: router ( ) {
	mux := httprouter.New()
	mux.GET( , getuser.Do(app)) mux
} // cmd/api/router/router.go package import "github.com/boilerplate/cmd/api/handlers/getuser" "github.com/boilerplate/pkg/application" "github.com/julienschmidt/httprouter" * . func Get (app *application.Application) httprouter Router "/users" return getuser ( ) { {
		fmt.Fprintf(w, )
	}
} // cmd/api/handlers/getuser/getuser.go package import "fmt" "net/http" "github.com/boilerplate/pkg/application" "github.com/julienschmidt/httprouter" . func Do (app *application.Application) httprouter Handle return func (w http.ResponseWriter, r *http.Request, ps httprouter.Params) "hello" I define all my routes in and call handlers by explicitly passing application configuration so that each handler has access to things like database, configuration with env vars and more. router.go I keep my handlers separate from router and group them under sub folders . One reason is that handler will have corresponding test file. It will also have multiple middleware files that will also have tests and there can be a lot of handlers. If not grouped correctly, it can get out of hand very fast. cmd/api/handlers/{handlerName} Now there are few more building blocks: server, router, logger. Let's assemble it all in the main program: main ( ) { err := godotenv.Load(); err != {
		logger.Info.Println( )
	}

	app, err := application.Get() err != {
		logger.Error.Fatal(err.Error())
	}

	srv := server.
		Get().
		WithAddr(app.Cfg.GetAPIPort()).
		WithRouter(router.Get(app)).
		WithErrLogger(logger.Error) {
		logger.Info.Printf( , app.Cfg.GetAPIPort()) err := srv.Start(); err != {
			logger.Error.Fatal(err.Error())
		}
	}()

	exithandler.Init( { err := srv.Close(); err != {
			logger.Error.Println(err.Error())
		} err := app.DB.Close(); err != {
			logger.Error.Println(err.Error())
		}
	})
} // cmd/api/main.go package import "github.com/boilerplate/cmd/api/router" "github.com/boilerplate/pkg/application" "github.com/boilerplate/pkg/exithandler" "github.com/boilerplate/pkg/logger" "github.com/boilerplate/pkg/server" "github.com/joho/godotenv" func main () if nil "failed to load env vars" if nil go func () "starting server at %s" if nil func () if nil if nil New things to mention is that I assemble the server by chaining method calls and setting properties on the instance. One interesting thing is , this is just to instruct the server to use my custom logger for consistency. WithErrLogger(logger.Error) I start the server in separate go routine so that can still run and gracefully handle program shutdowns. contains 2 instances of standard library Logger. is printing out messages to and to . I could have used some fancy logger like or any other but I was planning to keep it simple. exithandler pkg/logger Info os.Stdout Error os.Stderr logrus Next let's take care of the databases. I use migration tool written in GO that can be used as CLI or as a library. You can read more about it and find installation instructions . After installing it, let's create few migration files. As seen from above, I'll be operating on resource so it's natural I'll have table: here /users users $ migrate create -ext sql -dir ./db/migrations create_user This will generate 2 migration files in , and for user table. All files are empty so let's add some sql. db/migrations up down Up: public.users
( PRIMARY ,
    username ( ) ); -- db/migrations/${timestamp}_create_user.up.sql CREATE TABLE IF NOT EXISTS id SERIAL KEY VARCHAR 100 NOT NULL UNIQUE And down: public.users -- db/migrations/${timestamp}_create_user.down.sql DROP TABLE Pretty simple, but that's how it should be, right? Before running migrations, let's use library and create a program to simplify this process. This will also work nicely in CI/CD pipelines as it will let us  skip the installation of cli as a separate step of the pipeline build. For that to happen I'll add yet another dependency: golang-migrate golang-migrate $ - github. /golang-migrate/migrate/v4 go get u com I'll name my program : dbmigrate main ( _ _ ) {
	godotenv.Load()
	cfg := config.Get()

	direction := cfg.GetMigration() direction != && direction != {
		log.Println( ) }

	m, err := migrate.New( , cfg.GetDBConnStr()) err != {
		log.Printf( , err) } direction == { err := m.Up(); err != {
			log.Printf( , err) }
	} direction == { err := m.Down(); err != {
			log.Printf( , err) }
	}
} // cmd/dbmigrate/main.go package import "log" "github.com/boilerplate/pkg/config" "github.com/golang-migrate/migrate/v4" "github.com/golang-migrate/migrate/v4/database/postgres" "github.com/golang-migrate/migrate/v4/source/file" "github.com/joho/godotenv" func main () if "down" "up" "-migrate accepts [up, down] values only" return "file://db/migrations" if nil "%s" return if "up" if nil "failed migrate up: %s" return if "down" if nil "failed migrate down: %s" return Quick overview of what's happening here. First of all I load env vars. I then get pointer to instance of config that will give me easy access to all vars I need with some helper methods. You might have noticed that there's a new method. It will simply return or string to instruct my program if it should migrate database up or down. You can see latest changes . GetMigration up down here Now since I have this tool in place I can put it to work. Best place I found for it is By running it there I'm avoiding common "oh, I forgot to run migrations" issue. Updated version of : scripts/entripoint.dev.sh entrypoint.dev.sh -e

go run cmd/dbmigrate/main.go

go run cmd/dbmigrate/main.go -dbname=boilerplatetest

GO111MODULE=off go get github.com/githubnemo/CompileDaemon

CompileDaemon --build= -- =./main #!/bin/bash set "go build -o main cmd/api/main.go" command What's happening here? First run of will use all default values from .env file, so it will run the migrations up against db. In second run I pass so that it does the same but against db. Next I'll start my app with clean state: dbmigrate boilerplate -dbname=boilerplatetest boilerplatetest docker container rm -f $(docker container ps -a -q) docker volume prune -f docker-compose up --build # remove all containers # clear volumes # start app If all the above has worked, we should see table in both and databases. Let's check that: users boilerplate boilerplatetest docker -it $(docker ps --filter name=pg --format ) /bin/bash psql -U postgres -W \l \c boilerplate
\dt \c boilerplatetest
\dt # connect to pg docker container exec "{{.Names}}" # launch psql cli # ensure both DBs still present # connect to boilerplate database and list tables # do same for boilerplatetest # in both databases you should see users table This is what I see when the above commands are run: And sure thing it's all as expected. Now what if we add new migrations while application is running in docker. I'm pretty sure it's not very convenient to stop docker-compose and rerun the command again for changes to take place. Well, program is capable of handling this scenario. In new terminal tab: dbmigrate go run cmd/dbmigrate/main.go \
  -migrate=down \
  -dbname=boilerplatetest \
  -dbhost=localhost go run cmd/dbmigrate/main.go \
  -migrate=up \
  -dbname=boilerplatetest \
  -dbhost=localhost # migrate boilerplatetest db down # you can now repeat steps from above to connect to pg container # and ensure that users table is missing from boilerplatetest DB. # now bring it back up One thing to mention here is . This is because we connect to pg container from our host machine. Within docker-compose we can refer to same container by service name, which is , but we can't do same from host. -dbhost=localhost pg I hope you have learned something useful. In part 3 I'll go through simple CRUD operations for our users resource. It will include middleware usage, validations and more. You can also see the whole project and follow the progress . Stay safe! here

How To Create Golang REST API: Project Layout Configuration [Part 2]

Making a test suite in Go projects with a real live database/service Photo by on ShareGrid Unsplash Software testing is a process used to identify the correctness, completeness, and quality of developed computer software. There are so many kinds of software testing. Start from unit-testing, load-testing, stress-testing, integration-testing, UI-testing, e2e-testing, and many more. Every kind of testing have a different purpose, unit-testing aims to test a single unit of function. Load testing aims to measure how reliable our system against a huge request. And Integration testing aims to ensure our system can integrate with the external services without any issues. Integration Testing In Go In this article, I won’t tell any other test except integration testing. This kind test as I said earlier is to ensure that our systems can integrate to external services without any issues. So with this test, we hope we can avoid any unnecessary error or bug when deploying our applications to the server whatever its environment (staging, production) So, before moving how to do it in Golang, let me clarify a few things before I explain many things below. Actually, I don’t know that this kind of testing is looking good for many people, but this is how we made an integration testing in our company (my current company when writing this). If you have an any better idea, it really pleasures if you tell us it in the comment below. Kurio Preparation and Tools In this article, to make it clear, I’ve listed and prepared a few things as my tools and helper here. Docker installed (specifically, docker-compose)github.com/stretchr/testify for testing package toolsgithub.com/go-redis/redis for Redis drivergithub.com/golang-migrate/migrate for migration packageetc listed in go.mod So I will use 2 kinds of database, and my simple application will connect to this database. What I will explain is, how to make an integration testing against to my both database here. So I will use MySQL and also Redis well, technically we also can say Redis as a database but NoSQL, if it's not, well just assume it was a database :D. Test Suite So let’s say I have a project that depends on both of this database, you can look my entire simple projects here: https://github.com/bxcodec/integration-testing If you look to packages mysql and redis you will find my function handler to connect to each DB itself and also its file test. Each test was a Suite test. A bundle test that will test my handler. To make a suite test it’s easy, thanks to github.com/stretchr/testify I can do it with ease. For example, you can look at my redis package. At suite_test.go I define a RedisSuite struct that will be reusable by any test-file. package redis_test import ( ) <br> "github.com/go-redis/redis" <br> "github.com/stretchr/testify/suite" <br> type RedisSuite struct {<br> suite.Suite<br> Host     string<br> Password string<br> DB       int<br> *redis.Client<br>} Client func (r *RedisSuite) {<br> r.Client = redis. <br>} SetupSuite() NewClient(& ; .Options{< >  Addr: .Host,< >  Password: .Password,< >  DB: .DB,< > }) amp redis br r br r br r br {< > . . < >} func (r *RedisSuite) TearDownSuite () br r Client Close () br Thanks to testify package, it really helpful to create a suite test. Later with this struct, I just can easily embed it to my test-file. You can see at mycache_test.go If you look, the cache_test.go file, it’s a bit different with the normal file-test. If in normal test-file we ussually have this pattern: {} func TestXXXX (<strong>t *testing.T</strong>) // with testing param It always has the testing param in each test. And it’s required. But in this case, because I use the testify package, there a bit different how to do the test. And it really matters. To add a test case, we must follow the pattern: {} func (s TestSuite) TestXXXX () //without testing param For example, in my redis test-file (cache_test.go), you could see that I have 2 test they are: TestSet and TestGet. Running The Test To run the test, it still the same as usual. Run it with: go test. But, because this test requires live Databases(MySQL and Redis), at first, we need to run a live database in our testing environment. If we run the testing in our local, then make sure that our required Databases alive and can access from our local pc. If we run the testing in CI/CD server, then we must provide a live database to fulfill the test. Luckily, in this modern software engineering era, there was a tool like Docker exists. We can run our database in docker container, so we don’t have to have a real database live just for testing needs. To make it easy, I will use the docker-compose feature, look my docker-compose.yaml. With just command docker-compose up -d, then I will have a 2 database live in a docker-container so that I can test it directly with it. To ease me, I just make it into a Makefile. So before running my integration-test, I need my database already live in container. So now, to do my testing I just do it with one command: $ make integration-test // integration <br>$ make unittest // just unit-testing for test for demo integration testing command with make fileUsing it With CI/CD (Travis) Every CI/CD may have different feature. Actually, in my current company ( ) we use BuddyWorks as our CI/CD tools, but if I use BuddyWorks here, it will look very easy to do, because, in BuddyWorks, we just drag and drop no scripting :D. Kurio So to make it more fun and more “hacky” and “geeky” that looks very terminal based as many people see us the engineer that only working with the terminal and love the black screen :D, so I decided to use Travis CI/CD for this article :D Setup the travis.yml script Before move forward, first, we need to add our project to travis-ci.com and enable the CI/CD pipeline there. Later, we just need to add our .travis.yml in our project. For my project, you can look all the entire script of .travis.yml in my repository. Then later, enable it in Travis, find and enable our repo in Travis And all will run the test in Travis. Boilerplate!!! We just add our TestSuite boilerplate based on Database provider and driver-library into separated packages: You can look it here: https://github.com/golangid/testada To use this package, for example, you want to make a MySQL integration test, you can directly import the testada/mysql package. And embed directly the MySQL suite structs. import "github.com/golangid/testada/mysql" youItemMysqlTestSuite type {< > . < >// / </ >< >} struct br mysql MysqlSuite strong embed from testada mysql strong br func TestYourItemMysqlSuite(t *testing.T) {< > testing.Short() {< >  t.Skip( )< > }< > dsn := os.Getenv( )< > dsn == {< >  dsn = < > }< > yourItemSuite := &amp;youItemMysqlTestSuite{< >  MysqlSuite{< >   DSN:                     dsn,< >   MigrationLocationFolder: ,< >  },< > } br if br "Skip you item mysql repository test" br br "MYSQL_TEST_URL" br if "" br "root:root-pass@tcp(localhost:3306)/testing?parseTime=1&amp;loc=Asia%2FJakarta&amp;charset=utf8mb4&amp;collation=utf8mb4_unicode_ci" br br br br br "migrations" br br suite. <br>} Run( , ) t yourItemSuite At least, this package already makes the boilerplate like setting the migration (if using migrations) or handle the test-suite setup that will help you work faster. :D Also, it’s required to understand how testify/suite works, before implementing your own integration test like ours. Once again, as I tell at the beginning of this article, this is how we made an integration testing in our company (my current company when writing this). If you have an any better idea, it really pleasures if you tell me it in the comment below. But if you found this very useful, please share this with anyone who might need this. ^_^ Kurio

Integration Test With Database in Golang

Using nothing but the standard library It is a common requirement to encounter the necessity of having various operations needed around incoming requests to your server. The most prevalent examples would be logging and tracing. Although there are various frameworks out there that provide this out of the box, I’d like to illustrate how simple it is to create this logic using nothing but the standard library. Building your own implementation gives you full flexibility and control over the behaviour, reducing the need for external dependencies. HTTP Ideally, I would prefer the API to look something like this, within the context of my naive example: In the above example, I used to create a wrapper for all my handlers, which augments both and with the logging and tracing that I’ve defined and passed as parameters to this function. chainMiddleware home about middleware In order for this to work, we need to define a middleware type. It can be defined as: Thereby, a will be defined as a function that returns a new handler which will perform some operations before (or after) calling the next handler that is provided as an argument. For the sake of brevity when illustrating these examples, we’ll be using instead of the classical . The behaviour is the same. middleware [http.HandlerFunc](https://golang.org/pkg/net/http#HandlerFunc) [http.Handler](https://golang.org/pkg/net/http#Handler) Using this pattern we define the dummy and middleware as such: withLogging withTracing Our middleware is purely illustrative and does nothing but log that an action has been taken. We could theoretically already use this implementation, without the need for , simply by defining each route as such: chainMiddleware This is good and it works but can quickly become tedious and verbose if we introduce more middleware. Thus, our chain function provides nice syntactic sugar for chaining multiple middleware into one. Let’s look at the implementation: By making use of the functional programming features of Go, we can use the above implementation to link a chain of middleware which call into one another in the provided order, returning a new wrapper for our handlers. We take each middleware function in the list in reverse order and pass its return value as an argument to the one before it, starting with the handler. In this way, the chain happens in the order that it is passed in. final Now, if we run the program and visit in the browser, we should expect to see something similar to the following output in the console, before the final handler is called: http://localhost:8080 main.go:34: Logged connection from [::1]:54962 main.go:41: Tracing request for / Simple as that! You can find the full running example . here

Simple HTTP middleware with Go

geralt @ pixelbay Every day that I work in JavaScript-land, I stumble across a mixture of callbacks, promises or async/await. I have my own preferences in how I like to handle async code, though sometimes I don’t have a choice because an external library like , , , etc. is using something else. fs serverless aws-sdk One thing I dislike in any codebase is inconsistency. So, if I start with promises, I’m going to use promises throughout. This presents one minor issue; how can I maintain consistency in a project that has external libraries. Well, as the title of this article suggests, I transform them. Callbacks and Promises The most common scenario I run into is an older library using node-style callbacks that I would prefer to use with promises, or async/await, same stuff. As a refresher, your typical node-style callback might look like this: fs.readFile('./kittens.txt', (err, data) => {  if (err) throw err;  console.log(data);}); But this is how I want to access the method: fs.readFile('./kittens.txt')  .then(data => console.log(data)) Often, I just punt and use from . This is the easiest, fastest and approach. But… promisify bluebird.js laziest Importing a library to use but a single function is lazy and should be discouraged. … especially when the function in question would be simple to write. (google ) leftpad broke the internet Stop right now and take a look at the size of your node_modules folder. It’s obscene! It is not uncommon to have a node_modules folder in excess of 1GB or even 2GB! These things add up. Promisify What we want is called a . Function Decorator A is a higher-order function that takes one function as an argument, returns another function, and the returned function is a variation of the argument function. function decorator source Example of what a function decorator would look like: promisify const readFile = promisify(fs.readFile) readFile ('./kittens.txt')     .then(data => console.log(data)) The function , still strongly related to , has been transformed into a variant of the original. This is a . readFile fs.readFile function decorator This should be easy to make. First we create the function that takes 1 argument, and returns a function. When that returned function is called it will return a promise. promisify func function promisify(func) {return () =>new Promise((resolve, reject) => { })} We used the keyword above because we will need access to , which is not available to arrow functions. function this Notice (below) how one additional argument, is appended to the end of . This is because our decorated function will not take a callback as an argument, but the original function does. callback args func func.apply(this, [...args, callback]) Put together it starts to look something like this: function promisify(func) {return ( ) =>new Promise((resolve, reject) => { ...args const callback = ??? **func.apply(this, \[...args, callback\]);**  
}) } The final step also happens to be the easiest, create the . The is simply a node-style that will call either or based on the presence of . callback callback callback resolve reject err Callbackify I ran into a less common situation where what I needed was the reverse. The function I had to create needed to be a node-style callback function. Uggg, my code was already written using promises. The code in question is for AWS lambdas, which are typically written using callbacks so my code ended up looking something like this: module.exports.handler function(event, context, ) {myHandler(event).then(data => ).catch(err => )} = callback callback(null, data) callback(err) Because my library is all Promise based, I would much prefer to write something like this: module.exports.handler = (event, context) =>myService(event) // note: I don’t need context. I ended up creating the reverse of , so I can create my lambda like this: promisify callbackify module.exports.handler = callbackify((event, context) =>myService(event)) Since we’re pretty much doing the same as above, we can zip through this a little quicker. Let’s create with a single argument, , that returns a function. Since the function that is returned will take args + callback as arguments, we are going to have to separate them from each other. callbackify func function callbackify(func) {return function(...args) { }} const onlyArgs = args.slice(0, args.length - 1)const callback = args[args.length - 1] Finally, we need to call on and pass in our . apply func onlyArgs How does async/await fit into all of this? async and await operates almost exactly like promises, so you can use them interchangeably. const readFile = promisify(fs.readFile)const file = await readFile('./kittens.txt) console.log(file) Check that out, you can await a node-style function. Neat! callback The Takeaways Whether you use callbacks, promises or async/await, it is most important to be consistent. Try creating your own functions before importing a library. If you want to tweak how a library function works, create a . function decorator Github I put these functions up on github so that I can easily import them into my projects as I use them in almost every project. You are welcome to use them as well. _functional-helpers — Functional helpers_github.com joelnet/functional-helpers Related util.promisify is being added to node bluebird’s promisify End If you found this interesting, or are interested in functional programming, you might enjoy some of my other articles. _Read the latest stories written by Joel Thoms on Medium. Computer Scientist and Technology Evangelist with 21 years of…_medium.com Latest stories written by Joel Thoms — Medium I know it’s a small thing, but it makes my day when I get those follow notifications on Medium and Twitter ( ). Or if you think I’m full of shit, tell me in the comments below. @joelnet Cheers!

Function decorators: Transforming callbacks into promises and back again

Photo by on Ales Krivec Unsplash Logging is one of the things that’s extremely important to do well, especially in the (micro)services and functions world where you have to track what’s happening across hundreds of services and functions. In this post I’ll briefly look at how to collect logs from your Fn functions Prerequisites Fn CLI Fn Server (you can use command to bring up a local server) fn start Create a Simple Go Function Start by creating a new function with the Fn CLI ( ). I have added two log statements — hello and goodbye — to the function as shown below: fn init --runtime go Boilerplate Fn function with two logging statements added Let’s deploy and call this function like this: $ fn deploy --app logtest ... deploy output ... $ fn call logtest /logtest{"message":"Hello World"} Note: instead of running you can always list the routes of your app ( ) and then call the actual endpoint directly. fn call fn list routes [appname] So we get the response from the function — but where are the logs? The Fn CLI has a command that allows you to retrieve the logs for a specified app and a call id. App name is not enough to get the logs — you need to be more specific and provide a call ID that gets create each time you call a function. To get the calls, you run the command and provide your app name. fn list calls $ fn list calls logtest You will get a response that will list all calls to your function — each call having a unique ID, time stamps, app and route information and status: ID: 01CMFXT9D3R2M0250ZJ0000004App Id: 01CMFXG599R2M0250ZJ0000001Route: /logtestCreated At: 2018-08-09T11:05:11.459-07:00Started At: 2018-08-09T11:05:11.992-07:00Completed At: 2018-08-09T11:05:11.996-07:00Status: success ID: 01CMFXK7KPR2M0250ZJ0000002App Id: 01CMFXG599R2M0250ZJ0000001Route: /logtestCreated At: 2018-08-09T11:01:20.246-07:00Started At: 2018-08-09T11:01:20.776-07:00Completed At: 2018-08-09T11:01:20.794-07:00Status: success : your function will probably be invoked a lot of times — you can easily filter down the calls you want to get by specifying or options or filtering down the calls by the functions’ path ( ) or number of calls to return ( ) Note --from-time --to-time --path -n Let’s grab one of the call IDs and get the logs for it: $ fn get logs logtest 01CMFXK7KPR2M0250ZJ00000022018/08/09 18:01:20 Hello MyHandler2018/08/09 18:01:20 Goodbye MyHandler Yay — we got our logs! All good and well, but there’s no way one can do this manually for hundreds of functions and thousands or tens of thousands of calls across all functions. It would be way more convenient if we could collect all these logs in some central place. Collecting logs I have decided to try and see how to hook it up with Fn to send all my functions logs there. Papertrail I have signed up at their website and quickly went through the logging setup to get the endpoint I can send my logs to — something like . With this URL I can configure my app and tell it that I want all logs to go to that URL. logsXYZ.papertrail.com:12345 To do that, we .need to set the setting on the app like this: syslog-url $ fn update app logtest --syslog-url=tls://[papertrail-endpoint]app logtest update Test it out the same way as previously — by making a couple of calls to the function. The output from the functions is still the same, also if we check the call logs, we should still see the same logs as before. However, we also get the same logs in Papertrail as seen below: Logs being sent to Papertrail The good thing about central log collection system is that it gives you the ability to retain the logs, search though them and even set up alerts if you want to. Additionally, you can also filter down logs by app name or ID or function or call name. This way, diagnosing what’s happening and what went wrong becomes much easier. Conclusion In this short article we created a boilerplate function and configured our app to automatically send all logs to a cloud log collection system (in our case we used , but you could use any other provider as well). Fn Papertrail Thanks for Reading! Any feedback on this article is more than welcome! You can also follow me on and . If you liked this and want to get notified when I write more stuff, you should subscribe to ! Twitter GitHub my newsletter

Collecting logs from serverless Fn functions

Say goodbye to the medieval class constructor in your React components. While Stateless Function Components (SFCs) are a handy tool in your arsenal, Class Components are still the de-facto way to write React components that utilizes state or lifecycle hooks. ES6 A hypothetical ES6 Class Component might look something like this (over-simplified without error checking, of course). class Foo extends Component {constructor(props) {super(props);this.state = { loading: true };} async componentDidMount() {const data = await loadStuff();this.setState({ loading: false, data });} render() {const { loading, data } = this.state;return ({loading ? <Loading /> : <View {...data} />});}} We initialize our in the , asynchronously load our data in , and render our component based on the state. A pretty standard pattern — at least for me, if you’ve been following my work. state constructor componentDidMount View loading Class properties We’ve all been taught that the is where we initialize our instance properties, in this case. And if you are saying to yourself, “Exactly!”, then you would be absolutely correct… if not for the upcoming ES.next , currently in stage 3. constructor state class properties proposal With it we can now define class properties directly, like this. class Foo extends Component {state = { loading: true };...} will transpile your code and add a for you behind the scenes. Here is the output from Babel when we transpile the code snippet above. Babel constructor Note that Babel is actually passing all args — not just — down to . It is also taking ’s return value and passing it back to the caller. Both may be a bit overkill, but exactly what it should be doing. props super super There’s still a constructor, you just don’t see it. Binding methods Another reason that we’re taught to use the is for binding methods to , like so. constructor this class Foo extends Component {constructor(props) {super(props);this.myHandler = this.myHandler.bind(this);} myHandler() {// some code here that references this}...} Some people ignore this all together by assigning a function expression to a class property, but that’s a different story all-together. Read more about this in my other ES6 React Classes article . Demystifying Memory Usage using ES6 React Classes _Which is more efficient? Binding in the constructor, or using an arrow function as a class property?_medium.com Demystifying Memory Usage using ES6 React Classes Let’s assume for a moment that you are in the camp (and even if you’re not, bear with me). We’ll need to bind in the , right? Not necessarily. We can do the same thing that we did for class properties above. bind constructor class Foo extends Component {myHandler = this.myHandler.bind(this); myHandler() {// some code here that references this}...} Initializing state with props What about when you need to derive your initial from , say for initializing a default value? Surely we need the for that? state props constructor class Foo extends Component {constructor(props) {super(props);this.state = {color: this.props.initialColor};} render() {const { color } = this.state;return (<div>{color}</div>);}} Nope! Again, class properties to the rescue! We have access to both and . this props class Foo extends Component {state = {color: this.props.initialColor};...} Data fetching Maybe we need a to fetch data? Hardly. As we saw in our first code sample, any data loading should be done in . But why ? We do it there so that the fetch isn’t performed when running the component on the server — as is the case when doing Server Side Rendering (SSR) — as is performed server side. constructor componentDidMount componentDidMount componentDidMount not Conclusion We’ve seen that for setting our initial , we no longer need a (or any other instance property for that matter). We also don’t need it for binding methods to . Same for setting initial from . And we would most definitely never fetch data in the . state constructor this state props constructor Why then would we ever need the in a React component? constructor Well… you don’t. [However… If you find some obscure use case where you need to initialize something in a component, both client-side and server-side, you still have an out. There’s always _componentWillMount_ . Internally, React calls this hook right after “newing” the class (which calls the _constructor_ ) on both the client and the server.] So I maintain that for React components: The constructor is dead, long live the constructor! Further Reading Well, not reading, but has a on class properties that you may want to read, um… watch. Kent C. Dodds nice video tutorial You can also read a bunch of (including some on Hooks in React 16.7, {…❤️} Spread Love, and React Best Practices) on the AmericanExpress.io Technology Blog. React based articles I also write for the American Express Engineering Blog. Check out my other works and the works of my talented co-workers at AmericanExpress.io . You can also follow me on Twitter .

MY HANDLER

myhandlerapp.com

-- employees

Since n.d.

COMPANY RANKING

MY HANDLER

EVERGREEN INDEX #6982

Representing this company? Click here to claim and customize this page!

My Handler WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

MY HANDLER

myhandlerapp.com

-- employees

Since n.d.

COMPANY RANKING

MY HANDLER

EVERGREEN INDEX #6982

RELATED COMPANIESRANK

STORIES ABOUT MY HANDLER

Representing this company? Click here to claim and customize this page!

My Handler WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!