Forem: Alireza Bashiri

Service Objects with ActiveModel and SimpleDelegator

Alireza Bashiri — Thu, 09 Apr 2020 18:29:50 +0000

One of the worst practices in Ruby On Rails is to clutter the Gemfile to do
basics as authentication, authorization, validation, etc. considering the
fact that they are practiced for so long and they can be accomplished using just
the batteries already included in Ruby On Rails; service objects are no
different for which developers often end up using different gems to do such a
simple pattern.

In the favour of simplicity and the fact that I never trust dependencies due to
to the complexity they bring in I've been using ActiveModel and
SimpleDelegator to apply service objects through a consistent interface
across the controllers as well as avoiding dependency clutter and here's the results.

Login case

Let's consider a user logging in use case;

> Users can login with password and email
> Users cannot login with wrong password / email

So we have 2 cases which we have to cover in our implementation to do that I
use ActiveModel::Validations to validate the parameters I receive from the
controller and using save method to keep interface consistency.

class Login
  include ActiveModel::Model

  attr_accessor :email, :password, :user
  validates :email, presence: true
  validates :password, presence: true
  validates :user, presence: {message: "email or password is wrong"}

  def initialize(params)
    super(params.require(:user).permit(:email, :password))
    @user = User.find_by(email: email, status: :active)&.authenticate(password)
  end

  def save
    return if invalid?
    # This will generate and refresh user's token and return it
    Tokenizer.generate_and_refresh!(@user)
  end
end

Here if no user found it will set @user variable to nil and user presence
validation will handle the error which keep us from writing an error handling
part except a message.

And the controller would be like;

class LoginController < ApplicationController
  skip_before_action :authenticate
  INCLUDED = %i[positions]

  def create
    login = Login.new(params)

    if (user = login.save)
      render json: user, include: INCLUDED
    else
      render json: login, status: :bad_request
    end
  end

  private

  def serializer
    UserSerializer
  end

  def user_params
    params.require(:user).permit(:email, :password)
  end
end

This is already battle-tested in production and it works like a charm.

Approval flow

Let's consider a use case that your flow needs to go through multiple approvals
and each approval stage has its own validations and business logic. There are a
lot of ways to handle this;

`ActiveRecord` callbacks

It may seem simple solution but you have to write tons of conditions to avoid
conflict between different use cases and hard to debug.

Contextual validations with `on: :context`

This works just fine but it'll clutter your models with a lot of business logic
which it needs to somewhere else and it's hard to test and modify due to
it's coupled with your model. e.g.

validate :order_is_picked_before_packing, on: :packing

Decorators + State machines

State machines needs to be force-feed to developers as they make handling data
logic so convenient but to provide a good interface for your controllers you
cannot treat state machine transitions or guard errors as you best bet you
still need something in-between which in this case is a decorator which give
you best of both worlds validations, callbacks, separation of concern, ease
of testing and etc. In our case we need some conditions are met before going to
another state so the uses cases are;

> MVPs cannot be approved before they're submitted
> MVPs cannot be approved more than once by same user
> MVPs cannot be approved unless they have enough approvals from different users

Let's take look at the code;

class ApprovedMvp < SimpleDelegator
  include ActiveModel::Validations

  def save(user)
    return unless valid?

    if in_state?(:draft)
      errors.add(:minimal_viable_product, "it should be submitted first")
      return
    end

    if approvals.find_by(user: user)
      errors.add(:minimal_viable_product, "already been approved by user")
      return
    else
      approvals.create!(user: user)
    end

    if has_enough_approvals?
      transition_to!(:approved)
    else
      super()
    end
  end
end

Here we populate a decorated MVP with contextual errors and pass it up to the controller

class UseCases::MinimalViableProductsController < ApplicationController
  INCLUDED = UseCasesController::INCLUDED

  include UseCaseScoped

  def approve
    result = ApprovedMvp.new(minimal_viable_product)

    if result.save(@current_user)
      render json: result.use_case, include: INCLUDED
    else
      render json: result
    end
  end

