DEV Community: Jacob Smith

Composing packages into applications?

Jacob Smith — Thu, 06 Aug 2020 20:49:37 +0000

Hi there! This is a question I recently posted to Reddit. I wanted to post it here as well in order to get even more insight :) .

I am a new Gopher coming from a more object oriented background (uh-oh! over complexity alert!). I have been really enjoying my time in Go so far, and I adore the simplicity. Something that I've been trying to understand is how to go about composing packages into an application (and if I'm overthinking it).

From what I've gathered so far, packages in Go should be organized by feature over function, and should be narrow in focus. That all makes sense to me, and its actually been a really natural process creating packages. What I can't quite figure out is the best way to compose those small individual packages, into a more complex application with business logic and cross cutting concerns. I also want to be clear, by cross cutting concerns I am not talking about things like logging. That seems to always be the default question on peoples minds when trying to understand relationships across domains.

Here's a (contrived) example of what I'm asking about.

I am creating a Go version of the cat-facts joke that circulated on Reddit years ago. Basically I want the ability to create and delete subscribers, and the ability to send a fact to all the subscribers.

I plan on having two binaries to accomplish this.

An API that exposes 2 endpoints. One for creating subscribers, and one for deleting subscribers.
A standalone binary that can be run via a cron job. It will get a list of subscribers from my data store, load a fact from an external api, and then loop through those subscribers sending the fact to each one.

In my mind this has broken into 3 packages.

subscribers
distribution
facts

I've included some sample code from each package below. The packages are all very narrow in focus and don't have much "business logic".

subscribers

Subscribers contains my subscriber model, as well as interfaces for reading, writing, listing and deleting subscribers. I also store implementations of those interfaces here.

package subscribers

type Contact = string

type Subscriber struct {
  Contact Contact
}

type SubscriberReader interface {
  Read(contact Contact) (*Subscriber, error)
}

type SubscriberWriter interface {
  Write(subscriber Subscriber) error
}

type SubscriberLister interface {
  List() ([]Subscriber, error)
}

type SubscriberDeleter interface {
  Delete(contact Contact) error
}

// implementations of interfaces...
// for instance, sqlite reader, writer, lister and deleter

distribution

Distribution contains the interface and implementation for sending things.

package distribution

type TextSender interface {
  SendText(to string, message string) error
}

// implementations of interfaces...
// for instance, twilio sender

facts

Facts contains my fact model and the interface and implementation for retrieving one.

package facts

type Fact = string

type FactRetriever interface {
  Retrieve() (Fact, error)
}

// implementations of interfaces...
// for instance, a retriever for the catfacts api

Like stated above, each of those packages are small and are good for actions in 1 domain. My confusion arises when I think about stitching those pieces together into an application.

Example 1 - Creating a Subscriber

When I create a subscriber I want to do 3 things.

Ensure a subscriber doesn't already exist with a particular Contact - I can utilize a subscribers.SubscriberReader
Write the subscriber to the data store - I can utilize a subscribers.SubscriberWriter
Send a welcome message to the subscriber - I can utilize a distribution.TextSender

func CreateSubscriber(
    reader subscribers.SubscriberReader,
    writer subscribers.SubscriberWriter,
    sender distribution.TextSender,
    subscriber subscribers.Subscriber) error {
    // error handling excluded for brevity...
    existing, _ := reader.Read(subscriber.Contact)

    if existing != nil {
        // error handling excluded for brevity...
    }

    // error handling excluded for brevity...
    _ := writer.Write(subscriber)

    // error handling excluded for brevity...
    _ := sender.SendText(subscriber.Contact, "Meow! Welcome to catfacts")

    return nil
}

In this example I want to execute logic that would cross boundaries. Because I want to perform actions from the subscribers package and the distribution package. I'm not sure where this code would live. It seems to me that this should not live in the subscribers package, because it is no longer just dealing with subscribers. Is there a common approach to this in Golang? A place where I would compose my business logic so to speak. Part of me feels like creating an additional application package that becomes the place where I compose all my functionality, but I'm not sure if that would be considered an anti-pattern.

