Moving local serverless server into separate package

[miketalley]

Description and Context

Moving the local serverless testing logic out of the cms-cli command file into a separate lerna package.

This is currently still WIP, I would love any feedback on how this is being executed. Specifically...

• Does it make sense to import this package as a dependency in cms-cli the way that it is and abstract the logic away
• Does the signature of the main export(start) make sense -- it takes an options object shaped like

{
  accountId: <portalId/accountId>,
  path: <pathToLocalDotFunctionsFolder>,
  port: <customPortToRunServerOn>,
  contact: <booleanValueToSpecifyIfContactDataShouldBePassedToServerlessFunction> // defaults to true
}

Who to Notify

@gcorne

[gcorne]

Took a quick pass (not super deep).

[gcorne]

I think we should come up with another name for the package. My suggestion would be something that doesn't have local in the name because I think it could be used for things like testing a serverless function in a CI situation and for it to forgo the pun. Perhaps we could use something along the lines of serverless-function-runner or serverless-runner. I think the model of this being about execution not a server is best. Could even use execute or executor. Naming is hard…

[miketalley]

I just wanted the name to focus on the fact that we need to run a server to test serverLESS functions 😂
There is an express server that allows the endpoints to be accessed locally

[gcorne]

I'd suggest some docs that state that this is intended for use with the CLI with a link to either the docs on developers.hubspot.com or the NPM package.

[gcorne]

I think we should probably be using either .env or a config file for this and be consider when these may be things that may make sense to live with the project in source control.

[miketalley]

Good point, I'll move this out.

[gcorne]

Can you explain this a bit more? I thought we were faking the way this works when executing in the HubSpot serverless infra?

[miketalley]

The way production works is it grabs the cookie value for hubspotutk which is not an actual contact id. It's some sort of hashed value that the BE understands and can convert into a contact. AFAIK there is not an API endpoint to get the contact data using this value, and I'm not sure we want there to be an endpoint for this.

So instead, in order to facilitate testing around the contact prop that gets passed into the function, this allows for customization of the data that is passed in. By setting values for these environment variables, that mocked value will be passed into the function for testing.

[miketalley]

Going to merge this back into the serverless/local-testing branch as this branch has served it's purpose