Our Blog.

Expert thoughts from our software developers and design leaders.

  • Antonio Pagano on September 7, 2019

    Buffalo+Sendgrid is it possible?

    Sendgrid is one of the most well-known and used email delivering solutions. It has solutions for most (if not all) of the common email sending and delivering issues that we could face as developers. But this post is not about convincing you to use Sendgrid.

    One of the things I love about Buffalo is that it ships with all of the things a product needs for rapid application development and deployment. In this case that is email. Buffalo has a mail package that you can use to integrate sendgrid or any other provider with your app.

    import github.com/buffalo/mail

    Buffalo’s mail package key items are the Sender interface and the Message struct. It also ships with an SMTPSender implementation of the Sender interface which could be used if you have an SMTP server or want to use your gmail/hotmail email to send emails. I do not recommend you to use a single email account for SMTP on production environments but it could be useful when doing very quick iterations and hacks.

    Sender interface

    The Sender interface is a very simple interface which is defined as:

    type Sender interface {
    	Send(Message) error

    What essentially says that anything that has a Send method that receives a mail.Message and returns an error can be considered as a Buffalo email Sender. Simple huh?

    Message struct

    The second part of the equation is the Message struct. This struct is the representation of the email message inside the mail package. It has fields like From, To and Cc which should sound for anyone who has sent or received an email before.

    I will not go into deep details of this one because I just want to give an overview of the email package, but you could go and check it out here.

    Plugin Sendgrid in

    As I mentioned before Buffalo allows developers to implement their own Sender. In order to plug in Sendgrid you will use a Sendgrid implementation for the Sendgrid API.


    To do so I’m assuming you:

    Assuming that’s all set, lets continue.

    Generating mailers package

    One common pattern/best practice in buffalo is to have your email-sending functions in a package called mailers.

    If you don’t have this folder in your app it means you have not generated it. It doesn’t get generated with the new app. You can generate it by running the following command:

    buffalo g mailer your_first_mailer_name

    This will generate:

    • mailers folder
    • mailers.go file
    • your_first_mailer_name.go file (with your first mailer there).

    Lets focus on the mailers/mailers.go file.

    Modifying mailers.go

    mailers.go file is the place where the mailers configuration resides. At the moment I’m writing this (buffalo v0.14.10) after running the command I mentioned before that file looks like this:

    var smtp mail.Sender
    var r *render.Engine
    func init() {
    	// Pulling config from the env.
    	port := envy.Get("SMTP_PORT", "1025")
    	host := envy.Get("SMTP_HOST", "localhost")
    	user := envy.Get("SMTP_USER", "")
    	password := envy.Get("SMTP_PASSWORD", "")
    	var err error
    	smtp, err = mail.NewSMTPSender(host, port, user, password)
    	if err != nil {
    	r = render.New(render.Options{
            HTMLLayout: "layout.html",
    		TemplatesBox: packr.New("app:mailers:templates", "../templates/mail"),
            Helpers: render.Helpers{},

    This is cool if you were going to use the SMTP sender. It has everything you need to use it. However, since we’re going to use the Sendgrid sender we will need to change it to be:

    import (
        ssender "github.com/paganotoni/sendgrid-sender"
    var sender mail.Sender
    var r *render.Engine
    func init() {
    	APIKey := envy.Get("SENDGRID_API_KEY", "")
    	sender = ssender.NewSendgridSender(APIKey)
        r = render.New(render.Options{
            HTMLLayout: "layout.html",
    		TemplatesBox: packr.New("app:mailers:templates", "../templates/mail"),
            Helpers: render.Helpers{},

    This will require now that you add your Sendgrid API key to your development and production servers as an environment variable SENDGRID_API_KEY. This is so the Sendgrid Mailer is able to communicate with the Sendgrid API in order to send your emails.

    And as long as the same sender.Send method is called from within your mailer functions all will work as with the default SMTPSender. p.e:

    func NotifyForgotPassword(user models.User) error {
    	m := mail.NewMessage()
    	m.Subject = "Your password change request"
    	m.From = "do-not-reply@wawand.co"
    	m.To = []string{}
    	err := m.AddBody(r.HTML("password-forgot.html"), render.Data{
            "FullName":     user.FullName(),
    		"Link":         user.ForgotPasswordLink(),
    		"ReportLink":   user.ReportForgotPasswordLink(),
    	if err != nil {
    		return err
    	return smtp.Send(m)

    And that’s all. You can now use sendgrid to send emails for your Buffalo app.

    Wrapping up

    Thank you for reading this article. I hope you have enjoyed this brief description on how to use Sendgrid with your Buffalo app. If you are using Postmark I wrote a Sender for it, you can check it out here.

    If you have questions or comments about this post, you can find me on twitter at @paganotoni. You can also find my company at @wawandco. I would love to hear your opinions on this and other posts.

    Continue Reading
  • Antonio Pagano on August 31, 2019

    Deploying Buffalo to Google Cloud Run

    Google Cloud Run is a service that allows you to run containerized applications in a serverless environment. This means that you don’t have to care about servers. Billing is done for what you use in terms of memory and processor for time (Google provides a free tier you can check here).

    In this post, I will describe how you deploy your Buffalo application to Cloud Run.


    In order for us to be able to send the app to Google Cloud Run, you need:

    • Docker installed
    • Gcloud CLI tool installed with the beta components
    • Gcloud logged into your google account
    • Docker setup with your GCR account

    I'll continue with this post assuming you have all that, if you need instructions for these you can go here and take a look at how to install or setup these tools.

    Building container image

    After ensuring you have all the permissions and given Buffalo ships with a valid (and very nice) multistage Dockerfile. You can now build your image with the following command:

    docker build . -t gcr.io/buffalo/buffalo-app:v1.0.0

    Notice that you added -t gcr.io/buffalo/buffalo-app, which is:

    • gcr.io (base for GCR)
    • buffalo is the project name
    • buffalo-app is the name of the image you’re sending to GCR
    • v1.0.0 is the tag you’re using for that image

    This will build your image and tag it locally.

    Pushing container image

    Given you’ve already set permissions on the GCR docker repo you can now just push the container image there with the following command:

    docker push gcr.io/buffalo/buffalo-app:v1.0.0

    That will take the container image from your local docker repo and push it to GCR. By the time I’m writing this, Cloud Run doesn’t support images from other repositories apart from GCR.

    Creating and running service

    Once you have your image pushed to GCR you can tell Cloud Run to run your app with the following command. It will take care of service creation and deployment.

    gcloud beta run deploy buffalo-app --region us-central1 --platform managed --allow-unauthenticated --image gcr.io/buffalo/buffalo-app:v1.0.0 

    With this you’re telling gcloud tool:

    • To deploy a service called buffalo-app
    • To deploy it in the us-central1 region
    • To deploy it in a managed (full serverless) way
    • To allow unauthenticated access to it
    • With the image tag (gcr.io/buffalo/buffalo-app:v1.0.0) that will be pushed to GCR

    After this command has completed you will get a message saying:

    Service [buffalo-app] revision [buffalo-app-00001] has been deployed and is serving traffic at https://blog-5zw4ak7zjq-uc.a.run.app.

    Which is our signal that the deployment has been completed. That’s all, Your app is running in Google Cloud Run.

    Wrapping up

    I have to admit that as you may have noticed this post is more about Google Cloud Run than Buffalo, but I’m mostly doing Buffalo lately. I named this post “Deploying Buffalo to Google Cloud Run” with the hope that in the future I could continue sharing those lessons. My team and I are learning about Buffalo on Google Cloud Run for now; all I can tell is we’re loving that mix.

    Thanks for reading until here! If you have questions or comments about this post, you can find me on twitter at @paganotoni, or find my company there at @wawandco, I would love to hear your opinions on this and other posts.

    Continue Reading
  • Antonio Pagano on August 16, 2019

    Deploying a Buffalo app to Heroku

    A lot of things have changed in the Buffalo ecosystem since my last post on how to deploy to Heroku from Gitlab.

    Indeed, everything has changed since I posted how to deploy from gitlab repo into Heroku with the birth of the buffalo-heroku plugin. In this post I will try and describe how to use it to deploy your buffalo app to Heroku.


    First thing you need to install (or ensure you have) is buffalo-plugins plugin. If you’re on buffalo v0.14.6 or higher you’re all set. If you’re on an older version you should:

    1. Move to your project root folder
    2. Download and install buffalo-plugins plugin
    $ GO111MODULE=off go get -u github.com/gobuffalo/buffalo-plugins
    1. Init your application plugins (just in case):
    $ buffalo plugins init

    You may notice that a config folder has been added to your codebase, this will hold plugin information for your app.

    Installing buffalo-heroku plugin

    Then you will need to install buffalo-heroku plugin which (assuming you’re still in your application root folder) you can do by:

    $ buffalo plugins add github.com/gobuffalo/buffalo-heroku

    Once that passes successfully we’re all set to start deploying your app. You can check if your installation is ok by running:

    $ buffalo heroku -h


    Buffalo-heroku plugin provides very cool commands that I invite you to take a look at, for now I will concentrate in the details for you to deploy that app.

    Deployment Configuration

    Buffalo-Heroku uses some files in your repo to deploy your app, to create those files you should run:

    $ buffalo heroku config

    This will update your project with configuration files for deployment:

    1. Will create a heroku.yml file.
    2. Will ensure you have a Dockerfile (Will create it for you if you don’t have it)
    Creating the Heroku app

    One of the coolest commands in the buffalo-heroku plugin is the new command, it allows you to create new apps with a bunch of configuration options.

    We will create your app by running:

    $ buffalo heroku new -a name-of-your-app

    Once the app is created this will do your first deployment.

    Deploying Again

    Now that your app is all set with Heroku, you should be able to deploy your app at any time you need by just running:

    $ buffalo heroku deploy

    Very simple right? Now that you’ve set up your app and deployed you can get back to what we all love. Building actual apps with Go and Buffalo :).

    Recommended Reading
    • More on heroku.yml file
    • Buffalo plugins and plugin system (in the Buffalo repo)
    • Buffalo documentation

    Thanks for reading until here. If you’re interested in application development, my company Wawandco can help you building quality web and mobile applications. You can check what we have been up to in our dribbble posts, our Twitter or LinkedIn profiles. Stay tuned.

    Continue Reading
  • Antonio Pagano on July 14, 2019

    Page indicator with Buffalo

    Buffalo already ships with very cool pagination support, more than that it even uses the pagination when we generate resources, which is awesome.

    I’ve been working lately in a project that uses that pagination (again thanks to the buffalo team), but this app also has a page indicator on the left side, as the following image shows:

    Yes, i’m talking about the section that says “Displaying 1 - 25 of 120 Policies” (design typo there).

    So my first thought was computing those variables on the action and then passing these to the view, where i would use them to build my “page indicator” section.

    My action was turning very ugly, until i realized most (not to say all) that i needed was already contained in the pagination context variable set in my action:

    q := tx.PaginateFromParams(c.Params())
    c.Set("pagination", q.Paginator)

    Which is an instance of pops paginator! wow! i already had:

    • Page
    • PerPage
    • Offset
    • TotalEntriesSize
    • CurrentEntriesSize

    With that in hand building my page indicator was not very hard, but wanted to share my _page-indicator.html partial just so if anyone needs to do something similar this could be a good starting point.

    <div class="pagination-label">
        <span class="opacity">Displaying <%= pagination.Offset + 1 %> - <%= pagination.Offset + pagination.CurrentEntriesSize %> of <%= pagination.TotalEntriesSize %> <%= plural %></span> 
        <i class="per-page-separator">|</i>
        <span class="per-page-<%= perPage(per_page) %>">
            <a href="<%= basePath %>?per_page=25"><i class="opacity per-page-25-number per-page-option">25</i></a> 
            <a href="<%= basePath %>?per_page=50"><i class="opacity per-page-50-number per-page-option">50</i></a> 
            <a href="<%= basePath %>?per_page=100"><i class="opacity per-page-100-number per-page-option"> 100</i></a>
            <i class="opacity"><%= plural %> per page.</i>

    The way i use this partial from my table templates is:

    <%= partial("partials/page-indicator.html", {plural: "Cats", basePath: catsPath({humanSlug: currentHuman.Slug})}) %>

    As i’ve said it was very easy with the help of the Paginator that the Buffalo team created for us, hope this helps you if you’re needing to create a page indicator in your app.

    Continue Reading
  • Antonio Pagano on October 9, 2015

    Golang on CircleCI

    As some of you may know, our team has been working with Go for some time and we have always been using CircleCI to run our test suites, we would like to share our circle.yml file, it would help for your Go projects.



    Continue Reading
  • Manuel Perez on July 30, 2015

    A Happy Path To CSM

    Since I joined to the company and during the implementation of projects in which I participated, I have conducted a serie of activities for the management of those projects, activities and daily meetings, monthly, retrospectives among others, all this because in our company uses Scrum as a framework for managing our projects. Deepening about Scrum, it woke up in my desire to learn and perform the activities of a ScrumMaster.

    Sponsored by our company on March 2 of this year I traveled to Bogota along with two co-workers, Bryan and Jessica, for the ScrumMaster certification course, the course lasted two great days, and while is true that we get to the course with a lot of practical knowledge about the Scrum/Agile world, Kleer (the company who conducted the course) used every possible tool to establish these concepts and secure them in a dynamic and practice way.

    That was the most exciting part of the course, and where I was putting my expectations, because during flight to the CSM many times I wondered if it was possible, I mean, to prepare a group of people to perform activities of a ScrumMaster in two days. It was great to notice how with the passing of activities we were gradually increasing most knowledges about Scrum and the role of ScrumMaster and that was gaining sense why those meetings and activities that as company member we have done in each of our projects.

    After completing the course Bryan, Jessica and I have been sharing our fresh ideas and experience with our team through presentations, that in order to put in practice what we have learned and also we wanted to get feedback from our own knowledge, at the end we answered some doubts that any of them could probably have.

    • Why do we perform these activities?
    • Why there is a daily meeting where we talked about the worked of the last day?
    • Whose depend certain activities?
    • Who to turn when a problem occurs?

    Our goal as ScrumMaster when resolving these doubts beside finishing with them, it was to improve the self-management of members team that finally ends up guaranteeing better quality and value for our clients as well as the growth of ourselves as a professionals.

    Ultimately my participation in the CSM was a great experience, I had the opportunity to interact with people from different professions and countries and provide feedback of knowledge, I met places of the city of Bogota where the course was held during free time and achieve one of the course objectives that it was get the ScrumMaster certification.

    Continue Reading