Example 2 - Sending Facts

When I send facts I want to do 3 things.

Load the list of all subscribers
Load a random fact from a data source
Loop through the subscribers and send each one the fact

func SendFactToSubscribers(
    lister subscribers.SubscriberLister,
    retriever facts.FactRetriever,
    sender distribution.TextSender) error {
    // error handling excluded for brevity...
    subs, _ := lister.List()

    // error handling excluded for brevity...
    fact, _ := retriever.RetrieveFact()

    // error handling excluded for brevity...
    for _, subscriber := range subscribers {
        _ := sender.Send(subscriber.Contact, fact)
    }

    return nil
}

Again with this example I am executing logic that crosses domain boundaries. With this example I am also curious if I am "overloading" the function. Would someone with more Go experience than I write this function the same way? Or would it make more sense to break it down a bit. For instance pass in a []Subscriber as a parameter instead of an interface for listing them. If that's the case, then I would be back to trying to understand where to compose all the functionality together.

I am sure I am over complicating this. But part of the fun of learning a new language is learning all the best practices for that language. I love these types of design related challenges.

Any insight would be greatly appreciated!

Introduction to Azure Functions Pt. 5 - Automate the function deployment with a CI/CD pipeline

Jacob Smith — Mon, 11 Nov 2019 17:17:36 +0000

Introduction

In this post we will automate the deployment process of our Azure Function. We will setup a CI/CD process in Azure Devops that is run when we check into master. Next we will create a build pipeline that will build our entire solution and output an artifact for the function project. Finally we will create a release pipeline that will run automatically after the build succeeds and will take the build artifact and deploy it to our Function App.

Prerequisites

An Azure Devops account. Sign up for an account here. I am using the free tier.

Create an Azure Devops project

Login to the Azure Devops portal if you have not yet already.
Create a new Azure Devops project.
Under Project Name name your project Hello Azure.
Click on Create project.

Create a build pipeline

Login to the Azure Devops portal if you have not yet already.
Navigate to your Hello Azure project.
Click on Pipelines.
Click on Builds.
Click on New pipeline.
Under Connect select the source control provider your code is hosted under. In my case GitHub.
1. If you have not granted Azure Devops access to your GitHub account you will be redirected to a screen to grant access.
Under Select select your repository. In my case HelloAzure.
1. You will be redirected to a screen to grant Azure Devops access to your repository.
Under Configure select Starter Pipeline
Under Review modify the contents of azure-pipelines.yml to be the following.
```
trigger:
- master

pool:
  vmImage: 'ubuntu-latest'

steps:
- script: |
    dotnet restore
    dotnet build --configuration Release
- task: DotNetCoreCLI@2
  inputs:
    command: publish
    arguments: '--configuration Release --output publish_output'
    projects: 'HelloAzure.Functions/HelloAzure_Functions.csproj'
    publishWebProjects: false
    modifyOutputPath: false
    zipAfterPublish: false
- task: ArchiveFiles@2
  displayName: 'Archive files'
  inputs:
    rootFolderOrFile: "$(System.DefaultWorkingDirectory)/publish_output"
    includeRootFolder: false
    archiveFile: "$(System.DefaultWorkingDirectory)/build$(Build.BuildId).zip"
- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: "$(System.DefaultWorkingDirectory)/build$(Build.BuildId).zip"
    ArtifactName: "drop"
```
1. trigger lets the pipeline know what can trigger it. In this case a checkin to master.
2. pool is the environment we will run our build in.
3. steps are the build steps.
  1. The first step runs two command line commands
```
$ dotnet restore
$ dotnet build --configuration Release
```
    1. The first command restores any nuget packages our solution depends on.
    2. The second command will build the entire solution in release configuration.
  2. The second step uses the dotnet core CLI to run a publish command on the project.
    1. We specify the configuration to be Release and the output of the publish to go into a directory named publish_output.
    2. We specify the HelloAzure.Functions project as the one to publish.
    3. We set publishWebProjects to false to prevent the dotnet cli from throwing an exception while it looks for web projects.
    4. We set modifyOutputPath to false in order to keep the output directory flat. This will be an important piece to publishing.
      If modifyOutputPath is set to true we will get get a publish_output that looks like the following.
```
.
+-- publish_output/
|   +-- HelloAzure.Functions/
|       +-- ... published files
```
      We want an output that looks like the following.
```
.
+-- publish_output/
|   +-- ... published files
```
    5. We will be running a separate step to archive the publish_output directory so we set zipAfterPublishing to false.
  3. The third step uses the ArchiveFiles task to turn publish_output into an archive that has the name of the build.
  4. The last step uses the PublishBuildArtifacts task to publish the build artifacts archive in a spot that our release pipeline can look for it.
Once you are happy with the azure-pipeline.yml file click on Save and run
In the Save and run pane enter a commit message and choose a branch to commit the file to. In my case I just went with master.
1. This will add the azure-pipelines.yml file to the root of your repo and commit the change.
The build will now attempt to run.
1. If you get build failures verify that the branch you commited the azure-pipelines-yml file to is a branch that has your solution in it.

Create a release pipeline

Login to the Azure Devops portal if you have not yet already.
Navigate to your Hello Azure project.
Click on Pipelines.
Click on Releases.
Click on New pipeline.
In the Select a template pane select Or start with an Empty job.

Adding a Stage

The Stage pane will open after selecting Or start with an Empty job.
In the Stage pane under Stage name enter Dev.
Close the Stage pane.

Adding an Artifact

Click on Add an artifact.
In the Add an artifact pane ensure Source type is set to Build.
Ensure Project is set to Hello Azure.
Under Source (build pipeline) select HelloAzure.
Click on Add
Click on Continuous deployment trigger
In the Continuous deployment trigger pane toggle the switch for Continuous deployment trigger.
Under Build branch filters select the branch you'd like to run on.

Adding tasks to the Stage

Click on 1 job, 0 task under the Dev Stage.
In the Tasks list click the + icon on the Agent job list item.
In the Add tasks pane search for Azure Functions.
Click Add on the Azure Functions task.

Configure the Azure Function App Deploy task

