Proposal: Add optional layer for infrastructure service #818
Replies: 2 comments 2 replies
-
|
Hi, thanks for writing up this proposal! It's definitely an interesting one and I agree that the current solution proposed by FSD is less than optimal My main doubt is regarding consistency. If Another thing I'm worried about is — how many slices will a typical application have in this layer? You listed a bunch of examples of things that could go inside that layer, but an application develops over time, so there might be a long period where there are only 1-2 services, which might not justify an entire layer. Maybe we can do it so that services are segments in |
Beta Was this translation helpful? Give feedback.
-
|
Hi, thanks for the feedback!
Regarding consistency, I agree that this layer would be better placed at the global level (like the other layers). However, I believe it still belongs to the shared part of the application (since local services can be kept within the corresponding slice). From this perspective, it makes sense to keep it inside
I totally agree that this layer will probably only be necessary for a small number of projects, and at the early stages it will likely be unnecessary. I also agree with the idea of keeping infrastructure services as segments within shared until there are enough of them to justify creating a separate layer. In fact, I probably wouldn’t include this layer in the base recommended version at all. Instead, I’d treat it as either an experimental feature or include it in the methodology as part of an advanced usage section (which could later also include examples of expanding into a fractal architecture, the @x feature, and so on). |
Beta Was this translation helpful? Give feedback.
-
|
First of all, I am not sure examples really show issues, because I definitely would not do this in any case because it's the opposite of what we expect from fsd, and it's more about horizontal slices. In this particular example, in my opinion, all theme files should be located in ui/theme, there is no reason to distribute them. The same approach can be applied for most of cases like this. The question is rather how to properly organize the internal structures when you are doing this. Anyway, I've already used the same approach in my projects as suggested, like and this works well. As @alright said, there may be inconsistencies with other parts of the shared, but I personally don't care about this, because in my mental model it still works well as part of shared, as well as other specific parts that you can involve in your project, like the shared kernel. The main thing is not to create new layers for everything that you don't know where to put it. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, thanks for the feedback.
I completely agree with this. It’s not what we typically expect from FSD, but I occasionally see projects that split infrastructure in this way. There are even some examples like this in the showcase: https://feature-sliced.github.io/documentation/examples examples
I think all examples are valid, but this difference in implementation occurs because there is no single place to host common infrastructure services. And everyone does it their own way.
This might be a valid solution, but as far as I know, according to the methodology, we cannot nest segments within other segments. @illright, what do you say about this? 📂 shared
📂 ui // segment
📂 theme // like a slice not allow right now
📂 model
📂 lib
📂 ui
📄 index.tsMaybe it’s worth considering in this way and allowing the creation of nested slices... here they go again :)
That’s actually how we started working at first. Some infrastructure services were placed in
I completely agree with you. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Overview
Hi! I'd like to revisit an idea I’ve frequently shared at meetups and which we’ve successfully implemented in one of our production projects. The proposal is to introduce a separate layer for infrastructure entities (infrastructure services, then just services).
Definition
By infrastructure services, I mean entities that are not part of the business logic but provide the technical foundation that supports and enables business logic. Each infrastructure service would be structured as a typical slice, including common segments (such as
model,ui,lib,apiand others).Examples
Typical infrastructure services might include:
Current Approaches (and Their Problems)
So far, I’ve identified three approaches, all of which present significant challenges:
1. Distribute Services Across Existing Shared Segments +
app/providersExample:
Cons:
2. Distribute Services Across
shared/lib/*Pros:
Cons:
3. Use Custom Segments in
shared/*Pros:
Cons:
api,ui,lib,config).steiger) prohibit certain segment combinations (e.g.,uiinside shared segment).Proposed Solution
Introduce a New Layer: shared/services
Formalize infrastructure services as a separate optional layer, which contains first-class slices.
Example:
Advantages:
Potential Challenges:
shared/servicesfromshared/lib.steigerConclusion
Introducing the
shared/serviceslayer offers a scalable and maintainable solution to properly structure infrastructure services, while aligning with FSD principles.What are your thoughts on this approach?
Beta Was this translation helpful? Give feedback.
All reactions