DEV Community: Pascal Dennerly

GSL: Because Your Architecture Diagrams Should Be Searchable

Pascal Dennerly — Tue, 07 Jul 2026 16:43:55 +0000

We’ve all been there. You start documenting a system with a simple "Box and Arrow" diagram. At first, it’s clean. Then reality sets in.

You need to show which components are in the public subnet versus the private one. You need to distinguish between synchronous REST calls and asynchronous events. You need to highlight which services are within the scope of a specific compliance audit.

Before you know it, your PlantUML or Mermaid file is a 500-line wall of text. The biggest heartbreak? Nothing ages faster than a PDF of a system architecture.

The Problem: The "Diagramming Tax"

I’ve spent a lot of time in the trenches of software architecture documentation. Tools like PlantUML are fantastic for simple graphs, but they have a breaking point.

The "niggles" start when you want to annotate a graph without affecting the layout, or when you need to represent a node that lives in multiple logical worlds. PlantUML doesn't really allow you to attach metadata to a component without the tool trying to "draw" that metadata.

More importantly, these diagrams are write-only. You can't ask a PlantUML file: "Show me the blast radius if this internal service is compromised." You just have to squint at the spaghetti and hope your brain can parse the connections.

Enter GSL: Architecture as a Queryable Model

GSL (Graph Selector Language) is an experiment in treating architecture as data first, and an image second. It’s born from a simple desire: I wanted a format that was easy to version-control, easy to diff, and—most importantly—easy to explore.

GSL splits the problem into two distinct parts:

The Language: A way to describe the graph and annotate nodes with "Sets" using a simple @tag syntax.
The Query Language: An orthogonal tool to filter that graph and extract specific subgraphs.

1. Modeling Reality with Sets

In GSL, nodes aren't trapped in a rigid hierarchy. A component can belong to as many "Sets" as you need.

node web @public
node gateway
node userService @internal @auth
node database @internal @datastore

user -> web # Implicit node creation for speed
web -> gateway
gateway -> userService
userService -> database

The @internal tag isn't just a label; it’s a dimension. You aren't restricted by how the graph looks; you're describing what it is.

2. Exploring the Noise

The real "Aha!" moment didn't come from writing the parser; it came from looking at a massive, generated architectural graph and realizing I couldn't find what I was looking for.

By using an orthogonal query language, you can strip away the noise. If you only want to see the "Internal" world and how it connects to the outside, you run:

subgraph node in internal traverse both all

The result isn't just a list—the output is another GSL graph. This composability is the core of the experiment. You can pipe, filter, and zoom in on specific architectural stories without ever touching a mouse.

Beyond Documentation: The "Gut Feel" for Refactoring

While GSL is currently in its early stages (v0.4.x), the vision goes beyond just making better Mermaid charts.

I have a strong gut feel that by representing architecture in a queryable format, we open the door to automated architectural insights. Imagine being able to programmatically detect "architectural smells"—unintended transitive dependencies or security policy violations—before a single line of infrastructure is even deployed.

It moves us away from "drawing pictures" and toward advanced refactoring for systems, supported by tooling that actually understands the relationships we've defined.

An Ongoing Experiment

GSL is a labor of love implemented in Go. I chose Go not because it’s a requirement for the language, but because it allowed me to quickly build a robust first implementation. I've used tools like Participle for parsing while challenging the implementation through rigorous testing to ensure it matches the mental model I had in mind.

It’s still an experiment, and the query language is evolving rapidly. But the goal remains the same: Your architecture diagrams should be as searchable as your code.

Explore the project: If you're tired of static diagrams and want to see a different way of modeling systems, check out the repo at github.com/dnnrly/gsl-lang.

Quitting early for the win!

Pascal Dennerly — Sat, 14 Dec 2024 01:01:16 +0000

Super short summary: Exiting your program when you get an error can be a good idea. Using gobail will make your life easier.

When you get an error in your Go code, you'll normally see something like this:

err := myFunc()
if err != nil {
    return fmt.Errorf("doing my thing: %w", err)
}

You'll notice a few things in this example:

