Improve local development experience

[tjholm]

Some ideas of ways we could improve & speed up local developer experience

Remove Hot Reload from nitric run

nitric run would be intended for e2e testing with final container images with the emulated nitric environment and local services, it would be slower to start but would provide a much better idea of the finished product once relevant docker images are built.

Add command nitric start

nitric start would exclusively start local nitric services and nothing else, developers could then independently run their nitric applications to connect to these services using tools like nodemon on their local machines for hot reload and connecting debuggers would be much easier. This would give devs much more choice and control over their tooling for debugging and hot-reloading, and we could still provide opinions on this tooling via our examples and templates.

Don’t include nitric membrane by default in docker images

Production docker images should be built sans membrane, these images should be wrapped with the membrane when we’re ready to push them to a nitric supported environment, we can extract both entrypoint and cmd parts of the original image and wrap them for membrane invocation when pushing them to the cloud. This will also allow us to cache identical base images for multi-cloud support in future.

Remove config as code collection prior to nitric run

The CLI embedded membrane should be set up to dynamically provision resources on request by existing declaration endpoints to support things we are currently doing this for i.e. provisioning folders for minio buckets.

[asalkeld]

use-case: e2e tests - stays the same
use-case: local dev

was

• "nitric run"

now

• "nitric start" (suggest "nitric start-local-services")
• go run ./functions/api (or lang specific stuff) - so not at all run within a container?

Note: the "Don’t include nitric membrane by default in docker images" seems like a separate thing..

[tjholm]

@asalkeld will move the docker image wrapping stuff into a separate discussion.

And yes your writeup on the experience is correct. It will also be easier to connect a local debugger as well which will be really nice for local development.

[asalkeld]

Also would "nitric start" support more than one app?
For example you have 2 apps that work together, could you run them both against the one membrane?

[tjholm]

You can, but worth noting these "apps" would need to be in the same stack in the cloud to properly share resources in our current state.

[tjholm]

I have a working example with node that runs multiple functions using nodemon.

[jyecusch]

Yeah, that's the risk I guess. Could we perform some isolation (do we need to)?

[tjholm]

for now probably not, but it's definitely something to think about to reduce potential confusion.

[raksiv]

agree with tjholm, lets's start with documentation and see if it emerges as an issue.

[jyecusch]

Generally, I'm on board with the proposals.

The start-up performance of nitric run on Mac isn't great, it seems to be primarily an issue with drive performance in the docker VM on mac, but not super easy for us to fix universally. Using run just for more extensive testing gets around that issue and seems like it would offer a much quicker dev cycle for languages without support for hot reloading.

Also, for larger projects, it means you can pick and choose which functions to start. That'll be good, particularly on lower spec dev machines.

[tjholm]

I hadn't event considered the ability to test in isolation which seems like a pretty big win.

[tjholm]

also the removal on the config as code collection might speed things up a bit for a full run as well, as there would no longer be FS sync issues (build context would be copied rather than mounted).

[asalkeld]

One more question:

nitric start-local-services

Does it block? if not I assume we need a 'nitric stop-local-services'?

[tjholm]

my thoughts are this would block and display services in much the same way as run to display connected applications, and would simply be nitric start

[raksiv]

Thoughts on allowing the server to run on a specified port and/or base path to talk to one (or more) locally running servers with fewer config changes?

nitric start -port 9009 -path /app1

[tjholm]

I think the port start would work well for this. The initial implementation of this would likely be project agnostic at least for now, the local server would accept connections from whatever functions request them.