Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Project Components / Modules scaffolding support #133

Open
medgar-nitric opened this issue Aug 9, 2021 · 1 comment
Open

Add Project Components / Modules scaffolding support #133

medgar-nitric opened this issue Aug 9, 2021 · 1 comment
Labels
enhancement New feature or request

Comments

@medgar-nitric
Copy link
Contributor

medgar-nitric commented Aug 9, 2021

With FaaS architecture there is often common code shared between functions such as models or utility functions.

Many languages provide support for components or modular builds.

In the Java ecosystem Maven provides a modules concept enabling a project to be composed on multiple modules. An simple example could be a common model class needs to be used by multiple functions. This model would be contained in a common module, while the functions are contained in separate modules.

+customer-project\
|  
+- common\
|  +- src\
|  +- pom.xml
| 
+- func-customer-update\
|   +- src\
|   +- pom.xml
| 
+- func-customer-list\
|   +- src\
|   +- pom.xml
| 
+- nitric.yaml
+- pom.xml

Scaffolding up the modular project structure would provide a useful starting point for developers building FaaS solutions for the first time.

Example Java Microservices Maven Modules
https://2much2learn.com/mavengradle-based-multi-module-spring-boot-microservices/

┆Issue is synchronized with this Jira Story by Unito

@medgar-nitric medgar-nitric added the enhancement New feature or request label Aug 9, 2021
@tjholm
Copy link
Member

tjholm commented Aug 10, 2021

This is an interesting one, there are two concepts we need to deal with here when building images:

  • Context (the sum of all files included in the scope of a build).
  • Target (the output artefacts, that make up the execution context of a service).

Handling these mechanisms without some concept of extensibility is a bit of a challenge, as becoming target aware in the scope of a broader build context usually requires some knowledge/intervention (i.e. running specific scripts and copying specific files).

There are a few options available to us to support this, but essentially we would need users to provide us a way of setting both context and target in their service configurations and we can then inject this config into our builds, being able to support this for our existing templates would be preferable.

Could also look at adopting alternatives for image building/layering that could offer more flexibility and composability: e.g. https://buildpacks.io/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants