pmdfgy

What if we made a mistake by introducing and generalizing the concept of the "Controller" ?

They are boilerplate, they spread logic in multiple places and last but not least, they make testing very cumbersome.

No, nothing to install on your server. Everything is done via SSH from your phone and the server, there is nothing in-between. When you first SSH into the server, the key is stored in your keychain and reused for these operations. This way, you don't have to enter it everytime, but it's still safely stored.

You did a really great job describing the project and documenting it in the README. Congrats. The project looks super clean and professional.

That being said, TBH I don't see any real scenario where I would "prototype a CLI". Unlike a GUI where elements can be placed in some places vs others, a CLI is a CLI.

For any developer, it would probably take less time to write it directly using one of the libraries listed here : https://bloomberg.github.io/stricli/blog/intro (TS/JS) or https://github.com/spf13/cobra (Go) with stub implementations for commands.

The main problem for me is that defining the CLI in a JSON file lacks all the flexibility of code (reusability, etc.).

Based on your feedback, I've released v0.4.0.

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 :)

I like the idea of using one's native language and Portuguese is not far from mine so I kind of understand the README. But unfortunately, it is what it is, providing it in Engligh would probably make it more accessible to the HN community.

Let's take the first example here : https://ui.shadcn.com/docs/components/dialog. In this case, you have only one UC named EditProfileUCD, with the following input => name: PersonFullname and username: Username. All the things related to "UI" are not use cases since they are specific to a GUI target. A good tip to see if something is a UC or not : it should be available on all platforms. Opening a dialog in a Terminal is not for instance.

To continue with this example, you would add a <UCEntrypoint uc={uc} /> in your webpage, referencing EditProfileUCD. According to the client policy defined in the UCD and the UC auth, the button "Edit Profile" will show up or not. You can also simply disable it.