In which will be handled by a ErrorSerializer and a concern called
ActsAsJSONAPI which I've written to handle different cases of serialization and
error handling without dependencies and a lot of complexity which you can
checkout here.

Conclusion

Codes that are written 50 years ago with zero-dependencies are working fine
today and the ones are written today with dependencies may not work tomorrow :)

And don't get me wrong I don't mean to reinvent the wheel but don't be afraid
to build your own tool since each app has different needs and not all
gems/libraries are going to fit yours. Bad cases that you should never
implement by yourself except for practice is encryption or an premature abstraction
(framework, etc) that's takes your more than 1 day or 2.

I hope you've enjoyed it

Feel free to checkout my personal blog here
https://blog.alirezabashiri.com/

Tired of json-schema, try dry-validation

Alireza Bashiri — Fri, 21 Sep 2018 05:56:46 +0000

Why you should use dry-validation over json-schema?

You working with JSON responses coming from APIs and you want to validate their schemas? What’s your first choice? Probably you go with the great way that Thoughtbot guys explained in this article. I’ve launched and tested various projects based on that technique but I always felt I’m doing something wrong because the process was so painful. Let me explain; If you want to validate a JSON response first you should create a JSON schema based on it then you’d write your test and get some errors because of a comma/double quotation being missed.

An example of the old way of testing JSON responses. First, define the JSON schema:


{
  "type": "object",
  "required": ["user"],
  "properties": {
    "user" : {
      "type" : "object",
      "required" : [
        "id",
        "token",
        "token_expired_at",
        "email",
        "firstname",
        "lastname",
        "gender",
        "phone_number",
        "birthday"
      ],
      "properties" : {
        "id" : { "type" : "integer" },
        "token" : { "type" : "string" },
        "token_expired_at" : { "type" : "string" },
        "email" : { "type" : "string" },
        "lastname" : { "type" : "string" },
        "firstname" : { "type" : "string" },
        "gender" : { "type" : "string" },
        "phone_number" : { "type" : "string" },
        "brithday" : { "type" : "string", "format": "date-time" },
        "updated_at" : { "type" : "string", "format": "date-time" },
        "created_at" : { "type" : "string", "format": "date-time" },
      }
    }
  }
}

Then write your test

describe "Sign in" do
  context "anonymous user" do
    it "returns data in the specified format" do
      sign_in_as_anonymous

      expect(response).to match_response_schema("users/anonymous_detail")
    end
  end
end

Not speaking of bad errors, you have to switch to JSON schema syntax and Ruby over and over again (context switching) and there you are you’ve lost your time and focus. Now I’m going to show you a better way to validate your mighty JSON with ease.

Creating the custom matcher

# Gemfile
group :test do
  gem "dry-validation"
end

# spec/support/matchers/match_schema.rb
RSpec::Matchers.define :match_schema do |schema|
  match do |response|
    @result = schema.call(JSON.parse(response.body, symbolize_names: true))
    @result.success?
  end

  def failure_message
    @result.errors
  end
end

