Broad question

[atari-monk]

I wrote my db apps using Entity Framework Core and cli CommandDotNet
I like the way it turned out
It's nice to use commands and also it;s relativly easy to do integration test of whole app
However i think there is only one tech nowadays that really works
that is web apis
You just need them as backend and then clients can be whatever for whatever device.
Unfortunatly till now i build couple of small apis doing tutorials only.
Can you please comment on that.
Is my thinking about web apis beeing base layer in app tech correct ?
I think i should do web api first layer.
And from that commandDotNet could be use to build clients.
Taht is a natural progression in this ecosystem i think.

[drewburlingame]

It really depends on what your needs are. In most cases, you'll want your business logic for a domain to live in one place. If you want to expose that logic via network API so it can be accessed by other applications, then I would usually expose the logic in the API and have console apps call the endpoints.

There are many benefits to this approach

• If the domain logic changes, only the API needs to be updated and deployed.
• You may be able to take advantage of auto-scaling and a console app could take advantage of that by parallelising requests to the API.

There are some reasons not to move commands behind an API

• If you have a long running business operation, you'll need to divide it into smaller steps and orchestrate the work to avoid timeouts on the server and client. This is a good practice, but if you're writing small apps or prototyping, it may not be worth the extra work.
• Some operations may be risky to expose via API unless you're confident about security. Schema migrations are common example of an operation that you may not want to include in the API. Schema migrations require elevated db perms.
• Sometimes you just need a tool to run in your CI/CD chain. Schema migrations could be another example. It's simpler to run the console command than spin up a new API, wait for it to initialise and then call it.

There have been cases where I would make the domain logic available to both the API and the CLI and my deployment process would deploy both at the same time so I didn't worry about business logic being out of sync between them. There are risks if the commands run for a very long period of time though.

Those are some off-the-top-of-my-head thoughts on it.

[drewburlingame]

if you've got an API, generate OpenAPI from it and then use a tool to autogenerate service clients. Then your CLI can use the service clients.

[atari-monk]

Yes excactlly, domain logic, then one can use it with CLI and APIs, docker, message busses, these services for messaging that Les Jackson showed in his tutorial. I think my problem lies with productivity issue. I just get to less done for my taste. I am not doing this for job or anything really. Just wanted to get some databases filled with my data. My progress and even time invested in this is lacking.
I prolly should use ready apps like below
https://inventree.readthedocs.io/en/latest/start/intro/
My goals where to ambitious. I should start with one table. Write cli with tests for that. Than API.
This would be educative.
Instead i have bloated projects that i will prolly have to abandon and discust when i would need to configure something in docker.
I am happy i got this out, becouse i think i know what to do.
I must unfortunatly leave my db apps as is.
It's not first time i got lost.
Start new project with same goal, but where there is only one table
so i can build dao fast, cli fast, tests fast, tables fast, api fast.
And collect data with ease. Then if i chose so i may add to that.
Shame i see that so late. At least i got some blocks to do it from.
Thank you. Your answear helped me collect my thinking.
I am not gonna prettend i am capable to do that cli generation you mention but i will try when i will have first endpints.