You have to check whether there is an error
There is some text that will help diagnose the error
And the error is wrapped, passed back with the text

So what happens next? Well it all happens again. You check the error value, describe it, pass it back. And then it all starts again.

Why do we do this? Why all this effort?

Well it all depends on the software that you're writing. When you get an error, you have to make a decision. What happens to that error?

If you're writing an HTTP API responding to a request then eventually you're going to get to some kind of HTTP handler and you'll turn that error into some response - perhaps a little 400 with a polite reminder format their requests properly or possibly a 500 and a worrying message about the health of your application. Alternatively, if you're writing some kind of CLI tool then you might decide that the error will eventually get passed all the way back to your main function. For any kind of program, you might decide that enough is enough - the program should just end because you can't do anything else.

Let's look at this last option. When is it appropriate to just exit your program? Here's a few reasons that I can think of:

a. There's nothing else to be done, the error is so bad that everything has to stop right now
b. There are no consequences to terminating the program (no cleanup is required, no status to respond with)
c. Stopping early is desirable, perhaps you have a monitor that restarts the process cleanly

Whatever the reason, you need to consider how you're going to exit cleanly. Now the first thing you're likely to try is this:

err := myFunc()
if err != nil {
    fmt.Printf("doing my thing: %v", err)
    os.Exit(1)
}

It looks pretty similar to our original error handling code but with a couple of important differences. The first is kind of obvious - there's a honking great stop-right-g*****n-now statement there. Your program is not going to continue. The second point is perhaps more important. The code that is calling this sample doesn't have worry about handling any errors. There are no additional code paths that have to be tested - we can trust that that the calling code doesn't have an if block to test because there's nothing returned that we have to check.

Testing your exits

So I was being, perhaps, a little enthusiastic when I suggested you should just trust that your exit code is just going to work. You should probably check that the reason that you new program has stopped is for the right reason.

Attempt 1 - just run your program

This feels like it should be easy. Here's some things to consider - in the most easy case, you're just going to run your program and trigger an error condition. For example, get your CLI tool to open a file that doesn't exist. You can do this manually for a few simple cases. When the number of tests goes up, you'll probably need some kind of automation around it to help you.

Quick side note - this is probably the subject of a whole other blog post but my current favourite way of testing CLI tools uses godog to write tests. It can be a little complex but I've found it supremely powerful. Here are some good examples of how I've approached it with layli and wait-for.

This approach will get you very far but sometimes it can be difficult to create the conditions that will properly exercise all of the code paths that you want to be confident about.

Attempt 2 - mock out the exit

OK so now we're going to be using some of the features of the Go language. We don't actually have to call os.Exit - we can call something that looks like it. So look at this:

type ExitFunc func(code int)

var customExit ExitFunc = os.Exit

func myFunc() {
    err := someOtherFunc()
    if err != nil {
        fmt.Printf("doing my thing: %v", err)
        customExit(1)
    }
}

So how are we going to take advantage of this for our testing? As the function has now been turned into a variable (customExit) then we can replace the value with something else that we want to do. Like so...

package sameAsTheAboveCode

func TestOMGItsAllGoneWrong(t *testing.T) {
    oldExit := customExit
    defer func() {
        // Make sure we reset the exit so it can be used elsewhere
        customExit = oldExit
    }

    exitCalled := false
    exitCode := 0
    customExit = func(code int) {
        exitCalled = true
        exitCode = code
    }

    // Set up the mocks so that someOtherFunc returns an error

    myFunc()

    // Assume that we're using the fantastic stretchr/testify library here
    assert.True(t, exitCalled)
    assert.Equal(t, 1, exitCode)
}

This is a much more unit-test friendly approach. You can check that the exit code used is correct - and that you actually called the exit function.

On the surface, this looks great but there is one big problem - if your test passes, then you program will continue and execute the rest of the function when you expected it to exit. It will continue even though the test setup means that the rest of the execution is not valid and cause problems for your tests, such as causing panics.

Removing code to remove tests

Well, this sounds a bit extreme!

