Founded in 2006, 8th Light is a global team of software, design, and technology professionals. We partner with forward-thinking people and organizations to help them imagine and create elegant, robust, and groundbreaking software solutions to complex problems. With deep expertise and experience in software design, development, data, and DevOps, we work with a wide range of clients who are looking to achieve equally diverse outcomes. Rooted in a culture of continuous learning and collaboration, we’re employee-owned, and headquartered in Chicago, but our more than 140 team members live and work in locations including London, New York, Los Angeles, and Austin. Whether we’re crafting digital experiences that inform and inspire, energizing and empowering enterprises through technology-driven transformation, or nurturing and guiding internal teams looking to expand their own technological expertise and software-building capabilities, our objective is always the same: to help unlock human potential and spark change.

8th Light

A weekly newsletter with the best articles on microservices. Hand-curated by the engineers of . Subscribe: RisingStack https://microserviceweekly.com/ Top 5 Spring + Microservice Courses for Advanced Java Developers In Java world, Spring Framework provides several tools and framework to develop microservices e.g. Spring Boot and Spring Cloud and in this article, I’ll share a couple of good courses you can use to learn how to develop Microservices using Spring framework. _Microservices is the new buzzword in software development word, particularly on Java side, but it’s been in practice…_hackernoon.com Top 5 Spring + Microservice Courses for Advanced Java Developers Operational challenges in Microservices and how to overcome it using Consul In this article we will learn what are some operational challenges in microservices architecture and how consul helps to overcome it. With this we will learn what a service mesh is and how consul helps to overcome the challenges it creates. _In this article we will learn what are some operational challenges in microservices architecture and how consul helps…_devopsideas.com Operational challenges in Microservices and how to overcome it using Consul The Impact of Microservice Architecture on Load Testing See how the structure of microservice architecture and their communication affects the way we need to run load testing. _Microservice architecture (or, "microservices") has slowly emerged in recent years as a go-to method for development…_dzone.com The Impact of Microservice Architecture on Load Testing - DZone Microservices API vs. Microservices: A Microservice Is More Than Just an API A microservice can be misconstrued as simply an endpoint to provide an API. But microservices have much more flexibility and capabilities than that. This article will speak on the differences between APIs and microservices, plus detail some of the benefits a microservice can provide. _When writing software, consider both the implementation and the architecture of the code. The software you write is…_blog.scalyr.com API vs. Microservices: A Microservice Is More Than Just an API From monolith to microservices: Horror stories and best practices Architects currently or formerly at Best Buy, Cloud Elements, and Wix.com share some of the world’s most advanced microservices design escapades — horror stories and best practices from the microservices trenches. _They say software is getting smaller-micro, in fact. Microservices are the latest software architecture trend, and its…_techbeacon.com From monolith to microservices: Horror stories and best practices | TechBeacon Microservices Aren’t Magic: Handling Timeouts As microservices, serverless, and other distributed systems architectures become even more prevalent in the industry, it’s critical that we internalize their problems and strategies for solving them. In this article, we’ll look at one example of the many tricky issues that network boundaries can introduce: timeouts. _Microservices are a big deal. They can give us some pretty big wins for our architectures and teams, but microservices…_8thlight.com Microservices Aren't Magic: Handling Timeouts | 8th Light An Introduction to Serverless Microservices Thinking about microservices, especially their communication patterns, can be a bit of a mind-bending experience for developers. The idea of splitting an application into several (if not hundreds of) independent services, can leave even the most experienced developer scratching their head and questioning their choices. _Thinking about microservices, especially their communication patterns, can be a bit of a mind-bending experience for…_www.jeremydaly.com An Introduction to Serverless Microservices - Jeremy Daly Create full Microservice stack using JHipster Domain Language under 30 minutes Let us see how we can create a microservice stack using JHipster. We will build an e-commerce store today. _It’s been quite a while since I wrote a blog, I did a few some years ago but never really continued writing. So when I…_medium.com Create full Microservice stack using JHipster Domain Language under 30 minutes Training: Designing Microservice Architectures — Barcelona During the course of these two days, we will cover a high-level architectural overview of what is needed to design, develop and maintain an application built with microservices. _Two days of training to master microservices. _ Delivered by the expert instructors of RisingStack. Peter Czibik, Tamas…_ti.to Designing Microservice Architectures - Barcelona In brief Dynamically Update Your Microservice Configuration Serverless Microservices Explained Microservice Architectures in Embedded Linux and FreeRTOS Q&A — Red Hat’s Brian Gracely talks NFV, containers and microservices

The Microservice Weekly #151 — September 26.

source There is no shortage of new content. Millions of new blog posts are written every day. It’s important that we stay informed for our career, growth and general awareness. We’re all familiar with Newsletters. Newsletters are mini publications, curated by experts and enthusiasts on a focused topic. I like Newsletters, and it’s how I keep up with topics that matter to me. I’m already subscribed to several high-quality tech, startups focused Newsletters. You can check out my on Nucleus. I have a couple of good engineering sources like Hacker News, Reddit. But I wanted to expand my knowledge beyond that. So, I started digging the web for some engineering focused Newsletters. After, spending 2 hours online, I came across a couple of guides that looked promising. One of them is . This is a good master list but feels overwhelming. profile https://github.com/kilimchoi/engineering-blogs After couple of hours of further digging the web, I had compiled a master list of all tech blogs. About 200+ resources. All that left was going over this list and start validating. My validation metrics include content quality, freshness, and coverage. I thought it will be useful to others. So, I decided to put together a guide on best engineering newsletters/blogs. Take your time to review, and subscribe to those that you like. If you want to keep them organized, don’t miss out on the last part of this article. I hope you find this list useful and it helps you stay informed in your respective industries. Please let me know if you have a favorite that I missed it. Android Newsletters: Android Weekly - Free weekly Android development newsletterandroidweekly.net Android Weekly - Free weekly Android development newsletter _Android Authority Newsletters View all our recent newsletter campaigns Stay up to date on all the latest technology…_www.androidauthority.com Android Authority Newsletters - Android Authority A Handcrafted Weekly #AndroidDev Newsletterwww.androiddevdigest.com #AndroidDev Digest - A Handcrafted Weekly #AndroidDev Newsletter Database Newsletters : _A weekly round-up of database technology news and articles covering new developments, SQL, NoSQL, document databases…_dbweekly.com DB Weekly: A Free, Weekly Email Newsletter _A free, once-weekly e-mail round-up of PostgreSQL news and articles_postgresweekly.com Postgres Weekly: A Free, Weekly Email Newsletter _A free weekly newsletter featuring curated news, articles, new releases, events, tools and libraries, jobs etc related…_www.nosqlweekly.com NoSQL Weekly: A Free, Weekly NoSQL E-mail Newsletter _In this blog post, I'll look at the types of NVMe flash health information you can get from using the NVMe command line…_www.percona.com Percona Database Performance Blog _Signup for the MSSQLTips.com newsletter and get free SQL Server tips delivered to you._www.mssqltips.com Join the MSSQLTips SQL Server Community Javascript Newsletters : _Edit description_adripofjavascript.com Home - A Drip of JavaScript _A free, once-weekly e-mail round-up of Node.js news and articles_nodeweekly.com Node Weekly: A Free, Weekly Email Newsletter _A weekly newsletter for front-end developers with a specific focus on tools._webtoolsweekly.com Web Tools Weekly | A weekly newsletter for front-end developers _A free, once-weekly e-mail round-up of JavaScript news and articles._javascriptweekly.com JavaScript Weekly: A Free, Weekly Email Newsletter _We come across a lot of great articles on creating, testing and maintaining large JavaScript applications. This page is…_superherojs.com Superhero.js _Fullstack React is a weekly newsletter about the React ecosystem with an emphasis on useful libraries, tutorials and…_newsletter.fullstackreact.com Fullstack React _The free, weekly newsletter of the best React.js news, articles, projects, and more - brought to you by React.js…_reactjsnewsletter.com React Newsletter _Free weekly occasional summary of React Native news, articles, issues & pull requests, libraries and apps curated by…_reactnative.cc React Native Newsletter iOS Newsletters : _This is a quick look at the changes I needed to make to bring Cocoa with Love up to date for Swift 3 and the latest iOS…_www.cocoawithlove.com Cocoa with Love _In this screencast, you'll learn about classes in C# and how C# manages the memory for them. In this screencast, you'll…_www.raywenderlich.com Tutorials _objc.io publishes books on advanced techniques and practices for iOS and OS X development_www.objc.io objc.io _Subscribe to a hand-picked round up of the best iOS development links every week. Curated by Dave Verwer and published…_iosdevweekly.com iOS Dev Weekly - The best iOS development links, every Friday _Tips and techniques for iOS and Mac development - Weekday mornings at 9:42 AM. The goal of each of these 'bites' is to…_littlebitesofcocoa.com Little Bites of Cocoa - Tips and techniques for iOS and Mac development - Weekday mornings at 9:42… _The greatest iOS development tools, including websites, desktop and mobile apps, and back-end services. Updated daily…_iosdev.tools iOS Dev Tools - The Greatest iOS Development Tools _NSHipster is a journal of the overlooked bits in Objective-C, Swift, and Cocoa. Updated weekly._nshipster.com NSHipster _Hi there, I'm @NatashaTheRobot and I'm programmed to love #Swift! Every week, I put together a list of the best Swift…_swiftnews.curated.co This Week in Swift Company Engineering Blogs: A Language agnostic blogs sharing their latest ideas, and best practices. engineering learnings _All Posts - 8th Light's blog is a place for software crafters to indulge their curiosities, share new ideas, and debate…_8thlight.com All Posts | 8th Light _Welcome to the 500px Engineering Blog! This is where we, the engineers at 500px, share and discuss the challenges and…_developers.500px.com 500px Engineering Blog _Edit description_nerds.airbnb.com Airbnb Engineering - Nerds _Making things work_engineering.bloomreach.com BloomReach Engineering Blog _Introduction Location-specific feedback has always been fundamental to collaboration. At Dropbox, we've recognized this…_blogs.dropbox.com Dropbox Tech Blog _In April of 2016 Etsy launched Pattern, a new product that gives Etsy sellers the ability to create their own hosted e…_codeascraft.com Code as Craft _Meet the engineers who code Facebook_code.facebook.com Engineering Blog _The Blog of the GitHub Engineering Team_githubengineering.com GitHub Engineering _At Heroku, we're always working towards improving operational stability with the services we offer. As we recently…_engineering.heroku.com Heroku Engineering Blog _Stories from the people who build @Instagram_engineering.instagram.com Instagram Engineering _Read more about tech-at-instacart. Instacart Engineering._tech.instacart.com About Tech at Instacart _Stories from Lyft Engineering._eng.lyft.com Lyft Engineering _Join our engineers where we talk about solutions to problems presented by big data and the race for big speed._eng.localytics.com LocalyticsEng _Stories from the team who are building Medium._medium.engineering Medium Engineering _This is a Netflix blog focused on technology and technology issues. We'll share our perspectives, decisions and…_techblog.netflix.com The Netflix Tech Blog _Video publishing at The Times is growing For the past 10 years, the video publishing lifecycle at The New York Times…_open.blogs.nytimes.com Code - Open Blog - The New York Times _Engineers build Quora from the ground up, creating APIs and abstractions to solve challenging technical problems. This…_engineering.quora.com Engineering at Quora _This is part two of a three part series on how we created a technical career path for individuals at Spotify and what…_labs.spotify.com Labs _At Squarespace, our mission is to provide creative tools that help anyone bring their ideas to life. In this blog you…_engineering.squarespace.com Home _Follow the Stripe blog for product announcements, feature updates, new countries, and technical posts about payments._stripe.com Stripe Blog _In the last infrastructure blog post we focused on some of the key efficiency and optimization efforts that we've made…_blog.twitter.com Engineering | Twitter Blogs _The Official Blog_blog.twitch.tv Twitch Blog _The work behind Uber Engineering._eng.uber.com Uber Engineering Blog That’s all! Did I miss any awesome newsletter? Let me know. Found this post useful? Kindly tap the ❤ button below! :) This list was originally curated on . You can checkout from Joel. Sign up to curate the best of what you’re reading for yourself or share with who and what matters to you. Nucleus more engineering curations Editor’s Note: Also check out Hacker Noon Letters :-)