In the configuration pane under Azure subscription select your Free Trial subscription.
1. Click on Authorize
Under App type select Function App on Windows
Under App name select your Function App name.
Under Package or folder ensure the value is set to $(System.DefaultWorkingDirectory)/*/.zip.
Click on Save in the menu-bar.
Click on Create release in the menu-bar.
Follow the steps in the Create release pane.
Navigate back to the pipeline details page and click on Deploy under dev.
Follow the steps in the Deploy pane.
Your deployment will now be queued.

Recap

In this post we setup a CI/CD process in Azure devops. We created a build pipeline that will automatically build our project. We then created a release pipeline that will take those build artifacts and automatically deploy them to our Function App.

Introduction to Azure Functions Pt. 4 - Deploying the Azure Function

Jacob Smith — Mon, 11 Nov 2019 17:16:36 +0000

Introduction

In this post we will deploy the Azure Function we created to the resources in Azure that we created.

Prerequisites

To deploy the Azure Function we will be using the azure-functions-core-tools cli. Instructions for installing the CLI can be found here.

The azure-functions-core-tools cli will need the Azure CLI in order to authenticate you. Installation instructions for the Azure CLI can be found here

We will be using the command line in this section. Some basic knowledge of the command line will be useful.

Shell commands will be prefixed with $.

Login with the Azure CLI

To publish your function project to a Function App you must login with the Azure CLI.

In any directory login to the Azure CLI
```
$ az login
```
This will launch a login process in your default browser. Login to Azure to continue.

Deploying the Azure Function

Change directories into the Functions project of your locally cloned repository.
```
$ cd ~/code/HelloAzure/HelloAzure.Functions/
```
Deploy to your Function App
```
$ func azure functionapp publish <FunctionAppName>
```
1. Substitute <FunctionAppName> with the name of the Function App you created in Azure.
This will build and publish your function project to the specified Function App.

You should see console output similar to the following

Getting site publishing info...
Creating archive for current directory...
Uploading 3.45 MB [#########################################]
Upload completed successfully.
Deployment completed successfully.
Syncing triggers...
Functions in <FucntionAppName>:
    SayHello - [httpTrigger]
        Invoke url: <FunctionAppInvokeURL>

You may test your deployed function by visiting the Invoke url and adding a query parameter for name. If you see a response with the message Hello, <name> congrats! Your function has been deployed.

Recap

In this post we authenticated with the Azure CLI. We then deployed our function project to our Function App. Finally we verified that the function app was succesfully deployed by visiting the Invoke url.

The next step is to automate the function deployment with a CI/CD pipeline.

Introduction to Azure Functions Pt. 3 - Creating the Azure Function resources

Jacob Smith — Mon, 11 Nov 2019 17:15:22 +0000

Introduction

In this post we will be creating resources in Azure that will be used to run the SayHello Azure Function we created in our HelloAzure.Functions project.

Prerequisites

A Microsoft Azure account. Sign up for an account here. I am using the free tier of azure.

Creating the Azure Function resources

We will be creating a few resource in Azure to facilitate execution of the SayHello Azure Function.

Azure Resource Group
- A resource group is a collection of resources in Azure. All the resources we manually create (and any resource dependencies that are automatically created) will be added to this group.
Function App
- A Function App allows us to group related functions together into one unit and manage deployments, resource sharing, and more.

Creating an Azure Resource Group

Login to the Azure portal if you are not yet logged in.
Navigate to the Resource Groups list and click on Create resource group.
In the Create a resource group wizard ensure you have selected Free Trial under Subscription.
Under Resource group name your group HelloAzureGroup.
Skip tags and move on to Review + create.
Ensure the resource group details are correct and Click on Create.
Back on the Resource groups list you should now have a new Resource group named HelloAzureGroup

Creating a Function App

Login to the Azure portal if you are not yet logged in.
Navigate to the Function Apps list and click on Create undefined
In the Function App wizard ensure you have selected Free Trial under Subscription.
Under Resource Group select HelloAzureGroup
Under Function App name name your function app HelloAzureFunctionApp-<GUID>
1. A function app in Azure must have a unique name, which is why we postfix the name with a GUID.
Under Publish ensure Code is selected.
Under Runtime stack select .NET Core.
Select whatever region is appropriate for you (I selected Central US).
You may skip Hosting, Monitoring, and Tags.
Ensure your function app details are correct and click on Create.
Back on the Function App list you should now have a new Function app named HelloAzureFunctionApp-<GUID>

Recap

In this post we created resources in Azure that will be used to run the SayHello Azure Function. We created an Azure Resource Group to contain the resources we create, and resource dependencies that are automatically created. We also created a Function App to deploy our function project to.

The next step is deploying the Azure Function.

Introduction to Azure Functions Pt. 2 - Creating the Azure Function

Jacob Smith — Mon, 11 Nov 2019 17:11:07 +0000

Introduction

In this post we will be creating an Azure Function in our HelloAzure.Functions project. We will add an assembly reference to HelloAzure.BusinessLogic in order to add some contrived business logic. Finally we will run the function project locally in order to verify the function works as expected.

Prerequisites

To create the Azure Function we will be using the azure-functions-core-tools cli. Instructions for installing the CLI can be found here. To add an assembly reference from our BusinessLogic assembly we'll use the dotnet cli which is included in the .NET Core SDK. We will be using version 2.1 of the SDK. The SDK installer can be found here.

We will be using the command line in this section. Some basic knowledge of the command line will be useful.

Shell commands will be prefixed with $.

This wiki assumes that you have created a repository in a source control provider such as GitHub and that you have cloned that repository locally.

Creating the Azure Function

Change directories into the Functions project of your locally cloned repository.
```
$ cd ~/code/HelloAzure/HelloAzure.Functions/
```
Create a new Azure Function in the project.
```
$ func new
```
1. This will start the function creation wizard.
2. When prompted for a trigger select Http Trigger.
3. Name the function SayHello.
4. You should see the following output
```
The function "SayHello" was created successfully from the "HttpTrigger" template.
```
Your HelloAzure.Functions/ directory should now have a SayHello.cs file in it.
```
.
+-- HelloAzure.Functions/
|   +-- SayHello.cs
|   +-- ...
```

Adding a reference to our BusinessLogic assembly

From your HelloAzure.Functions/ directory add a reference to the BusinessLogic assembly.
```
$ dotnet add reference ../HelloAzure.BusinessLogic/HelloAzure.BusinessLogic.csproj
```
1. This command will add a project reference to your HelloAzure_Functions.csproj file that points to the HelloAzure.BusinessLogic project.

Add "business logic" to the function

In a text editor modify the contents of SayHello.cs

using System;
using System.IO;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;
using HelloAzure.BusinessLogic;

namespace HelloAzure.Functions
{
    public static class SayHello
    {
        [FunctionName("SayHello")]
        public static async Task<IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req,
            ILogger log)
        {
            GreetingService greetingService = new GreetingService();
            log.LogInformation("C# HTTP trigger function processed a request.");

            string name = req.Query["name"];

            string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
            dynamic data = JsonConvert.DeserializeObject(requestBody);
            name = name ?? data?.name;

            if (name != null) {
                string greeting = greetingService.GetGreeting(name);
                return (ActionResult)new OkObjectResult(greeting);
            }

            return new BadRequestObjectResult("Please pass a name on the query string or in the request body");
        }
    }
}

In our changes we added a using statement for HelloAzure.BusinessLogic.
Next we instantiated an instance of the GreetingService.
Finally we modified the return logic to generate a greeting using our GreetingService instead of using a hard-coded string.

Running the function locally

From your HelloAzure.Functions/ directory start the function project.
```
$ func start --build
```
1. This will build the functions project and start it.
2. The --build flag is needed since this is a .NET Core functions project and it must be built.
3. This will start an HTTP Server and point your functions to it.
4. You should see output containing the following.
```
Http Functions:

SayHello: [GET,POST] http://localhost:7071/api/SayHello
```
If you visit the URL above in a browser and add a query string parameter for name you should see a response with the message Hello, <name>. If you do then congrats! Your function is working.

Recap

In this post we added an Azure Function to our HelloAzure.Functions project. We added a reference to our HelloAzure.BusinessLogic class library in order to add some contrived business logic to illustrate how you might add logic to a function. Finally we ran our function project locally in order to verify the function works.

This would be a good time to commit the changes you've made to source.

The next step is creating Azure Function resources.

Introduction to Azure Functions Pt. 1 - Creating the .NET Core Solution

Jacob Smith — Mon, 11 Nov 2019 17:01:38 +0000

Introduction

In this post we will be creating a .NET Core solution, a class library to hold shared business logic, and an Azure Functions project. We will also link both projects to the solution, and add some basic business logic to our class library.

Prerequisites

To create the .NET Core solution and the business logic class library we will be using the dotnet cli which is included in the .NET Core SDK. We will be using version 2.1 of the SDK. The SDK installer can be found here. To create the Azure Function project we will be using the azure-functions-core-tools cli. Instructions for installing the CLI can be found here.

We will be using the command line to build out the solution and its projects, and to link them together. Some basic knowledge of the command line will be useful.

Shell commands will be prefixed with $.

This wiki assumes that you have created a repository in a source control provider such as GitHub and that you have cloned that repository locally.

Creating the .NET Core Solution

Change directories into your locally cloned repository.
```
$ cd ~/code/HelloAzure/
```
Create a new .NET Core solution.
```
$ dotnet new solution -n HelloAzure -o
```
1. The dotnet new solution command creates a new solution.
2. The -n HelloAzure flag is the name of the solution.
3. The -o . flag specifies where to output the results of the create operation, in this case the current directory.

Creating the Azure Function Project

From your root directory create a new azure function project .
```
$ func init HelloAzure.Functions
```
1. When prompted choose the dotnet runtime.
2. This will create an empty Azure Functions project and place it in a directory named HelloAzure.Functions.
  1. The azure-core-tools-cli will replace . chars with _ so the generated csproj file will be HelloAzure_Functions.csproj.

Note. The name of the project can be whatever you would like. I went with naming it Functions and name-spacing it under the HelloAzure solution.

Linking the Azure Function Project

From your root directory link the Azure Function Project to the solution.
```
$ dotnet sln add HelloAzure.Functions/HelloAzure_Functions.csproj
```

Creating a business logic class library

From your root directory create a new shared library to contain business logic.
```
$ dotnet new classlib -n HelloAzure.BusinessLogic
```
1. The dotnet new classlib command creates a new class library.
2. The -n HelloAzure.BusinessLogic flag is the name of the class library.

Note. The name of the project can be whatever you would like. I went with naming it BusinessLogic and name-spacing it under the HelloAzure solution.

Linking the business logic class library

From your root directory link the business logic class library to the solution.
```
$ dotnet sln add HelloAzure.BusinessLogic/HelloAzure.BusinessLogic.csproj
```

Adding some "business logic" logic to the BusinessLogic library

The BusinessLogic class library is stubbed out with an empty class named Class1.cs. We need to rename it and give it some actual business logic to handle.

Change directories into the BusinessLogic project
```
$ cd HelloAzure.BusinessLogic/
```
Rename the Class1.cs file to GreetingService.cs
```
$ mv Class1.cs GreetingService.cs
```

In a text editor replace the contents of GreetingService.cs with the following.

namespace HelloAzure.BusinessLogic
{
    public class GreetingService
    {
        public string GetGreeting(string name)
        {
            return $"Hello, {name}";
        }
    }
}

Recap

In this post we created the following.

A .NET Core solution.
An Azure Functions project.
A BusinessLogic class library.

We also added links from each project to the solution.

Finally we added some actual business logic to the BusinessLogic class library.

If you followed all the above steps you should have a project structure that looks like the following.

.
+-- .gitignore
+-- HelloAzure.sln
+-- HelloAzure.BusinessLogic/
|   +-- GreetingService.cs
|   +-- HelloAzure.BusinessLogic.csproj
+-- HelloAzure.Functions/
|   +-- .vscode/
|   +-- .gitignore
|   +-- HelloAzure_Functions.csproj
|   +-- host.json
|   +-- local.settings.json

Congrats on getting all the setup complete 😊 . We now have a solution that we can add functions to 🎉.

This would be a good time to commit the changes you've made to source.

Introduction to Azure Functions

Jacob Smith — Mon, 11 Nov 2019 17:01:25 +0000

Recently for work I have been assigned to a project that uses Azure Functions as its backbone. I have prior experience with the .NET ecosystem, but had not yet had much of a chance to work with Azure or newer versions of .NET Core. I spent a bit of time before the project started getting buffed up on all the tooling and know-how I would need to write and deploy functions to Azure.

This series is a walk through of everything I did to get a simple Azure Function setup and deploy-able (both manually, and through a CI/CD pipeline). The repository that contains my function is located here.

The repository above contains a wiki with this entire series already in it. I also wanted to post to Dev in the hopes that the content might be useful to folks here!

The series is broken out into 5 parts. They can be referenced in any order but I would suggest going through them in order.

Each post follows a similar structure.

Introduction
- Outlines what will be covered in the section, and what the output should be.
Prerequisites
- Calls out any prerequisites needed for the section and covers how to obtain them.
Content
Recap
- Serves as a quick recap to show you all the work you just accomplished 😊.

I hope this series is informative for anyone reading it! Comments and feedback are more than welcome.