I feel like I should explain... Typically in "well managed" companies you need to make sure that every line of code has been proved to be working before if can be put in front of your customers. Using the above techniques you may not be able to generate the correct coverage metrics to attest that you're good. Even if it's trivial to reason about.
All of the examples above have assumed that when we get an error then we have to check it to decide what to do (Exit with vengeance). Wouldn't it be great if we were able to exit without having to check that there was an error?

Let's see what we can do.

func checkExit(err error) {
   fmt.Printf("doing my thing: %v", err)
   customExit(1)
}

func myFunc() {
    checkExit(someOtherFunc())
}

Take a look at the above example. The functionality is the same but the implementation of myFunc is much simpler now - there are no conditionals. We can check the implementation of the checkExit function in it's own tests, meaning that whatever is new in myFunc() can be much more easily verified.

Introducing gobail

A new libraray, gobail has been created that allows you to e confident that if there is an error then it will be handled without having to add complexity to your own code. It looks like this:

func myFunc() {
    gobail.Run(someOtherFunc()).OrExit("with message")
    gobail.Run(yetAnotherFunc()).OrExit("with message")
}

This library has been fully tested, with coverage metrics, to prove it. You can safely use it without having to worry that an error will be skipped. It will also handle functions with 2 return values, like so:

gobail.Return2(return2ValsAndError()).OrExitMsg("something went wrong: %v")

Notice as well that you an include the error that is causing all of your problems.

It's also possible to panic instead of exiting, printing our a stack trace and other contextual information from the program when the panic is invoked. Take a look at the docs for more details.

Isolating dependencies

As you write software with gobail, you will notice that you will mostly have to use it when talking to external libraries. This has the additional code that you typically need to write to handle all of the error cases can be wrapped in a call to Return or Return2 and assume that we will exit when necessary.

Conclusion

Sometimes it's desirable to exit your program instead of handling your errors in detail. The gobail library has been created and validated so that you don't have to worry about the detail of proving this.

If you find an improvement that could be made or just have a suggestion then raise a PR or an issue on the repo and the developers will get on it when they can!

Introducing Layli

Pascal Dennerly — Fri, 24 Nov 2023 22:20:15 +0000

This is a story about how my simple little alternative to PlantUML came about. Please check out layli if you just want to see the end result.

I've been an avid user of PlantUML for years. I love the ability to define my diagrams as code. Sequence diagrams, component diagrams - just define what connects to what and you have a diagram that you can put in git and render in to any image format you choose.

But.

BUT....

