krok VS go-structure-examples

Booting up a database in a container is relatively fast now-a-days. Take a look here: https://github.com/krok-o/krok/blob/main/tests/livestore/init_test.go

An example for this you can find here: https://github.com/krok-o/krok/tree/main/pkg/krok/providers/handlers

Tests!!! You have none. :) If you want to test with a real DB instead of mocking everything you can do that with an ephemeral container that spins up relatively fast. Here is an example for that: https://github.com/krok-o/krok/blob/main/tests/livestore/init_test.go ( This might be a bit over your head depending on your experience maybe this post is better: https://docs.docker.com/language/golang/run-tests/ )

As others suggested, using the API is nicer. If you are looking for a nice example on how to do that take a look at my docker container executor code here: https://github.com/krok-o/krok/blob/main/pkg/krok/providers/executor/in_memory_executor.go :)

Here is an app where I'm using swagger and I create API documentation by using swagger generator and comments: https://github.com/krok-o/krok

I would like to present a project I've been working on for 1.5 years or so, called Krok Github, Krok Website.

Here is a fairly complex project which does just this: https://github.com/krok-o/krok

Adding to the other comments, this is how Krok uses swagger:

This creates a temporary database in a docker container while you are running your test. For an example look here: https://github.com/krok-o/krok/blob/main/tests/livestore/init_test.go

I have a question, I am trying out hexagonal architecture for one of my projects trying to follow this repository example and I ran into a slight problem.

Just fyi, that repo is NOT considered standard, and in fact, is often advised against. The structure of your code should depend on its complexity and how interoperable with other projects you need/would like it to be. I suggest watching this talk on structuring your code and taking a look at this companion repo to decide which will be the best way to structure your code, depending on your needs

Kat Zien's excellent talk, presentation and code samples can be found here.

Thanks for the video, I'll take a look at it. And I checked the repo, I liked how the new is structured: https://github.com/katzien/go-structure-examples/tree/master/new

So here’s where I normally tell people to start off: check out this video and this repo in regards to the main 6 ways of architecting your Go applications.

Watch this and give this repo a look.

Am I completely fumbling it by approaching this the wrong way & if so what should I do differently? I have searched a few repos like this which redefines the same entity in multiple places which I feel is a violation of some sort, and this which the author had to resort to moving some files outside to overcome a circular dependency (see comments inside their handling.go file).

Really surprised I haven’t seen katzien/go-structure-example and her GopherCon 2018 talk about structuring your Go projects mentioned yet

Let's agree to leave the MVC model for OO languages. A better architecture would be something like katzien/go-structure-examples