Architecture proposal

[elmoritz]

I have done a few private projects with Hummingbird and I would love to get a better understanding of how to actually organize your code and modules in a typical server-project.

All the examples are mixing everything into on method there is no Separation of Concerns (SoC).

I think it would help a lot of people who look into the examples to find some kind of example for a feasible architecture. Not to say that this is the ultimate standard, but to have a guideline on how to piece all the different services together.

I started with this, but to connect everything it is quiet hard.
Levels going from top to bottom:

• App(s)
• Domains/Features -> endpoint implementation
• Services -> Layer between the Endpoints and the Repositories for transforming data
• Repositories -> basically only data storage of any kind or external data sources

Since Services most-likely have to be shared between Domains/Features I always come back to some kind of Dependency-Object that holds all my dependencies during the creation process.

Same issue with Repositories especially if they use some kind of httpClient that is shared to call external APIs.

This is at least what I found out so far, but the dependencies-Object builds all the different services and repositories so that the setup process of the Application can use them easily.

Any Kind of help with this is much appreciated and an Example would be very helpful for future Hummingbird enthusiasts.

[adam-fowler]

Hi,

One of the points of Hummingbird was to leave the architecture design open.

The examples are there to demonstrate individual features or provide guidance on how to interact with another service. They are not demonstrations of a "standard" Hummingbird architecture.

I understand where you are coming from though. It might help people coming new to the framework.

Personally I don't like the large dependencies object: a big global that holds references to all your dependencies. It makes initial development easier as you can just pass this one object around, but it also hides a lot of information. By being explicit about which dependencies a controller/repository uses you provide useful information about it. Also if you pass in the dependencies individually it makes testing them much easier. Another solution people use is the https://github.com/pointfreeco/swift-dependencies library. Although I find pointfreeco libraries frustrating as they drag you into their ecosystem by including so many of their other libraries as dependencies.

[elmoritz]

@adam-fowler to the rescue again.
Thank you for all your contributions.

I might not have been as clear as possible.
I created an object which builds the dependency tree just because the services and repositories are depending on each other and I don't want to recreate them all the time.
I do pass them into the controllers individually, because of testing as you mentioned.
I was just wondering if there would be a better way.

I have a few services that need a httpClient, which I don't really want to create more than once, but maybe that is my iOS-brain talking.

Any pointers are much appreciated.
As you said I don't want to specify an architecture just some pointers on how it might be done.