...very quickly, you find that your component diagrams end up looking a bit messy. So you use linetype ortho to get the straight lines with corners, rather than curves. Then you have to arrange the boxes around the page and you add hidden connections (-[hidden]-> and play with the line lengths (using --> and --->, perhaps even ---->). All of a sudden you discover that your simple diagram becomes a mess of crossing lines and kludges to separate the nodes so that it looks pretty.

So what to do? I love the ability to specify my diagrams as code. This works really nicely for sequence diagrams but my experience with component diagrams is often...disappointing.

A manifesto

I was frustrated with what I was working on and had a couple of insights. Surely there should be some simple guidelines that guarantee pretty diagrams? So I made some notes and eventually came up with this list or rules:

Edge paths must travel across a "path grid"
Node borders must be on the "path grid"
Edges must meet nodes at "ports"
Ports must sit on the "path grid"
Where a port is not specified, layli may select a "default" port on any side of the node
Nodes must be layed out so that the total area marked by the outside bounds of every node is as small as possible
Nodes must be seperated by at least 1 space on the "path grid"
Edges must must not cross!
Edges must follow a grid path (ie. not curved or diagonal)
Edges must be as short as possible
Edges must have as few corners as possible
Edge paths may sit on top of each other at the beginning or at the end

I think this is a reasonable start. It almost looks like a manifesto!

Getting started on Layli

After a little time prevaricating, I set out to clobber the keyboard a little and Layli slowly came in to being. The first thing I had to do was figure out how to arrange the boxes on my diagram (the nodes). I decided that the simplest way to do this was to just implement a primitive flow layout - just arrange them in to a square arrangement, row by column.

Next up, I had to draw connections between the nodes (edges). To do this, I looked back to an blog that I read a couple years ago that described using Dijkstra's shortest path algorithm to plot paths between nodes. I forget the details but this seemed to be an intriguing approach. After a little work, I had something that looked pretty decent:

After a little more work, I was able to implement some more features. A handful of different node arrangements alongside trying to shuffle the order that we draw paths so we don't get crossing lines.

There're more examples here.

What next

I've got a few items on my TODO list. Allowing you to specify nodes absolutely - giving them coordinates on your diagram, adding some styling, making the path-finding algorithm prettier. Who know's?

Maybe this is something that you'd like to contribute to? Just raise an issue or a pull request and I'd be happy to take a look!

Download layli and start using it now!

What will make me happy, as a #hacktoberfest maintainer

Pascal Dennerly — Mon, 05 Oct 2020 20:54:21 +0000

The original version of this appeared as a tweet thread a few days ago:
https://twitter.com/pascaldoesgo/status/1311799941791133697?s=19

Hey #hacktoberfest beginners!

I'm a very small scale maintainer and here are some things that you could do that I, personally, would value greatly! I suspect most maintainers would too. I personally look after 3 open source projects, essentially written to solve problems.

Shameless plug, here they are:

abbreviate

httpref

s3backup

As you can see, it's not much but it's mine.

Deciding on a contribution

First of all, I'd probably take a look at open issues on a project. A lot of projects will tag them with labels like help wanted or beginners. You can see quite quickly whether a project might have something they think is a good starting point for you. If you have an idea of what you could do to implement the change then just ask on the issue. I would happily spend a little time on feedback.

If you think you have an idea for an entirely new change that doesn't already exist then raise your own issue to discuss it first. This has been called "talk first" or talk then code development. It'll help me understand what's coming in. And help me to give you some guidance.

What changes can you make?

4 1-line puntuation changes in separate PRs is no help to anyone. I've had at 3 pull requests of this type already, including changes to the code of conduct and project license. The changes accidentally changed the legal meaning of the license text, moving it away from being the kind of project I want it to be. This is not cool!

Honest grammar and punctuation fixes are valued! If you've spent some time reviewing a README and you think you can make it better, then THANK YOU! I am a human and I old enough and had my ego punctured enough to realise that I make mistakes. All the time! If you spot something that you think isn't quite right the raise that PR.

Adding and improving documentation is the best contribution! It's the bit most developers struggle with. Usage guides, installation instructions, FAQs. These are great candidates for documentation changes that always seem to need more work. Certainly for me, if I'm intimately familiar with a tool or some code then I find it harder to understand what it takes to start using it. An outside perspective is actually a great asset for this kind of contribution.

Making that change

Now this section is more about my personal style of contributing. It's an approach when extending my own projects as well as at work.

First off open a draft PR early, fill out the PR template, make me aware of what you're doing. This achieves a few things all in one go.

Let's you use the CI/CD tooling where it's available. This depends very much on what the project is using to do their testing and deploying. It probably won't work for Github actions but might for Travis or CircleCI etc.
Makes me aware of an incoming change.
Gives me an opportunity to give you some early feedback for larger changes

I'm happy to review your code and help steer you if you don't feel confident or feel you just need some advice.

You don't have to be a confident developer to start coding. I remember my first attempts at code. I didn't know what I was doing for a long time. To be fair, I still make it up a little now. 😅

What you can expect from me

Be mindful that I have a full time job, small kids, a wife, people that call me on the phone, DIY, a laptop that we share amongst us.

I'll try to help you as much as I can but I can't promise to be totally on it all the time.

I will take a look at all changes that come in a few days! If you've spent the time to raise a pull request then I owe it to you to give it the proper amount of attention.

What I want you to get something from #hacktoberfest

Most importantly, have fun!

I mean a free T-Shirt is all very nice but I want you to enjoy what you're doing. You'll be more engaged and find it easier to contribute.

Ultimately #hacktoberfest is about building the Open Source community and joining in makes you a part of that.

Introducing Abbreviationist

Pascal Dennerly — Tue, 29 Sep 2020 22:19:38 +0000

Just a bit of blatant self promotion here. I've been playing with my little CLI tool abbreviate and wondering what I could do next. I also need to practice my very new front-end skills so I put together this site to meld the 2 things:

https://abbreviationist.herokuapp.com/

It's not much but after so many years hiding in the backend, putting up a simple site with my own HTML and CSS is a big deal for me.

If you have any comments or feedback then feel free to let me know. :)

