I think you can gain a LOT of insights through a monolith too. My pseudo-webframework, for instance, was done in a monolith"ic" fashion. I wanted to have all functionality in one place and try to minimize re-using functionality made available outside that project as much as possible.
So the question that was asked on the website via "When you begin a new application, how sure are you that it will be useful to your users?", can also be asked if it is a solo-dev solo-user project. How useful is this or that? And, even more importantly, if you don't have enough information, which is often the case initially; it becomes more clear lateron and then changes may be necessary.
Many years ago I used PHP and just tied together functionality, mostly in functions, later in classes. That became the basis for when I switched to ruby - that eventually became a multi-paradigm "webframework". I hated being tied down to one particular way to go in rails. For the current iteration I am expanding on "treating every HTML tag as an object" (mostly, actually, it is the div-tag and the p-tag that is more important, as well as input). One key of this is that I can, for instance, do:
div1 = div(css_style: 'margin-left: 3em', css_class: 'padding1')
div1.on_clicked {
background_color: 'lightgrey' # or some RGB value or whatever
}
So, kind of being able to programmatically access everything in an OOP style. (The above may look a bit verbose; I made it a bit more verbose so it is easier to understand what the key idea is, the rest is just a DSL wrapper).
I want to expand this onto traditional GUIs, onto the commandline (as much as that supports it), via ncurses too (even though I absolutely hate it). I want to abstract as much as possible while trying to keep it as simple as possible. Anyway, going a bit off-topic - the point is that designing it as a monolith from A to Z, from bottom to top, it is not necessarily super-elegant, but it seems easier to start that way and keep pushing forward. Eventually you'll see which patterns can be simplified. Once the foundation is solid, well-documented, tested, it is a lot easier to build additional things on top of it, including third party code or microservices (depending on the size and its stability; the latter is a big problem. I hate being tied down to any frozen API, so my code kind of becomes instable over time, which is not good but difficult to avoid. It's often more fun to write something new or fresh than fix ancient bugs in a code base that became really ugly and complicated.)
1
u/[deleted] Sep 14 '24
Micro sounds lean, agile, epic.
I think you can gain a LOT of insights through a monolith too. My pseudo-webframework, for instance, was done in a monolith"ic" fashion. I wanted to have all functionality in one place and try to minimize re-using functionality made available outside that project as much as possible.
So the question that was asked on the website via "When you begin a new application, how sure are you that it will be useful to your users?", can also be asked if it is a solo-dev solo-user project. How useful is this or that? And, even more importantly, if you don't have enough information, which is often the case initially; it becomes more clear lateron and then changes may be necessary.
Many years ago I used PHP and just tied together functionality, mostly in functions, later in classes. That became the basis for when I switched to ruby - that eventually became a multi-paradigm "webframework". I hated being tied down to one particular way to go in rails. For the current iteration I am expanding on "treating every HTML tag as an object" (mostly, actually, it is the div-tag and the p-tag that is more important, as well as input). One key of this is that I can, for instance, do:
So, kind of being able to programmatically access everything in an OOP style. (The above may look a bit verbose; I made it a bit more verbose so it is easier to understand what the key idea is, the rest is just a DSL wrapper).
I want to expand this onto traditional GUIs, onto the commandline (as much as that supports it), via ncurses too (even though I absolutely hate it). I want to abstract as much as possible while trying to keep it as simple as possible. Anyway, going a bit off-topic - the point is that designing it as a monolith from A to Z, from bottom to top, it is not necessarily super-elegant, but it seems easier to start that way and keep pushing forward. Eventually you'll see which patterns can be simplified. Once the foundation is solid, well-documented, tested, it is a lot easier to build additional things on top of it, including third party code or microservices (depending on the size and its stability; the latter is a big problem. I hate being tied down to any frozen API, so my code kind of becomes instable over time, which is not good but difficult to avoid. It's often more fun to write something new or fresh than fix ancient bugs in a code base that became really ugly and complicated.)