Our Blog.

Expert thoughts from our software developers and design leaders.

  • Antonio Pagano on September 28, 2019

    Custom Web Fonts in Buffalo

    In certain situations the site or app you’re building uses fonts that are not hosted in a CDN. The font is not in Google fonts, and is not in Adobe Fonts or other provider.

    You may be given at that point a set of OTF, TTF and WOFF files. But what do do then? How do you integrate those font files in your Buffalo app?. After all, you want your frontend to look as closer to what your designer has put together, And we all know that fonts matter.

    What to do?

    Assuming you are in your Buffalo app folder, take a look at the assets sub-folder.

    - assets
      > css
      > images
      > js

    Nothing there says fonts, right?.

    Brief context on the buffalo assets build process

    Buffalo bases its assets build in Webpack. It compiles Javascript using Webpack tools like Babel, and processes the SASS/SCSS using node-sass.

    That leaves images alone, Right?

    Images are copied into the public/assets/images folder. And like this, all other folders or files that are not CSS or Javascript get copied to the public/assets folder.

    At build time, the public folder is filled with the results of the assets compilation and then is packed into the app binary, with Packr. But Packr is a whole complete (and long) separate topic.

    Our solution

    Now that we know how files in the assets folder are processed and packed into the binary, you may know what’s coming up.

    We need to create another folder called fonts inside the assets one.

    - assets
      > css
      - fonts // Like this!
        * myFont.woff
        * myFont.ttf
        * myFont.otf
      > images
      > js

    But that’s not all. Until this we’ve only ensured that the fonts make it to our binary.

    Now we need to make sure our fonts make it to our CSS. What we typically do is we create a file called: _fonts.scss. In there, you can add your font definitions, like the following:

    @font-face {
      font-family: "My Custom Font";
      font-style: normal;
      font-weight: 300;
      src: local("My Custom Font"), 
           url("/assets/fonts/myFont.woff") format("woff");

    This will ensure that the app pulls your fonts from the assets folder, and finally will make your font available to be used in your app.

    Wrapping up

    With this brief post I shared a bit on how asset files are handled by Buffalo. I also showed a bit of the compilation details of the buffalo binary, and how to add custom fonts into your buffalo app.

    If you like this, don’t hesitate to share it. I would love to read/hear your opinions.

    Continue Reading
  • 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