Engineering Newsletters that You Should Subscribe To

Hi guys, I’m a Front-End developer. Before there was a time 2 years working CMS Magento, I like CMS Magento because system clean, and architecture database EAV (Entity — Attribute — Value) but I don’t understand why present I’m dev front-end (I don’t know) in the 2-year current. And present I chance comeback working position Back-End that I like. I’ve read some articles following: (Uncle bob) https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html (Iman Tumorang — Software Engineer) https://medium.com/hackernoon/golang-clean-archithecture-efd6d7c43047 (Elton Minetto — CTO) https://medium.com/@eminetto/clean-architecture-using-golang-b63587aa5e3f Summary If you have read through the article Uncle bob, he said that: > Each has at least one layer for business rules, and another for interfaces. So, each of these architectures produce systems that are: Independent of Frameworks. The architecture does not depend on the existence of some library of feature laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints. Testable. The business rules can be tested without the UI, Database, Web Server, or any other external element.Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.Independent of Database. You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.Independent of any external agency. In fact your business rules simply don’t know anything at all about the outside world. More at https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html In architecture of Uncle Bob divide 4 layers: Entites Use Cases Controller Framerwork & Devices In my project divide layers: Models Use case Repository Delivery Models: Models is same as entites. It set of data struct, interface and method, functions. Example model: Book ( ) type Book struct {
	ID     uint Title  string Author string }

type BookUsecase interface {
	Fetch(ctx context.Context) ([]Book, error)
	GetByID(ctx context.Context, id string) (Book, error)
}

type BookRepository interface {
	Fetch(ctx context.Context) (res []Book, err error)
	GetByID(ctx context.Context, id string) (Book, error)
} import "context" // Book ... `json:"id" gorm:"primary_key"` `json:"title"` `json:"author"` : Usecase This a layer will handle problem logic business. This a layer decide repository will use. And have responsibility to provide data to layer delivery use.Layer Usecase a depends layer Repository ( )

type bookUsecase struct {
	bookRepo domain.BookRepository
} func NewBookUsecase(a domain.BookRepository) domain.BookUsecase { &bookUsecase{ : a,
	}
}
func (a *bookUsecase) Fetch(c context.Context) (res []domain.Book, err error) {
	res, err = a.bookRepo.Fetch(c) err != nil { nil, err
	} }

