How about adding some support for markers that I can put in my files that will cause generator to ignore them

[derberg]

Reason/Context

I'd like to use generator not only to scaffold my project when I start working on my application. I also want to use it continuously, every time I change something in AsyncAPI document.

The problem is that regeneration means basically another generation of the entire template. This leads to a process of regenerate -> carefully go through each change introduced after regenerating and ignore changes that will break your code

More context here.

Description

The solution from #581 covers entire files but there are still issues with files like https://github.com/asyncapi/nodejs-ws-template/blob/master/template/src/api/services/%24%24channel%24%24.js. There is some part of the code that needs to stay untouched, the custom logic that I add after project generation. Maybe we could have some markers, something to put in the code that would make generator ignore a given part of the file.

What do you think? some part of me says this is (marker) impossible and doesn't make sense, but then what are the other options? Do you know if there is some code generator that solved this challenge?

[jonaslagoni]

some part of me says this is (marker) impossible

It should be possible, just pre-process files and save the parts marked but it comes at a cost and this is IMO the wrong direction to take.

My 2 cents, don't mix generated code together with your own implementations. Instead interact with the generated code, provide an API developers can use to interact with, see it as a server wrapper instead of integrating custom code directly into the generated code. Of course, this approach is not without fault as well, but it removes the major pain point you have.

The long explanation why this different approach is better even for server code?

The same reason why we do not use this approach for clients
Because developers can more easily understand interaction with a separate library than if generated code are mixed together with custom business logic.

Following the examples from your blog post for src/api/services/travel-status.js

const service = module.exports = {};

/**
 * Client can receive travel info status.
 * @param {object} ws WebSocket connection.
 */
service.subTravelInfo = async (ws) => {
  ws.send('Message from the server: Implement here your business logic that sends messages to a client after it connects.');
};

A different approach, and the one I suggest. Is to generate the server in a separate library completely such as in libraries/asyncapi

Then we create our own implementation around this wrapper as such src/index.js:

cons webServer = require('../libraries/asyncapi');
webServer.service.subTravelInfo = async (ws) => {
   //Add what ever business logic you need here.
};

with JSDoc it is possible to generate the type signature for webServer.service.subTravelInfo to enable syntax highlight as usual.

Now I can control my own setup completely, the way I want to structure the processing of the callbacks, I can generate the library as many times as I want without conflicts.

Getting to know how to interact with a library is way easier than knowing what files I can change in a setup I have not created. Everyone working with these files (with the current setup) needs to know about the entire setup, with the index.js file they just need to know their own setup and then which functions they use to interact with the library.

Your pain point is the very reason why I do not like using server-generated stubs... Ever since I first encountered them with OpenAPI generator. Am I the only one feeling this needs to change? 🤔Or do you like the current setup? 🤔

That being said, this issue is not about a single template, but whether this feature makes sense... Yes, I can see the benefit of having such a feature, but I feel like we are enabling code generation that should be avoided in most cases. Especially when it comes to public templates.

[magicmatatjahu]

I cannot handle this issue, sorry 😅. @derberg What part do you want to left (from file https://github.com/asyncapi/nodejs-ws-template/blob/master/template/src/api/services/%24%24channel%24%24.js) in final file? Could you describe problem in another way?

[derberg]

@magicmatatjahu

What part do you want to left

None 😄 This is a template file, that results for example in something like this

Now, this is a service that has only "sub" function as my AsyncAPI file has only subscribe operation for travel/status. But in a week, I want to extend my file and add publish operation to my travel/status channel. Problem is that for now, I have to run a new generation, this file will be regenerated (not lost as of course git and all that stuff, so I can review what was regenerated) and my dev flow is that I need to basically manually review what was regenerated, revert, adjust, etc

[magicmatatjahu]

@derberg So finally you want left generated function for subscribe but then only regenerate template for "new" publish function? I wanna make it clearer to another people from community whose have concerns like me 😅

[derberg]

@magicmatatjahu yes, exactly like this. Problem is that I do not know how to do this 😄 I only know what is the problem 😄

[magicmatatjahu]

I added my 50 cents 😄 in this issue #581 (comment) describe the problems that we need to resolve.

[derberg]

s

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[derberg]

I'm closing for now, doesn't seem like something that is super important now, we can always reopen if, or folks can create new issue if they want this in the future.