Note: Here I’ve chosen /spec/support/matchers/* for my custom matchers with a name convention of match_*. Also in schema.call schema is a dry-validation class and call initializes the schema class with the given parameters then I return the result of validation which is a true/false value. I’ve even defined failure_message to be able to see the errors that have been generated from validating the schema inside Rspec result.

Defining the anonymous user schema

Add this to your spec/rails_helper.rb

require "support/views/schemas"

Now defining anonymous user schema:

AnonymousUserSchema = Dry::Validation.Schema do
  required(:user).schema do
    required(:email)
    required(:token).filled
    required(:token_expired_at).filled
    required(:firstname)
    required(:lastname)
    required(:gender)
    required(:phone_number)
    required(:birthday)
  end
end

Now you can change your spec to this:

describe "Sign in" do
  context "anonymous user" do
    it "returns data in the specified format" do
      sign_in_as_anonymous

      expect(response).to match_schema(AnonymousUserSchema)
    end
  end
end

There you go! What if when I added a new field? You just add the field with the needed condition to end of the block.

AnonymousUserSchema = Dry::Validation.Schema do
  required(:user).schema do
    required(:email)
    required(:token).filled
    required(:token_expired_at).filled
    required(:firstname)
    required(:lastname)
    required(:gender)
    required(:phone_number)
    required(:birthday)
    required(:age).maybe(int?)
  end
end

With dry-validation you can do pretty much everything. For further information please check out the link down below.

http://dry-rb.org/gems/dry-validation/

I hope you have enjoyed :D

Building a finance tracking REST API using Go with TDD - Part 2

Alireza Bashiri — Mon, 17 Sep 2018 20:21:51 +0000

Hola amigos! In this part we're going to complete budgets API, also I'm going to tell you in recent days I've come up with a great combination of tools to build REST APIs much more MVC-like than this that I'm going to write about in incoming posts.

I've just finished with just one single acceptance test for budgets API but here I going to declare various test cases should cover almost 100% of budgets API behaviors. So let's get started:

// budgets_test.go
package main

import (
    "net/http"
    "os"
    "testing"

    "github.com/azbshiri/common/test"
    "github.com/go-pg/pg"
    "github.com/go-pg/pg/orm"
    "github.com/gorilla/mux"
    "github.com/pquerna/ffjson/ffjson"
    "github.com/stretchr/testify/assert"
)

var testServer *server
var badServer *server

func TestMain(m *testing.M) {
    testServer = newServer(
        pg.Connect(&pg.Options{
            User:     "alireza",
            Password: "alireza",
            Database: "alireza_test",
        }),
        mux.NewRouter(),
    )

    badServer = newServer(
        pg.Connect(&pg.Options{
            User:     "not_found",
            Password: "alireza",
            Database: "alireza",
        }),
        mux.NewRouter(),
    )

        // Here we create a temporary table to store each test case
        // data and follow isolation which would be dropped after.
    testServer.db.CreateTable(&budget{}, &orm.CreateTableOptions{
        Temp: true,
    })

    os.Exit(m.Run())
}

func TestGetBudgets_EmptyResponse(t *testing.T) {
    var body []budget
    res, err := test.DoRequest(testServer, "GET", BudgetPath, nil)

    ffjson.NewDecoder().DecodeReader(res.Body, &body)
    assert.NoError(t, err)
    assert.Len(t, body, 0)
    assert.Equal(t, res.Code, http.StatusOK)
}

func TestGetBudgets_NormalResponse(t *testing.T) {
    var body []budget
    budgets, err := CreateBudgetListFactory(testServer.db, 10)
    assert.NoError(t, err)

    res, err := test.DoRequest(testServer, "GET", BudgetPath, nil)
    assert.Equal(t, http.StatusOK, res.Code)
    assert.NoError(t, err)

    ffjson.NewDecoder().DecodeReader(res.Body, &body)
    assert.Len(t, body, 10)
    assert.Equal(t, budgets, &body)
}

func TestGetBudgets_DatabaseError(t *testing.T) {
    var body Error
    res, err := test.DoRequest(badServer, "GET", BudgetPath, nil)

    ffjson.NewDecoder().DecodeReader(res.Body, &body)
    assert.NoError(t, err)
    assert.Equal(t, DatabaseError, &body)
    assert.Equal(t, http.StatusInternalServerError, res.Code)
}

I've defined three test cases normal response, empty response and when there's a database error that we've simulated using a non-existing database username to make database unavailable. Also as you noticed there's a DatabaseError constant which assert to make sure errors are readable. I've created a errors.go file in which there are a new error type called Error as below:

package main

import "net/http"

type Error struct {
    Message string `json:"message"`
    Status  int    `json:"status"`
}

func Err(message string, status int) *Error {
    return &Error{message, status}
}

var DatabaseError = Err("Your request failed due to a database error.", http.StatusInternalServerError)

It carries a message and a corresponding HTTP code to make dealing with errors easier. Now that everything is in a right place we should pass or tests which are failing in the current state.

So first we go by creating an HTTP handler function in budgets.go file:

// budgets.go
package main

import (
    "net/http"

    "github.com/azbshiri/common/db"
)

type budget struct {
    db.Model
    Amount float64 `json:"amount"`
}

func (s *server) getBudgets(w http.ResponseWriter, r *http.Request) {
}

Then registering the HTTP handle in routes.go:

// routes.go
package main

const BudgetPath = "/api/budgets"

func (s *server) routes() {
    s.mux.HandleFunc(BudgetPath, s.getBudgets).Methods("GET")
}

Note: I defined BudgetPath constant to be able to use budgets API path in various places including tests. Tests are still failing so we should get budgets from the database and return an acceptable response to consumers. Also, I created a CreateBudgetListFactory factory in factories.go file to making database population easier.

// factories.go
package main

import (
    "math/rand"
    "time"

    "github.com/go-pg/pg"
)

func CreateBudgetListFactory(db *pg.DB, length int) (*[]budget, error) {
    budgets := make([]budget, length)
    for _, budget := range budgets {
        budget.Amount = rand.Float64()
        budget.CreatedAt = time.Now()
    }

    err := db.Insert(&budgets)
    if err != nil {
        return nil, err
    }

    return &budgets, nil
}

// budgets.go
package main

import (
    "encoding/json"
    "net/http"

    "github.com/azbshiri/common/db"
    "github.com/pquerna/ffjson/ffjson"
)

type budget struct {
    db.Model
    Amount float64 `json:"amount"`
}

func (s *server) getBudgets(w http.ResponseWriter, r *http.Request) {
    var budgets []*budget
    err := s.db.Model(&budgets).Select()
    if err != nil {
        w.WriteHeader(http.StatusInternalServerError)
        json.NewEncoder(w).Encode(DatabaseError)
        return
    }

    ffjson.NewEncoder(w).Encode(budgets)
}

Now we're green:

=== RUN   TestGetBudgets_EmptyResponse
-------- PASS: TestGetBudgets_EmptyResponse (0.00s)
=== RUN   TestGetBudgets_NormalResponse
-------- PASS: TestGetBudgets_NormalResponse (0.00s)
=== RUN   TestGetBudgets_DatabaseError
-------- PASS: TestGetBudgets_DatabaseError (0.00s)
PASS
ok      github.com/azbshiri/budget-api  0.040s

Okay, now we repeating the same steps for creating a new budget API:

// budgets_test.go
package main

import (
    "bytes"
    "net/http"
    "os"
    "testing"

    "github.com/azbshiri/common/test"
    "github.com/go-pg/pg"
    "github.com/go-pg/pg/orm"
    "github.com/gorilla/mux"
    "github.com/pquerna/ffjson/ffjson"
    "github.com/stretchr/testify/assert"
)

var testServer *server
var badServer *server

func TestMain(m *testing.M) {
    testServer = newServer(
        pg.Connect(&pg.Options{
            User:     "alireza",
            Password: "alireza",
            Database: "alireza_test",
        }),
        mux.NewRouter(),
    )

    badServer = newServer(
        pg.Connect(&pg.Options{
            User:     "not_found",
            Password: "alireza",
            Database: "alireza",
        }),
        mux.NewRouter(),
    )

    testServer.db.CreateTable(&budget{}, &orm.CreateTableOptions{
        Temp: true,
    })

    os.Exit(m.Run())
}

func TestGetBudgets_EmptyResponse(t *testing.T) {
    var body []budget
    res, err := test.DoRequest(testServer, "GET", BudgetPath, nil)

    ffjson.NewDecoder().DecodeReader(res.Body, &body)
    assert.NoError(t, err)
    assert.Len(t, body, 0)
    assert.Equal(t, res.Code, http.StatusOK)
}

func TestGetBudgets_NormalResponse(t *testing.T) {
    var body []budget
    budgets, err := CreateBudgetListFactory(testServer.db, 10)
    assert.NoError(t, err)

    res, err := test.DoRequest(testServer, "GET", BudgetPath, nil)
    assert.Equal(t, http.StatusOK, res.Code)
    assert.NoError(t, err)

    ffjson.NewDecoder().DecodeReader(res.Body, &body)
    assert.Len(t, body, 10)
    assert.Equal(t, budgets, &body)
}

func TestGetBudgets_DatabaseError(t *testing.T) {
    var body Error
    res, err := test.DoRequest(badServer, "GET", BudgetPath, nil)

    ffjson.NewDecoder().DecodeReader(res.Body, &body)
    assert.NoError(t, err)
    assert.Equal(t, DatabaseError, &body)
    assert.Equal(t, http.StatusInternalServerError, res.Code)
}

func TestCreateBudget(t *testing.T) {
    var body budget
    byt, err := ffjson.Marshal(&budget{Amount: 1000.4})
    rdr := bytes.NewReader(byt)

    res, err := test.DoRequest(testServer, "POST", BudgetPath, rdr)

    ffjson.NewDecoder().DecodeReader(res.Body, &body)
    assert.NoError(t, err)
    assert.Equal(t, 1000.4, body.Amount)
    assert.Equal(t, http.StatusOK, res.Code)
}

func TestCreateBudget_BadParamError(t *testing.T) {
    var body Error
    res, err := test.DoRequest(testServer, "POST", BudgetPath,
        bytes.NewReader([]byte{}))

    ffjson.NewDecoder().DecodeReader(res.Body, &body)
    assert.NoError(t, err)
    assert.Equal(t, BadParamError, &body)
    assert.Equal(t, http.StatusBadRequest, res.Code)
}

func TestCreateBudget_DatabaseError(t *testing.T) {
    var body Error
    byt, err := ffjson.Marshal(&budget{Amount: 1000.4})
    rdr := bytes.NewReader(byt)

    res, err := test.DoRequest(badServer, "POST", BudgetPath, rdr)

    ffjson.NewDecoder().DecodeReader(res.Body, &body)
    assert.NoError(t, err)
    assert.Equal(t, DatabaseError, &body)
    assert.Equal(t, http.StatusInternalServerError, res.Code)
}

Creating a new HTTP handle function for new API:

// budgets.go
package main

import (
    "encoding/json"
    "net/http"

    "github.com/azbshiri/common/db"
    "github.com/pquerna/ffjson/ffjson"
)

type budget struct {
    db.Model
    Amount float64 `json:"amount"`
}

func (s *server) getBudgets(w http.ResponseWriter, r *http.Request) {
    var budgets []*budget
    err := s.db.Model(&budgets).Select()
    if err != nil {
        w.WriteHeader(http.StatusInternalServerError)
        json.NewEncoder(w).Encode(DatabaseError)
        return
    }

    ffjson.NewEncoder(w).Encode(budgets)
}

func (s *server) createBudget(w http.ResponseWriter, r *http.Request) {
    var param struct {
        Amount float64 `json:"amount"`
    }
    err := ffjson.NewDecoder().DecodeReader(r.Body, &param)
    if err != nil {
        w.WriteHeader(http.StatusBadRequest)
        json.NewEncoder(w).Encode(BadParamError)
        return
    }

    budget := budget{Amount: param.Amount}
    err = s.db.Insert(&budget)
    if err != nil {
        w.WriteHeader(http.StatusInternalServerError)
        json.NewEncoder(w).Encode(DatabaseError)
        return
    }

    ffjson.NewEncoder(w).Encode(budget)
}

Note: I used DTO concept to decode parameters that sent to budget creation API, which is a great way to do so.

And we're done:

=== RUN   TestGetBudgets_EmptyResponse
-------- PASS: TestGetBudgets_EmptyResponse (0.01s)
=== RUN   TestGetBudgets_NormalResponse
-------- PASS: TestGetBudgets_NormalResponse (0.00s)
=== RUN   TestGetBudgets_DatabaseError
-------- PASS: TestGetBudgets_DatabaseError (0.00s)
=== RUN   TestCreateBudget
-------- PASS: TestCreateBudget (0.00s)
=== RUN   TestCreateBudget_BadParamError
-------- PASS: TestCreateBudget_BadParamError (0.00s)
=== RUN   TestCreateBudget_DatabaseError
-------- PASS: TestCreateBudget_DatabaseError (0.00s)
PASS
ok      github.com/azbshiri/budget-api  (cached)

Please add your comments down below and if you found this informative don't forget to drop a heart for me :D

Building a finance tracking REST API using Go with TDD - Part 1

Alireza Bashiri — Sat, 08 Sep 2018 11:34:43 +0000

Building a simple REST API using Go always could be challenging from designing the architecture to implement it 'cause there's no standard way to do it and developers (software architectures) are free to do whatever they want which comes with a cost.

After almost 6 years of building services and REST APIs using RubyOnRails, I realized that developers have a passion for abstraction but that's not always a good choice. For example; If you look at almost every RubyOnRails projects there's too much abstraction and implicit things going on which makes the learning curve far more of a curve, starting pretty shallow.

Today I'm going to show you a different perspective of designing REST APIs with Go which like a good parent instead of allowing us to do anything teaches to practice, patience, and perseverance.

Let's get started, at first every Go project must be created in $GOPATH. My $GOPATH is at, ~~~/go/src/~~ ~/go/ . But we're going to create the project under ~/go/src/github.com/budget-api be able to download the project using go get.

So we're going to run these commands, in CLI.

cd ~/go/src/github.com/azbshiri
mkdir budget-api
touch main.go

(If you don't have github.com/username, you would create it using mkdir -p github.com/username after changing the directory to ~/go/src/)

Okay, we're going to use PostgreSQL as our database and Gorilla toolkit to help us build a RESTful API. For now, we just need github.com/go-pg/pg to be able to connect to PostgreSQL and github.com/gorilla/mux for routing.

go get github.com/go-pg/pg
go get github.com/gorilla/mux

Alright now that we have the prerequisites, we should think how we're going to use them and design the architecture.

I'm going to use a struct as a container for controller/handler actions called server to be able to access database, router and etc. So I create a new file called server.go and put the declaration in it.

// server.go
package main

type server struct {
    db *pg.DB
    mux *mux.Router
}

And create a factory function to initialize a new server (that would help in testing which I'll show in the future)

// server.go
package main


type server struct {
    db *pg.DB
    mux *mux.Router
}

func newServer(db *pg.DB, mux *mux.Router) *server {
    s := server{db, mux}
    s.routes() // register handlers
    return &s
}

We need a routes.go to declare paths for APIs

// routes.go
func (s *server) routes() {
    // register handlers here
}

Now we have a file hierarchy like the below

.
├── main.go
├── rotues.go
└── server.go

To be able to run the server we should implement http.Handler interface so we add a new pointer function to server called ServeHTTP and serve registered handlers in the router (mux)

// server.go
package main

import (
    "net/http"

    "github.com/go-pg/pg"
    "github.com/gorilla/mux"
)

type server struct {
    db     *pg.DB
    mux    *mux.Router
}

func newServer(db *pg.DB, mux *mux.Router) *server {
    server := server{db, mux}
    server.routes() // register handlers
    return &server
}

func (s *server) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    s.mux.ServeHTTP(w, r)
}

Now we can update the main.go file to run the server

package main

import (
    "net/http"

    "github.com/go-pg/pg"
    "github.com/gorilla/mux"
)

func main() {
    db := pg.Connect(&pg.Options{
        User:     "alireza",
        Password: "alireza",
    })

    mux := mux.NewRouter()
    server := newServer(db, mux)
    http.ListenAndServe(":8080", server)
}

At this point, we don't have any registered handlers which would lead to an API so we have just a useless running server but we have the standard, to begin with which is a great thing to speed up the development process.

Due to I'm a TDD guru, so let's just begin with a test to write our first API. As you know we're going to build a finance tracking REST API so we're going to have Budget business model and call the API endpoint /budgets.

// budgets_test.go
package main

import (
    "net/http"
    "os"
    "testing"

    "github.com/azbshiri/common/test"
    "github.com/go-pg/pg"
    "github.com/gorilla/mux"
    "github.com/stretchr/testify/assert"
)

var testServer *server

func TestMain(m *testing.M) {
    testServer = newServer(
        pg.Connect(&pg.Options{
            User:     "alireza",
            Password: "alireza",
            Database: "alireza",
        }),
        mux.NewRouter(),
    )
    os.Exit(m.Run())
}

func TestGetBudgets(t *testing.T) {
    res, err := test.DoRequest(testServer, "GET", "/budgets", nil)
    assert.NoError(t, err)
    assert.Equal(t, res.Code, http.StatusOK)
}

To write the above test we used two libraries github.com/stretchr/testify/assert and github.com/azbshiri/common/test the first one is for making assertion easier and the second one is a little bit complicated which I built myself to reduce duplication of initializing of a http.Request and a httptest.ResponseRecorder and pass them to the existing router to be able to capture the response (That's normal way of writing integration tests in Go for further information you can check out https://golang.org/src/net/http/httptest/example_test.go).

Run the test

go test -v .
=== RUN   TestGetBudgets
-------- FAIL: TestGetBudgets (0.00s)
        budgets_test.go:42:
                        Error Trace:    budgets_test.go:42
                        Error:          Not equal:
                                        expected: 404
                                        actual  : 200
                        Test:           TestGetBudgets
FAIL
exit status 1
FAIL    github.com/azbshiri/budget-api  0.018s

shell returned 1

Phew! The plan was to cover everything in a single post but honestly this is getting longer than anticipated so kindly permit me to break this into a series of posts.

Once again, thanks for reading and don’t forget to leave your questions and/or suggestions as comments below.

Command as a service

Alireza Bashiri — Tue, 01 May 2018 12:05:27 +0000

Did you hear about FaaS? Now you can run shell commands as RESTful services (CaaS) with just a command and an endpoint.

https://github.com/cooldrip/comando

🏎Create fake REST API in one sec (written in Go)

Alireza Bashiri — Sun, 29 Apr 2018 17:27:03 +0000

Do you ever wanted to create a REST API with just a JSON file? I think so, and there are many tools to that but not written in Go :D so give jhop a try and have fun.

https://github.com/cooldrip/jhop

⌛️The missing strftime in Go

Alireza Bashiri — Wed, 25 Apr 2018 10:50:45 +0000

Last night I was reading time package documentation but I couldn't find strftime implementation so I did a little bit of research and I did find out that there's no such thing as strftime in Go time package.

Story short I couldn't find anything close to strftime even in third-party packages then I decided to implement it using cgo without magic and there's it is 🎉, it supports all the standard directives in strftime manual page.

https://github.com/cooldrip/cstrftime

Go already has RSpec!

Alireza Bashiri — Sat, 31 Mar 2018 03:24:50 +0000

You can use (*testing.T).Run(string, func(t *testing.T)) to run each test case in isolation and also is more readable than table driven approach.

import (
    "testing"
    "github.com/stretchr/testify/assert"
)

func TestRateRecipe(t *testing.T) {
    t.Run("ok", func(t *testing.T) {
        res := post("/recipes/1/rating", nil)
        assert.Equal(t, res.Code, http.StatusOK)
    })

    t.Run("id is invalid", func(t *testing.T) {
        res := post("/recipes/foo/rating", nil)
        assert.Equal(t, res.Code, http.StatusBadRequest)
    })
}