func (a *bookUsecase) GetByID(c context.Context, id string) (res domain.Book, err error) {
	res, err = a.bookRepo.GetByID(c, id) } import "context" "github.com/working/project/domain" // NewArticleUsecase will create new an articleUsecase object representation of domain.ArticleUsecase interface return bookRepo if return return return : Repository This a layer will handle to database method: fetch, put, delete, get, etc.Layer responsibility will choose DB use in application. Could be Mysql, Postgresql, MongoDB, MariaDB, etc ( )

type psqlBookRepository struct {
	Conn *gorm.DB
} func NewPsqlBookRepository(Conn *gorm.DB) domain.BookRepository { &psqlBookRepository{Conn}
}

func (m *psqlBookRepository) Fetch(ctx context.Context) (res []domain.Book, err error) { books []domain.Book
	m.Conn.Find(&books) books, nil
}
func (m *psqlBookRepository) GetByID(ctx context.Context, id string) (res domain.Book, err error) { book domain.Book
	m.Conn.Where( , id).First(&book) book, nil
} import "context" "github.com/jinzhu/gorm" "github.com/working/project/domain" // NewMysqlArticleRepository will create an object that represent the article.Repository interface return var return var "id = ?" return : Deliver This a layer will decide how the data present. Could be REST API, HTML, or gRPC whatever the decide type.This a lay accept the input from user and send layer Usecase handle logic ( )

type BookeHandler struct {
	BookUsecase domain.BookUsecase
}

func NewBooksHandler(r *gin.RouterGroup, us domain.BookUsecase) { := &BookeHandler{ : us,
	}
	r.GET( , handler.FindBooks) r.GET( , handler.FindBook) }

func (a *BookeHandler) FindBooks(c *gin.Context) {
	books, := a.BookUsecase.Fetch(c.Request.Context())
	c.JSON( , gin.H{ : books})
}

func (a *BookeHandler) FindBook(c *gin.Context) {
	books, := a.BookUsecase.GetByID(c.Request.Context(), c.Param( ))
	c.JSON( , gin.H{ : books})
} import "github.com/gin-gonic/gin" "github.com/working/project/domain" handler BookUsecase "/books" // r.POST("/books", handler.CreateBook)       // create "/books/:id" // find by id // r.PATCH("/books/:id", handler.UpdateBook)  // update by id // r.DELETE("/books/:id", handler.DeleteBook) // delete by id _ 200 "data" _ "id" 200 "data" Current my project building on based 4 layers: Model, Usecase, Repository, and Delivery which I present above. And my project interview, I think it not good. I will rebuild the architecture project in article next. You should understand architecture someone and accept it in a project of you. That will give you look good and remember to start with it simple Link Project: https://github.com/caohoangnam/go-clean-architecture Tech stack using: Gorm Gin Framework Postgresql Viper Clean Architecture If you have a question , or need more explanation, or something, that I can not explain well here, you can ask me from my linked in or email me. Thank you so much.

Creating Clean Architecture Using Golang

Independent, Testable , and Clean After reading the uncle Bob’s Clean Architecture Concept, I’m trying to implement it in Golang. This is a similar architecture that we used in our company, but a little different structure. Not too different, same concept but different in folder structure. Kurio - App Berita Indonesi a, You can look for a sample project here , a sample CRUD management article. https://github.com/bxcodec/go-clean-arch Disclaimer : I’m not recommending any library or framework used here. You could replace anything here, with your own or third party that has the same functions. Basic As we know the constraint before designing the Clean Architecture are : Independent of Frameworks. The architecture does not depend on the existence of some library of feature laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints. Testable. The business rules can be tested without the UI, Database, Web Server, or any other external element. Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules. Independent of Database. You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database. Independent of any external agency. In fact your business rules simply don’t know anything at all about the outside world.More at https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html So, based on this constraint, every layer must independent and testable. If Uncle Bob’s Architecture, has 4 layer : Entities Usecase Controller Framework & Driver In my projects, I’m using 4 too : Models Repository Usecase Delivery Models Same as Entities, will used in all layer. This layer, will store any Object’s Struct and its method. Example : Article, Student, Book. Example struct : type Article struct {
	ID        int64 Title     string Content   string UpdatedAt time.Time CreatedAt time.Time } import "time" `json:"id"` `json:"title"` `json:"content"` `json:"updated_at"` `json:"created_at"` Any entities, or model will stored here. Repository Repository will store any Database handler. Querying, or Creating/ Inserting into any database will stored here. This layer will act for CRUD to database only. No business process happen here. Only plain function to Database. This layer also have responsibility to choose what DB will used in Application. Could be Mysql, MongoDB, MariaDB, Postgresql whatever, will decided here. If using ORM, this layer will control the input, and give it directly to ORM services. If calling microservices, will handled here. Create HTTP Request to other services, and sanitize the data. This layer, must fully act as a repository. Handle all data input - output no specific logic happen. This Repository layer will depends to Connected DB , or other microservices if exists. Usecase This layer will act as the business process handler. Any process will handled here. This layer will decide, which repository layer will use. And have responsibility to provide data to serve into delivery. Process the data doing calculation or anything will done here. Usecase layer will accept any input from Delivery layer, that already sanitized, then process the input could be storing into DB , or Fetching from DB ,etc. This Usecase layer will depends to Repository Layer Delivery This layer will act as the presenter. Decide how the data will presented. Could be as REST API, or HTML File, or gRPC whatever the delivery type. This layer also will accept the input from user. Sanitize the input and sent it to Usecase layer. For my sample project, I’m using REST API as the delivery method. Client will call the resource endpoint over network, and the Delivery layer will get the input or request, and sent it to Usecase Layer. This layer will depends to Usecase Layer. Communications Between Layer Except Models, each layer will communicate through inteface. For example, Usecase layer need the Repository layer, so how they communicate? Repository will provide an interface to be their contract and communication. Example of Repository’s Interface package repository models type ArticleRepository interface {
	Fetch(cursor string, num int64) ([]*models.Article, error)
	GetByID(id int64) (*models.Article, error)
	GetByTitle(title string) (*models.Article, error)
	Update(article *models.Article) (*models.Article, error)
	Store(a *models.Article) (int64, error)
	Delete(id int64) (bool, error)
} import "github.com/bxcodec/go-clean-arch/article" Usecase layer will communicate to Repository using this contract, and Repository layer implement this interface so can used by Usecase MUST Example of Usecase’s Interface package usecase ( )

