index.xml

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Mortar</title>
    <link>https://go-masonry.github.io/</link>
    <description>Recent content on Mortar</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language><atom:link href="https://go-masonry.github.io/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Bricks</title>
      <link>https://go-masonry.github.io/mortar/bricks/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://go-masonry.github.io/mortar/bricks/</guid>
      <description>When we build software, most of us always try to rely on something we or others have built before us. Since we don&amp;rsquo;t want to reinvent the wheel, again.
Go&amp;rsquo;s standard library is an excellent example here. There are strings, time, http and many other build-in libraries that we use. While this example is great, it doesn&amp;rsquo;t scale to 3rd party libraries.
Let&amp;rsquo;s look at Logger libraries for example, there are:</description>
    </item>
    
    <item>
      <title>Builder Pattern</title>
      <link>https://go-masonry.github.io/mortar/builders/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://go-masonry.github.io/mortar/builders/</guid>
      <description>You&amp;rsquo;re probably used to functional options pattern. However, we found Builder pattern to be very useful, here we will explain why.
Motivation  &amp;ldquo;See&amp;rdquo; all the options without searching for them. Partial Builders:  Override previously set values    Library usage within the organization +---------------------+ +-------------------------------+ +-------------------------+ | Library Developer | +--------&amp;gt; | Platform/Infra/Ops Developer | +-------&amp;gt; | Integration Developer | +---------------------+ +-------------------------------+ +-------------------------+ Develops the library to be used Pre-configure the library specifically Set final values in different scenarios, expose to their organization.</description>
    </item>
    
    <item>
      <title>Configuration Map</title>
      <link>https://go-masonry.github.io/mortar/config/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://go-masonry.github.io/mortar/config/</guid>
      <description>It is good practice to use constants in your code instead of magic numbers, and it&amp;rsquo;s even better to set them outside your code, either by providing a config file or reading from an environment variable. Mortar has a Config interface that is used everywhere to read external configurations. While Mortar can be configured explicitly, and that gives you total control over it, it is much comfortable to use its defaults.</description>
    </item>
    
    <item>
      <title>Listeners</title>
      <link>https://go-masonry.github.io/mortar/listeners/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://go-masonry.github.io/mortar/listeners/</guid>
      <description>We assume that you, like us, don&amp;rsquo;t expose your services to the world without setting up at least a Load Balancer before it/them. Historically, when we started building webservices, our infrastructure was expecting a single port to forward all the traffic to it from the LoadBalancer. When we wanted to use gRPC API, as well as REST, we still had to expose everything under one port. Fortunately, we weren&amp;rsquo;t the first, and we used this excellent cmux library to solve that problem.</description>
    </item>
    
  </channel>
</rss>