Fun Coding

Pascal Dennerly — Sat, 28 Mar 2020 21:15:09 +0000

Fun Coding
/verb/

To develop code for ones own pleasure. This may or may not be related to your day job. Perhaps a side project, perhaps not. The principle is that it's for fun.

Rewarding Github contributions

Pascal Dennerly — Tue, 10 Mar 2020 21:00:43 +0000

So I'll probably be cross posting on Twitter or something but here goes...

How do you reward people that take the time to contribute?

I recently had someone fix a bug in httpref. No prompting, just a PR out of the blue that nailed the problem. I was shocked, and surprised, and so so glad that someone had taken the time.

Apart from a cursory 'thanks' when I hit merge and an impromptu shout out on Twitter I couldn't really do anything.

Is this something that anyone has been able to do? Just show someone how much you appreciate what they've done?

Discuss...

Learning Frontend as a Backend dev

Pascal Dennerly — Thu, 27 Feb 2020 22:10:47 +0000

Hey all, I thought I'd pull the community for tips on learning Frontend development.

I've been writing backend software in various forms for many, many years now. Even so, Frontwnd feels magical and scary.

It's definitely a skill I'm missing, but I wouldn't know where to start now.

Has anyone done this particular journey? Any tips?

THIS_IS_A_CONSTANT

Pascal Dennerly — Thu, 27 Feb 2020 20:18:13 +0000

A junior engineer asked a great question while we were pairing

"Why does this variable have to be in upper case?"

Well, because it's static final, of course.

But why?

So I had to think about this one and wondered why myself. What's so different? And why did people decide this was a good idea?

So the obvious difference is that because it's final, it can't be modified after it has been initialised. And it's static, meaning that it's a property of the class and not of this instance.

It's as close as you really get, in Java, to a const in other languages.

But, he asked, why does that mean we have to make it upper case with underscores? Won't the compiler tell us when you try to change it?

Well it's a convention that we used to tell us that we need to use this field differently, like we used to back in the old C days, and it's stuck from there.

But what was so different about C?

So there wasn't really the concept of a immutables for a while in C either. BUT we did have the #define directive. This told the compiler that the next thing it saw on the line would be a symbol that would be replaced exactly with the thing after that.

So you would see something like:
#define STR "my string"

When the compiler saw STR, it would literally replace that symbol with "my string" when it was processing that file.

It was important to know that you were dealing with something special, something that could break in REALLY weird ways! Anyone remember the old "end of file when ';' expected - but it's RIGHT THERE!"?

So here we are in 2020, writing Java variables with different case because it looks like a constant, because we have to know to treat it differently, almost with reverence, because of lessons learned in another language.

Same post at the top of my feed

Pascal Dennerly — Thu, 20 Feb 2020 23:51:55 +0000

Hey,

I signed up tonight and clicked on a post to see what it's about. But now that article, as important and insightful as it is, appears at the top of my feed and I can't figure out how to remove it.

Any suggestions?

Testing Go CLI Tools

Pascal Dennerly — Wed, 12 Feb 2020 21:08:19 +0000

Testing Go CLI Tools (part 1)

This has all started from a very simple tweet from Mat Ryer

I don’t use func main In #golang 😂

But seriously, I always make a new little “run” function and then immediately call that, passing in args and io.Writer for stdout etc.

It’s the easiest way I’ve found to make func main testable. https://t.co/8BQ0EEmU5x
— mat_ryer.go (@matryer) February 12, 2020

What is going on?

Interlude in to my testing journey

So I have a confession to make - I like testing my code. I read about it first in Joel Spolsky’s book “Joel on Software”. Unit testing was a thing that I did a little 20 years ago when I was writing C for mobile phones and then C++ for Windows applications (before there were Apps). There was no common unit testing framework that people always looked to, we just cobbled it together with what we had.