type ArticleUsecase interface {
	Fetch(cursor string, num int64) ([]*article.Article, string, error)
	GetByID(id int64) (*article.Article, error)
	Update(ar *article.Article) (*article.Article, error)
	GetByTitle(title string) (*article.Article, error)
	Store(*article.Article) (*article.Article, error)
	Delete(id int64) (bool, error)
} import "github.com/bxcodec/go-clean-arch/article" Same with Usecase, Delivery layer will use this contract interface. And Usecase layer implement this interface. MUST Testing Each Layer As we know, clean means independent. Each layer testable even other layers doesn’t exist yet. This layer only tested if any function/method declared in any of Struct. And can test easily and independent to other layers. Models Layer: To test this layer, the better ways is doing Integrations testing. But you also can doing mocking for each test. I’m using github.com/DATA-DOG/go-sqlmock as my helper to mock query process msyql. Repository: Because this layer depends to Repository layer, means this layer need Repository layer for testing . So we must make a mockup of Repository that mocked with mockery, based on the contract interface defined before. Usecase: Same with Usecase, because this layer depends to Usecase layer, means we need Usecase layer for testing. And Usecase layer also must mocked with mockery, based on the contract interface defined before Delivery: For mocking , I use mockery for golang by vektra could be seen here https://github.com/vektra/mockery Repository Test To test this layer, like I said before , I’m using a sql-mock to mock my query process. You can use like what I used here github.com/DATA-DOG/go-sqlmock , or another that have similar function func TestGetByID(t *testing.T) {
 db, mock, := sqlmock.New() err != nil { 
    t.Fatalf(“an error ‘%s’ was not expected when opening a stub  
        database connection”, err) 
  } 
 defer db.Close() 
 rows := sqlmock.NewRows([]string{
        “id”, “title”, “content”, “updated_at”, “created_at”}).   
        AddRow( , “title ”, “Content ”, time.Now(), time.Now()) 
 query := “SELECT id,title,content,updated_at, created_at FROM 
          article WHERE ID = \\?” 
 mock.ExpectQuery(query).WillReturnRows(rows) 
 a := articleRepo.NewMysqlArticleRepository(db) 
 num := int64( ) 
 anArticle, := a.GetByID(num) 
 assert.NoError(t, err) 
 assert.NotNil(t, anArticle)
} err if 1 1 1 1 err Usecase Test Sample test for Usecase layer, that depends to Repository layer. package usecase_test ( models ucase )

