dont use randomId when name is provided

[danielcondemarin]

No description provided.

[eahefnawy]

Thanks Dan! I'm gonna test this as it might be breaking. Will probably publish a major version of this.

[danielcondemarin]

Thanks Dan! I'm gonna test this as it might be breaking. Will probably publish a major version of this.

Publishing a major is probably the safest thing to do 👍

[barrysteyn]

This is something incredibly vital. I am unable to refer to the table name in my app code unless this feature is merged. It shouldn't take more than a month and one week to get a reply on this issue!

[barrysteyn]

@danielcondemarin Hi Dan, I think you can close this issue now as my PR has been merged that ensures names are not randomized.

[mstn]

@barrysteyn @eahefnawy Why removing the random id?

Sorry for the late question, but I found it after my code was broken.

It could clash with existing tables (other projects, environment...). If you want to refer to the table name in you app code, you should pass ${table.name} (i.e. config output) as an environmental variable. Other resources, e.g. buckets and lambdas (for the latter ones I do not know if it is still true), have also names userDefinedName-randomString.

In general I think we always want to give a prefix to append to a name because it is easier to understand what table is articles-xyz than xyz.

[barrysteyn]

At the very least, if this is wanted, then this should be a feature switch (i.e. random table name). But my two cents is that table names are an application code specific thing, and it should be determined within your code (e.g. in the serverless.js file).

However (sadly), I don't think serverless components are being maintained anymore, and there seems to be a general move away from using them.

Let me give you one example: @danielcondemarin 's amazing project for hosting next.js on serverless: It is hosting app specific code, and would not be able to provide names randomly made within the components to the user's business logic. So in this instance, if you create a table with a name, you would expect that name to be identical so you can call it in your business logic (and just to hit it home again, the business logic is separate from the actual components and so the components cannot pass it down to it).

[mstn]

Thanks @barrysteyn. I found out that "your" way is now implemented for lambda function names as well. So I guess now it is the "official" way. But, as you said, it seems that this project has been abandoned. It's a pity!

I do not know @danielcondemarin 's project. However, I agree that it is not possible to mix "infrastructure" and "business logic" code.

I do not know if sharing a competitor's link is polite (sorry, guys), but this is an interesting project https://www.pulumi.com/ (search for magic functions). Using that, I built a PoC where I am able to share architectural components (with logic like "dispatch that to this") as NPM packages!

[eahefnawy]

@mstn @barrysteyn @danielcondemarin Apologies for the late reply here, we've been super busy upgrading everything. The good news is that we've made Serverless Components GA and upgraded this component to the latest core, and we've incorporated this change. Now if you don't specify a name input, it'll be autogenerated.

REF:
https://www.serverless.com/blog/serverless-components-ga/

Thanks all for your input. Closing since it's now fixed.