And your Dialog would render a <UCPanel uc={uc} /> that will display the form based on the UC input. Check out the contract of UCPanel (https://github.com/c100k/libmodulor/tree/master/dist/esm/tar...) to see how you can design the form and the form fields. Ideally, you would design these only once, and use <UCPanel uc={uc} /> across your whole codebase.

said in another way: many of the people on HN have a backend api, a react SPA, and a mobile app. what types of problems do i have now which libmodulor solves?

In this typical architecture, you would benefit a lot from libmodulor. All your business functionality would be expressed as individual use cases, organized in apps corresponding to your business domain. You would have a server target (backend api), a react-web target (react SPA), a react-native target (mobile app). Each of them will bind the appropriate things in their container. The API endpoints will be automatically mounted in your backend API. They correspond to UCDs having a server lifecycle. Adding a <UCPanel uc={uc} /> in react web or react-native will render the same UC for each platform and submit it automatically to the server, without you having to do any plumging whatsoever. You are totally free to expose a UC in web but not in react-native.

do i get a mono-build-system, where everything flows together and i just say "libmodulor build" and "libmodulor deploy" and I'm good to go?

This is clearly an important part that is non-existent at this time. For my own products for instance, I deploy each based on the target used (push on a PaaS for a server target, webpack/vite for a web target, fastlane for a react-native target, etc.)

If you have some time, I highly recommend to follow the "Getting Started", showing you how you can multiply the targets, re-using the apps as is.

Thanks a lot for your questions, they help me a lot to see where I fail to explain and how I can simplify things.

it wasn't clear how each of those translates to TypeScript

That's a fair point. I will add more details on how each of these notions translates to TypeScript. Quickly :

  - UseCase : a file containing the use case definition
  - App : a directory with a use cases folders and metadata (i18n, metadata)
  - Product : a directory with a apps folders and metadata (i18n, metadata)
  - Target : depends on it by for a GUI it's the screens where use cases are injected

I'm not a huge fan of this name either, but couldn't come up with something better at this time. `Module` seemed to broad to me. Although the notion is not totally clear to you, do you have any ideas in mind ?

I agree that it's not as straightforward as other solutions at this moment. I'll keep working and improving this to reduce the time needed to get started.

I'm not sure there is a relation between a program/library to be "opinionated" vs the skillset of the person who created it.

In my case, I'm using the word because the library defines a set of rules and conventions to follow. They are indeed based on my experience.

Are they perfect ? Probably not. And I'm totally open to review them if I missed things. That's how we all learn. Like any model (in a mathematical way), it is an approximation of the actual problem.

Looks great, will have a look at it.

Thank you for your feedback, I really appreciate.

Let's say you want to create a product with auth and crud for contacts. You'll have a SignInUCD, a CreateContactUCD, a AddPhoneNumberToContactUCD, etc.

As you said, your react-native target will define the UI screens. You are free to design them the way you want as the library does not make any assumptions about the UI/UX. In every screen where you want to "inject" a use case, you'll use the `useUC` hook and `<UCPanel uc={uc} />` (see https://github.com/c100k/libmodulor/tree/master/dist/esm/tar...). See also https://github.com/c100k/libmodulor/blob/master/docs/getting.... It explains for web, but the mechanics are the same.

Since react-native expects `<View>`, `<Text>` and not `<div>`, etc. you'll also need to define your "design system", like it's been done here for example : https://github.com/c100k/libmodulor/tree/master/dist/esm/tar.... Basically, you need to define how you want a use case form to be displayed, etc. When in web we rely on `<input>`, in react-native we'll rely on `<TextInput>`. And of course, according to the data type, you can display a specific form control.

I realize it's super hard to explain and I'm not clear enough but hopefully I'll find the best way to express it.

Given the fact that a persona with [name, phone number, birthdate] can be sold for more than $10 to data brokers and marketers, the economics are actually pretty good.

Congrats on launching. Looks very clean.

The main problems I have with these kind of solutions are :

- Having to make an HTTP request to get a variable (or multiple ?) for my local function to do its job. And that's a clear no-go for me, in terms of latency

- Having variables stored "somewhere else" complexifies the rollout of new features introducing new "variables", as one needs to update the external tool (here Varse), to create this variable

- Overtime, you end up with a big bag of obsolete variables that are not used anymore by the main application because you forget to remove them

The usual combo "Environment Variable / Restart" proposed by most PaaS offerings will be hard to fight IMO.

In any case, good luck with this project.

So you are basically selling `StripeController`, `gem 'devise'`, `adapter: postgresql`, `gem 'tailwind'` for $50 ? What a bargain.

I'll defintely give it a try when I can but in the meantime I wanted to congratulate and encourage you for the *simple* and yet very practical website presenting the project. It's so rare nowadays that it deserves it.

You can rename the project to "The most comprehensive authentication library for node" then.

I closed your Landing page after reading two adverbs ending with "lessly" in the same sentence, one being "seamlessly".

More seriously, I'm having a hard time understanding what differentiates you from Mailchimp and the email services, already provising such tools. The template notion is also a little bit confusing as I don't understand what an SMS template is, since an SMS is text only, with no layout. By the way, we can see the confusion in the "Templates" page, all of them being for Email, which is understandable.

Looks really nice and will give it a try on our codebase as an alternative to Winston.

Funny thing : one of the colleagues was unhappy when we proposed to define the logger as an interface, allowing us to switch implementation in one line. "We will never change the logger" he said...

    export interface Logger {
        debug(message: LoggerMessage, ...meta: unknown[]): void;
        error(err: Error): void;
        info(message: LoggerMessage, ...meta: unknown[]): void;
        trace(message: LoggerMessage, ...meta: unknown[]): void;
        warn(message: LoggerMessage, ...meta: unknown[]): void;
    }

Interesting for demo purposes. Do you plan to add authentication schemes ?

I think there are multiple reasons for that.

The first is an increased fatigue caused by some poor quality posts OR posts presenting the same thing again and again just by opportunism (e.g. boilerplates where people just share their thing as an Ad). Therefore, the trust has decreased and people start asking themselves "what's hidden behind".

Another reason might be related to the surge of cyberattacks of all kinds. Lots of comments here are not super nice, but they are polite and ask good and legitimate questions, especially regarding cybersecurity.

As long as people are polite, argumented criticism should be appreciated.

Linus Torvalds : Here is the Linux Kernel, powering almost all the servers around the world. It's complicated C, I've spent years of my life building it. You can get the code for free. Check it out.

Every indie hacker here : Here is my JS/TS class calling the Stripe API. You cannot see how it looks like, it's probably poorly structured code because all I do is hacking around following YouTube videos. It will be $12.99. Because I've seen this video of this guy with a mustache charging $99.99 for a few Next.js pre-built pages and services.

Sorry, but here is honest feedback. At least, to make things a little bit less obvious, take the time to write a proper README in the Git repo, instead of the default Tuborepo README.

In any case, good luck with your project.

You should include some examples of generated Private Notes on your website because like this, without knowing, I don't want to give you access to all my Strava activities.

Nice explanation and execution. Looks super Pro ! Congrrats !

One question : how do you manage database credentials ? That's a question I've had a lot working on my project so I'm pretty sure customers will have the same for you.

Especially given the latest Snowflake security issues.

It totally is. Take Notion for example.

This URL is displayed on your homepage, under the "2. Embed" section.

I don't know if your landing page is one of these growth/indie hackers thing, with nothing real behind, so I'll give you the benefit of the doubt (even though your video tells me the contrary).

But : curl: (6) Could not resolve host: script.faqpopup.com

The last thing someone wants to do is to inject some JS on their website without knowing what's in it.

Nice work. I really miss the simplicity of C. One file. One Makefile and that's it. Has anyone tested with a node_modules folder ?

No thanks. Looking forward to seeing this trend of awful CPU intensive landing pages disappear as fast as it arrived.

Nice job !

A small remark : since nothing is free in our world, it would be super cool if you could add the rate limits of each API. This way, we could see if it can be safely used in production or not.

Am I the only one who creates them manually and add an entry only when I see a file that should not be committed when I "git status" ?

I mean, .gitignore is a simple text file, editable from any tool. Why would anyone bother exporting such a file in JSON to then add it as a text file to a repository ?

I'm sorry, but I don't see any actual usage for this. There is no point in having a bloated .gitignore with things you don't even use.

I like the idea of the snippets popping out along the way. I would clearly use it for my website (https://trekstories.c100k.eu).

Another good use case I see, is for race organizers to showcase the route on their website. That would look more modern compared to the usual low-res screenshot. Something like this : https://www.youtube.com/watch?v=g5GjuRS9sVA