func TestFetch(t *testing.T) { := (mocks.ArticleRepository) mockArticle models.Article
	err := faker.FakeData(&mockArticle)
	assert.NoError(t, err)

	mockListArtilce := make([]*models.Article, )
	mockListArtilce = append(mockListArtilce, &mockArticle)
	mockArticleRepo.On( , mock.AnythingOfType( ), mock.AnythingOfType( )).Return(mockListArtilce, nil)
	u := ucase.NewArticleUsecase(mockArticleRepo)
	num := int64( )
	cursor := list, nextCursor, := u.Fetch(cursor, num)
	cursorExpected := strconv.Itoa(int(mockArticle.ID))
	assert.Equal(t, cursorExpected, nextCursor)
	assert.NotEmpty(t, nextCursor)
	assert.NoError(t, err)
	assert.Len(t, list, len(mockListArtilce))

	mockArticleRepo.AssertCalled(t, , mock.AnythingOfType( ), mock.AnythingOfType( ))

} import "errors" "strconv" "testing" "github.com/bxcodec/faker" "github.com/bxcodec/go-clean-arch/article" "github.com/bxcodec/go-clean-arch/article/repository/mocks" "github.com/bxcodec/go-clean-arch/article/usecase" "github.com/stretchr/testify/assert" "github.com/stretchr/testify/mock" mockArticleRepo new var 0 "Fetch" "string" "int64" 1 "12" err "Fetch" "string" "int64" Mockery will generate a mockup of repository layer for me. So I don’t need to finish my Repository layer first. I can work finishing my Usecase first even my Repository layer not implemented yet. Delivery Test Delivery test will depends on how you to deliver the data. If using http REST API, we can use httptest a builtin package for httptest in golang. Because it’s depends to Usecase, so we need a mock of Usecase . Same with Repository, i’m also using Mockery to mock my usecase, for delivery testing. func TestGetByID(t *testing.T) { mockArticle models.Article 
 err := faker.FakeData(&mockArticle) 
 assert.NoError(t, err) 
 mockUCase := (mocks.ArticleUsecase) 
 num := int(mockArticle.ID) 
 mockUCase.On(“GetByID”, int64(num)).Return(&mockArticle, nil) 
 e := echo.New() 
 req, := http.NewRequest(echo.GET, “/article/” +  
             strconv.Itoa(int(num)), strings.NewReader(“”)) 
 assert.NoError(t, err) 
 rec := httptest.NewRecorder() 
 c := e.NewContext(req, rec) 
 c.SetPath(“article/:id”) 
 c.SetParamNames(“id”) 
 c.SetParamValues(strconv.Itoa(num)) 
 handler:= articleHttp.ArticleHandler{ : mockUCase, : httpHelper.HttpHelper{}
 } 
 handler.GetByID(c) 
 assert.Equal(t, http.StatusOK, rec.Code) 
 mockUCase.AssertCalled(t, “GetByID”, int64(num))
} var new err AUsecase Helper Final Output and The Merging After finish all layer and already passed on testing. You should merge into one system in main.go in root project. Here you will define, and create every needs to environment, and merge all layers into one. Look for my main.go as example: package main ( httpDeliver articleRepo articleUcase cfg _ ) config cfg.Config

func init() {
	config = cfg.NewViperConfig() config.GetBool( ) {
		fmt.Println( )
	}

}

func main() { := config.GetString( )
	dbPort := config.GetString( )
	dbUser := config.GetString( )
	dbPass := config.GetString( )
	dbName := config.GetString( )
	connection := fmt.Sprintf( , dbUser, dbPass, dbHost, dbPort, dbName)
	val := url.Values{}
	val.Add( , )
	val.Add( , )
	dsn := fmt.Sprintf( , connection, val.Encode())
	dbConn, := sql.Open( , dsn) err != nil && config.GetBool( ) {
		fmt.Println(err)
	}
	defer dbConn.Close()
	e := echo.New()
	middL := middleware.InitMiddleware()
	e.Use(middL.CORS)

	ar := articleRepo.NewMysqlArticleRepository(dbConn)
	au := articleUcase.NewArticleUsecase(ar)

	httpDeliver.NewArticleHttpHandler(e, au)

	e.Start(config.GetString( ))
} import "database/sql" "fmt" "net/url" "github.com/bxcodec/go-clean-arch/article/delivery/http" "github.com/bxcodec/go-clean-arch/article/repository/mysql" "github.com/bxcodec/go-clean-arch/article/usecase" "github.com/bxcodec/go-clean-arch/config/env" "github.com/bxcodec/go-clean-arch/config/middleware" "github.com/go-sql-driver/mysql" "github.com/labstack/echo" var if `debug` "Service RUN on DEBUG mode" dbHost `database.host` `database.port` `database.user` `database.pass` `database.name` "%s:%s@tcp(%s:%s)/%s" "parseTime" "1" "loc" "Asia/Jakarta" "%s?%s" err `mysql` if "debug" "server.address" You can see, every layer merge into one with its dependencies. Conclusion In short, if drawn in a diagram, can seen below Every library used here you can change by your own. Because the main point of clean architecture is : no matter your library, but your architecture is clean, and testable also independent This is how i organized my projects, you could argue, or agree, or maybe improve this for more better, just leave a comment and share this The Sample Projects The sample project can seen here https://github.com/bxcodec/go-clean-arch Library used for my project: Glide : for package management go-sqlmock from github.com/DATA-DOG/go-sqlmock Testify : for testing Echo Labstack (Golang Web Framework) for Delivery layer Viper : for environment configurations Further Reading about Clean Architecture: Second part of this article: https://hackernoon.com/trying-clean-architecture-on-golang-2-44d615bf8fdf https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html http://manuel.kiessling.net/2012/09/28/applying-the-clean-architecture-to-go-applications/ . Another version of Clean Architecture in Golang If you have a question , or need more explanation, or something, that I can not explain well here, you can ask me from my linkedin or email me. Thank you

