by pmdfgy on 1/23/25, 3:30 PM with 26 comments
I've been able to achieve this by relying on TypeScript, a 4-layer architecture (UseCase => App => Product => Target) and dependency injection.
This mechanism allows me to use whatever tech stack I want, provided the good adapters are developed. For instance, I have pre-built ones : node express (server), next.js (server), node hono (server in alpha), node parseArgs (CLI), node stricli (CLI), react-web-pure (web with no CSS), react-native (mobile), node mcp server (anthropic MCP in alpha), etc.
The same goes with data storage : Postgres, SQLite, a txt file, whatever.
It also comes with auto testing and auto documentation.
Did I reinvent the wheel ? Probably on some aspects. Is it too much abstraction ? Probably as well. But I like the idea of modularity and portability.
That's why it's not made for everyone, nor all types of projects.
If you like testing new stuff, give it a try and feel free to ping me if needed, I'd love to help.
I'm aware the documentation is not state of the art yet. I wanted to focus on the "Getting Started" Guide to give a quick overview instead of going to deeply into the details.
Best,
by gr4vityWall on 1/23/25, 5:17 PM
I feel like you could describe the abstractions you built in more detail. When I read the explanation for what the 'UseCase', 'App', 'Product' and 'Target' were, it wasn't clear how each of those translates to TypeScript. My guess is that 'UseCase' and 'App' would be like Classes, if you're modeling your program in an OOP way? The 'Product' seems like it would be the TypeScript project itself, with the package.json, source code and all of that.
I would rethink how you named the 'App' layer. The examples given ('auth', 'accounting', etc.) are not necessarily what I would call an 'app'.
As you introduce names and concepts for things in your library, I recommend trying to keep the cognitive load as low as possible. It seems like there are a very high amount of high-level concepts and implementation details like types, functions, etc. that 1. are specific/unique to libmodulor and 2. you need to learn before you can start actually building your application, from looking at the examples. The barrier to give it a try in a side project seems really high.
Building things is cool regardless :) I'm happy that you built something it's useful to you and that you got to share here.
by pmdfgy on 2/1/25, 6:26 PM
It includes a simple react-native target to show how to do it. To make things easier to understand, I've also revamped the documentation, added a Guide to create your own target and enhanced the Tutorial with a RN target.
Finally, I've added the Tutorial code in the repo for whoever wants to browse it without necessarily performing all the steps.
Thanks a lot again for your feedback. My email is open :)
by tomhallett on 1/23/25, 4:08 PM
But I’m still a bit confused on what the project actually “is”. I see you have an architecture and I’m using ts to define the interface between those 4 types of components. But let’s say I have a react-native target: what am I expressing in that interface? A cli which can build/deploy that interface? Each ui screen in that rn app (rn login, rn add contact)? Or all of the api endpoints in the web target which gets called by the rn target?
In the readme, I would focus a bit less on the UML part, and a bit more on the “if I have a webapp and a mobile app, with auth and crud for contacts, here’s what you’d need”
by bjacobso on 1/23/25, 4:25 PM
It might help you implement some of these ideas
by yasserf on 1/23/25, 4:31 PM
I build something similar (vramework.dev), actually on my way now to give a talk on it
Got a presentation for it at presentation.vramework.dev if anyone is interested
by 0x20cowboy on 1/23/25, 5:35 PM
I apologise for being off topic, but I really want “an opinionated X” to stop having some kind of positive connotation to junior devs.