Then I moved to a company that did C# and discovered that there WERE frameworks for you to use. In this case, NUnit. Well, that was a revelation. Everything was tested, every code path and every combination of if statement. It was great to feel like your code worked!

Lets move forward a few years. Unit testing again in C++ with CPPUnit, meeting actual people whose full time job it was to test your software. I even learned some of the theory behind testing, passing a proper QA certification - ISTQB. Only the basic one mind, but it was a start. TDD became a thing that I tried and failed to do. Testing still involved all the code paths.

So now we arrive at the present day. I’ve become less bad. I do TDD before I’ve even created the file that the Production code will go in. I test behaviours and not implementation. Occasionally I even make it so I can refactor my code without needing to change the tests. I’m not so worried about getting all of the code paths checked multiple times but I still care when there are gaps.

Testing CLI tools

It’s actually quite hard to test everything in a command line tool. When you think about it, how is a Unit Testing framework going to help you to parse command line arguments? What happens when some of the output goes to STDOUT? What about STDERR? And how do we get any kind of code coverage statistics?

BATS

My first attempt at solving this uses a great framework called BATS. This is essentially a Bash based Unit Testing framework. You can use this to to make calls to you CLI tool and validate the output. You can see how I’ve done this in a couple of places:

goclitem: a simple, opinionated, Go CLI application template
abbreviate: a tool for abbreviating long strings (it’s a pre-cursor to goclitem, which is why the structure is a little different)

Here we can see that I’m building the tool and then actually invoking it, testing my expectations against the real fully built tool. It’s great. BUT…

We can’t check the code coverage
We can’t use the nice testing tools that Go and 3rd party packages provide

Calling `main()`

This was the next obvious approach. This didn’t work that well. There was none of the control offered by the regular unit tests but there was difficulty intercepting the output.

Using `run`

Now we get on to Matt Ryer’s comment. What is it trying to do? Essentially this allows us to have an entry point to the CLI without having be locked in to main. In part 2, I’ll dig in to how this is used.

Go Interface Generation

Pascal Dennerly — Fri, 26 Oct 2018 21:58:35 +0000

Go Interface Generation

I’d like to rave about a tool that I discovered recently. But first…a little history.

I’ve been working with Buffalo and enjoying it very much. It’s all there in front of you, in Go (my very favourite language) and it’s easy to take your service from the basic out-of-the-box template to adding your own domain models and business logic.

But I also have a background in Java of the Big Business kind. We’re talking full DDD and 3-tier applications in web containers, JCA components and fancy messaging solutions.

Now the thing I like about 3-tier applications is the strong seperation of concerns. Buffalo, as easy as it is, doesn’t have this same seperation. Buffalo deals with this by making strong use of integration tests using a full database implementation and utilities to manage database schemas and populating the database with data according to what is defined in your text fixtures.

In short, I want to be able to take the business logic out of the handler and put it in a repository that I can abstract away so that when I do my testing (first), I can make sure that I’m only testing 1 thing at a time.

How do we achieve this in Buffalo?

Well the obvious way is to move the logic for making queries against the database in to its own type, passing in the dependencies as members of this class. Stub out the dependencies - a route for validating outputs against the inputs that we insert.

Buffalo makes extensive use of the incredibly useful package Pop. Unfortunately, access to the database in this package is via the Connection type. It’s unfortunate because it is a struct, which means that we can’t just insert a mock version of it in to the units that we’d like to test.

To perform this injection of a mock, we need to create an interface that exposes each of the exported functions on the Connection type.

After a little searching, I found ifacemaker. This tools reads the struct and creates an interface that allows access to each of the exported functions on that type.

To run the tool, I did this:

ifacemaker --file ~/go/src/github.com/gobuffalo/pop/connection.go --struct Connection --iface DBConnection --pkg repo

This presented the following type:

package repo