Trying Clean Architecture on Golang

Probando la arquitectura limpia en Golang

Because it’s definition is poorly phrased, the Open/Closed principle is probably the most misunderstood of the 5 SOLID principles. However it’s the one which when properly applied can save you more development effort through good architecture than any of the others. The principle as originated by Bertrand Meyer states: software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification Later, when he included it in his SOLID principles, Bob Martin expressed it better: You should be able to extend the behavior of a system without having to modify that system. What this is about is best understood in the context of writing a software package or library which is used by many third parties. Essentially you want this library to be used in the widest variety of likely contexts by its consumers (open for extension), however you want to change it as little as possible, because every time you do you’re obliging your consumers to update their versions and in the worst case, fix the consequences of breaking changes. Also, this helps with reliability because ideally over time the code will become more and more well tested by use in many contexts, and less and less frequently changed so less liable to be broken by those changes. The same applies to a lesser extent to when you write code in one place in your application which is used elsewhere: if you can adapt it to different purposes by writing new code that is better than modifying it because modifying it will likely cause changes to need to be made everywhere it is used. You can see that this second principle is like the Single Responsibility Principle about minimising the consequences of future changes to your code. And just like the SRP, the way you follow this principle in practice is determined by an educated guess about how the requirements on your software are likely to change in future. In the SRP you make a judgement about decomposition and where to draw encapsulation boundaries in your code. In the OCP, you make a judgement about what in your module you will make and leave to your module’s consumers to make concrete, and what concrete functionality to provide yourself. abstract As with the SRP, this cannot be a one way street where you must write code that could never need to be modified and can always be extended. The only code that could never need to be modified is a class such as below: public class TotallyAbstract<TArg, TRes>{private Func<TArg, TRes> f; public TotallyAbstract(Func<TArg, TRes> f){this.f = f;} public TRes Apply(TArg a){return f(a);}} You’ll notice that it actually has no functionality whatsoever! Here is the opposite: you can only get it to do one thing ever and you’d have to modify it to do anything else: public class TotallyConcrete{public int Apply(){return 2 + 2;}} Any sensible module must lie in between these extremes: to do something useful it has to be partially concrete, however to be used in a range of contexts it must be partially abstract. So don’t get the extremist idea that your code should never be changed only extended! A function or program can have its functionality varied by the parameters and configuration data which it receives. The Open Closed Principle doesn’t seem to be talking about this kind of adaptation of functionality when it speaks of ‘extension’, though. This sounds like writing code not data: however the line between the two is always blurred to a greater or lesser extent. Configuration of a module can be done using data files or code. It’s part of simple programming to call functions with parameters. However, extending code with other code is more advanced. This however is possibly the most important skill to learn as a programmer, because it enables you to write less code! It does this by letting you use the same code in a wider variety of contexts. The skill here is not just in writing code which can be extended easily but also in seeing the opportunity to do so. A very powerful example of this way of working is the plug-in architecture. A classic use for this is in image editors where you can plug in filters made by third parties. The image editor knows nothing specific about any of the filters: it has a contract which is an abstraction which defines the minimum requirements for a piece of code to be used as an image filter, then it makes no further assumptions about the plugins except that they fulfil this contract. This allows the image editor without any of its code being changed to have its functionality extended by other code. Bob Martin writes about this here: . https://8thlight.com/blog/uncle-bob/2014/05/12/TheOpenClosedPrinciple.html This is of course an example of dependency inversion, the D in SOLID. In fact all extension of a module with code is a form of dependency inversion: the difference is in what kind of abstraction you use to specify the dependency which will be injected: The module has parameters in its API which allow functions to be passed in and executed in the context of the module’s operation to specify or modify its function. This is underused in object oriented programming in my view, and provides a clear and simple way to inject code which works best where this function has no need to be reused in other contexts, and is not naturally grouped with a set of related functions as in a class. Function parameters (no data) Similar to the above, except the code which is injected into the module is now in the form of a class which groups together custom methods and possibly data. This is the most recommended approach in object oriented programming, however providing a single function is simpler if appropriate, and a point usually missed is that interfaces, unlike base classes, give the module writer no chance to restrict and control how any of the functionality is provided, which could cause issues. Totally abstract class parameters (interfaces or fully abstract base classes) The client code uses class inheritance to create a subclass which inherits data and some methods from a parent class in the module, adding or changing some methods and adding data as required. Nice to use where there is a hierarchy of more specialised related classes, it can get complicated to manage and so is discouraged by many writers. Partially abstract class parameters (implementation inheritance) In fact there’s not a lot of difference between these in fundamental terms, they are all different ways of injecting client code into the module. In a functional language, you only have the first. In an object oriented language, you have all three (the first may be more or less awkward to do depending on how well function variables are implemented). Hopefully this article provides some pointers as to looking again at the way you close your code against the need to change and open it to be adapted and reused, as success in this area can reap great dividends in maintainability and efficiency. The previous article in this series on the Single Responsibility Principle is at . https://hackernoon.com/you-dont-understand-the-single-responsibility-principle-abfdd005b137 The next article in this series on the Liskov Substitution Principle is at . https://medium.com/@jim_ej/the-liskov-substitution-principle-and-why-you-might-want-to-enforce-it-6f5bbb05c06d Twitter: @jim_ej

Why the Open Closed Principle is the one you need to know but don’t

Scientific American Supplement, No. 717, September 28, 1889, by Various, is part of the HackerNoon Books Series. You can jump to any chapter in this book . EARLY ELECTRIC LIGHTING. here EARLY ELECTRIC LIGHTING. The opening of the new station of the Electric Lighting Co., of Salem, Mass., was recently celebrated with appropriate festivities. Among the letters of regret from those unable to attend the opening was the following from Prof. Moses G. Farmer: "Eliot, Me., Aug. 5, 1889. " : To the Salem Electric Lighting Company, Charles H. Price, President "Gentlemen: It would give me great pleasure to accept your kind invitation to be present at the opening of your new station in Salem on the 8th of this present August. "It is now thirty years since the first dwelling house in Salem was lighted by electricity. That little obscure dwelling, 11 Pearl Street, formerly owned by 'Pa' Webb, had the honor to be illuminated by the effulgent electric beam during every evening of July, 1859, as some of your honored residents, perhaps, well remember. Mr. George D. Phippen can doubtless testify to one or more evenings; Mr. Wm. H. Mendell, of Boston, can also add his testimony; dozens of others could also do the same, had not some of them already passed to the 'great beyond,' among whom I well recollect the interest taken by the late and honored Henry L. Williams, Mr. J. G. Felt, and I do not know how many others. I well remember reading some of the very finest print standing with my back to the front wall and reading by the light of a 32 candle power lamp on the northernmost end of the mantel piece in the parlor; very possibly the hole in which the lamp was fastened remains to this day. In a little closet in the rear sleeping room was a switch which could be turned in one direction and give a beautiful glow light, while if turned in the other direction, it instantly gave as beautiful a dark. My then 12 year old daughter used to surprise and please her visitors by suddenly turning on and off the 'glim.' It is not well to despise the day of small things, for although the dynamo had not at that date put in an appearance, and though I used thirty-six Smee cells of six gallons capacity each, yet I demonstrated then and there that the incandescent electric light was a possibility, and although I innocently remarked to the late Samuel W. Bates, of Boston, who with his partner, Mr. Chauncey Smith, furnished so generously in the interest of science, not wholly without hope of return, the funds for the experiment, that it 'did not take much zinc,' and though Mr. Bates as naively replied, 'I notice that it takes some silver, though,' still it was then and there heralded as the coming grand illuminant for the dwelling. I am thankful to have lived to see my predictions partly fulfilled. "During the early fifties I published a statement something like this: 'One pound of coal will furnish gas enough to maintain a candle light for fifteen hours. One pound of gas (the product of five pounds of coal) will, in a good fishtail gas burner, furnish one candle light for seventy-five hours. One pound of coal burned in a good furnace, under a good boiler, driving a good steam engine, turning a good magneto-electric machine, will give a candle light for one thousand hours. But if all the energy locked up in one pound of pure carbon could be wholly converted into light, it would maintain one candle light for more than one and a half years.' "So, gentlemen, ; there is still room for improvement. Let your motto be 'Excelsior.' Possibly you may have already extracted from one-fifteenth to one-twelfth of the energy stored in the pound of carbon, but hardly more. Go on, go on, and bring it so cheap as to reach the humblest dwelling when you shall celebrate the centennial of the opening of your new station. nil desperandum "I do most sincerely regret that I cannot be with you in the flesh. I am, like Ixion of old, confined to a wheel (chair in my case), cannot walk, cannot even stand; hence, owing to the impairment of my understanding (???), I must wish you all the enjoyments of the evening, and gladly content myself that you have made so much possible. "Very truly yours,   Moses G. Farmer." About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Various (2006). Scientific American Supplement, No. 717, September 28, 1889. Urbana, Illinois: Project Gutenberg. Retrieved https://www.gutenberg.org/cache/epub/17755/pg17755-images.html This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at , located at . www.gutenberg.org https://www.gutenberg.org/policy/license.html

8TH LIGHT

8thlight.com

51-200 employees

Since 2006

COMPANY RANKING

8TH LIGHT

EVERGREEN INDEX #876

Representing this company? Click here to claim and customize this page!

8th Light WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

8TH LIGHT

8thlight.com

51-200 employees

Since 2006

COMPANY RANKING

8TH LIGHT

EVERGREEN INDEX #876

RELATED COMPANIESRANK

STORIES ABOUT 8TH LIGHT

Representing this company? Click here to claim and customize this page!

8th Light WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!