// DBConnection ...
type DBConnection interface {
        String() string
        // URL returns the datasource connection string
        URL() string
        // MigrationURL returns the datasource connection string used for running the migrations
        MigrationURL() string
        // MigrationTableName returns the name of the table to track migrations
        MigrationTableName() string
        // Open creates a new datasource connection
        Open() error
        // Close destroys an active datasource connection
        Close() error
        // Transaction will start a new transaction on the connection. If the inner function
        // returns an error then the transaction will be rolled back, otherwise the transaction
        // will automatically commit at the end.
        Transaction(fn func(tx *Connection) error) error
        // NewTransaction starts a new transaction on the connection
        NewTransaction() (*Connection, error)
        // Rollback will open a new transaction and automatically rollback that transaction
        // when the inner function returns, regardless. This can be useful for tests, etc...
        Rollback(fn func(tx *Connection)) error
        // Q creates a new "empty" query for the current connection.
        Q() *Query
        // TruncateAll truncates all data from the datasource
        TruncateAll() error
}

We can now use this in our Go mocking tools - for example github.com/stretchr/testify/mock. But if we’re going to use a mock, we have to generate one. Here’s where we turn to mockery. The first time you use it - it’ll fail. This is because it doesn’t populate the package imports and package names (for example, Connection rather than pop.Connection). Fortunately this is easy to fix, giving this:

package repo

import (
    "github.com/gobuffalo/pop"
)

// DBConnection represents a Buffalo pop connection to a database
type DBConnection interface {
    String() string
    // URL returns the datasource connection string
    URL() string
    // MigrationURL returns the datasource connection string used for running the migrations
    MigrationURL() string
    // MigrationTableName returns the name of the table to track migrations
    MigrationTableName() string
    // Open creates a new datasource connection
    Open() error
    // Close destroys an active datasource connection
    Close() error
    // Transaction will start a new transaction on the connection. If the inner function
    // returns an error then the transaction will be rolled back, otherwise the transaction
    // will automatically commit at the end.
    Transaction(fn func(tx *pop.Connection) error) error
    // NewTransaction starts a new transaction on the connection
    NewTransaction() (*pop.Connection, error)
    // Rollback will open a new transaction and automatically rollback that transaction
    // when the inner function returns, regardless. This can be useful for tests, etc...
    Rollback(fn func(tx *pop.Connection)) error
    // Q creates a new "empty" query for the current connection.
    Q() *pop.Query
    // TruncateAll truncates all data from the datasource
    TruncateAll() error
}

The next time we run mockery, it magically works. Take a look at this snippet, if it compiles then you have yourself an interface over a struct to unlock your unit tests.

The following code should work, although you may need to fill in the blanks:


func AcceptConnection(tx DBConnection) {}

func TestMocks(t *testing.T) {
    tx := &pop.Connection{}
    mx := &mocks.DBConnection{}

    AcceptConnection(tx)
    AcceptConnection(mx)
}

If you get this far then you have all of the components needed to add a testable repository tier in your Buffalo app.

DEV Community: Pascal Dennerly

GSL: Because Your Architecture Diagrams Should Be Searchable

The Problem: The "Diagramming Tax"

Enter GSL: Architecture as a Queryable Model

1. Modeling Reality with Sets

2. Exploring the Noise

Beyond Documentation: The "Gut Feel" for Refactoring

An Ongoing Experiment

Quitting early for the win!

Testing your exits

Attempt 1 - just run your program

Attempt 2 - mock out the exit

Removing code to remove tests

Introducing gobail

Isolating dependencies

Conclusion

Introducing Layli

A manifesto

Getting started on Layli

What next

What will make me happy, as a #hacktoberfest maintainer

Hey #hacktoberfest beginners!

Deciding on a contribution

What changes can you make?

Making that change

What you can expect from me

What I want you to get something from #hacktoberfest

Introducing Abbreviationist

Fun Coding

Rewarding Github contributions

Learning Frontend as a Backend dev

THIS_IS_A_CONSTANT

Same post at the top of my feed

Testing Go CLI Tools

Testing Go CLI Tools (part 1)

Interlude in to my testing journey

Testing CLI tools

BATS

Calling main()

Using run

Go Interface Generation

Go Interface Generation

How do we achieve this in Buffalo?

Calling `main()`

Using `run`