From 3715b9fe7a686b07e6b771ba8ad429ff002b9cf3 Mon Sep 17 00:00:00 2001 From: Bill Harts Date: Wed, 31 Jul 2019 13:05:17 -0400 Subject: [PATCH 1/2] Update organizaing-serverless-projects.md Correct typos and some grammar. Added some clarity around directory structure --- _chapters/organizing-serverless-projects.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/_chapters/organizing-serverless-projects.md b/_chapters/organizing-serverless-projects.md index 295d6e193..3f59d4045 100644 --- a/_chapters/organizing-serverless-projects.md +++ b/_chapters/organizing-serverless-projects.md @@ -52,18 +52,18 @@ The directory structure of your entire application under the microservice + mono A couple of things to notice here: 1. We are going over a Node.js project here but this pattern applies to other languages as well. -2. The `services/` dir at the root is made up of a collection of services. Where a service contains a single `serverless.yml` file. +2. The `services/` directory at the root is made up of a collection of services, each in a separate subdirectory. Each service subdirectory contains a single `serverless.yml` file. 3. Each service deals with a relatively small and self-contained function. So for example, the `posts` service deals with everything from creating to deleting posts. Of course, the degree to which you want to separate your application is entirely up to you. 4. The `package.json` (and the `node_modules/` dir) are at the root of the repo. However, it is fairly common to have a separate `package.json` inside each service directory. 5. The `lib/` dir is just to illustrate that any common code that might be used across all services can be placed in here. -6. To deploy this application you are going to need to run `serverless deploy` separately in each of the services. +6. To deploy this application you are going to need to run `serverless deploy` separately in each of the `services/` subdirectories. 7. [Environments (or stages)]({% link _chapters/stages-in-serverless-framework.md %}) need to be co-ordinated across all the different services. So if your team is using a `dev`, `staging`, and `prod` environment, then you are going to need to define the specifics of this in each of the services. #### Advantages of Mono-Repo The microservice + mono-repo pattern has grown in popularity for a couple of reasons: -1. Lambda functions are a natural fit for a microservice based architecture. This is due to a few of reasons. Firstly, the performance of Lambda functions is related to the size of the function. Secondly, debugging a Lambda function that deals with a specific event is much easier. Finally, it is just easier to conceptually relate a Lambda function with a single event. +1. [Lambda]({% link _chapters/what-is-aws-lambda.md %}) functions are a natural fit for a microservice based architecture. This is due to a few reasons. Firstly, the performance of a Lambda function is related to the size of the function. Secondly, debugging a Lambda function that deals with a specific event is much easier. Finally, it is just easier to conceptually relate a Lambda function with a single event. 2. The easiest way to share code between services is by having them all together in a single repository. Even though your services end up dealing with separate portions of your app, they still might need to share some code between them. Say for example; you have some code that formats your requests and responses in your Lambda functions. This would ideally be used across the board and it would not make sense to replicate this code in all the services. From f7863699e18ca4dfcca6aebb955d66c65d07375f Mon Sep 17 00:00:00 2001 From: Jay V Date: Wed, 31 Jul 2019 14:31:55 -0400 Subject: [PATCH 2/2] Update organizing-serverless-projects.md --- _chapters/organizing-serverless-projects.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_chapters/organizing-serverless-projects.md b/_chapters/organizing-serverless-projects.md index 3f59d4045..90e909dcd 100644 --- a/_chapters/organizing-serverless-projects.md +++ b/_chapters/organizing-serverless-projects.md @@ -63,7 +63,7 @@ A couple of things to notice here: The microservice + mono-repo pattern has grown in popularity for a couple of reasons: -1. [Lambda]({% link _chapters/what-is-aws-lambda.md %}) functions are a natural fit for a microservice based architecture. This is due to a few reasons. Firstly, the performance of a Lambda function is related to the size of the function. Secondly, debugging a Lambda function that deals with a specific event is much easier. Finally, it is just easier to conceptually relate a Lambda function with a single event. +1. [Lambda functions]({% link _chapters/what-is-aws-lambda.md %}) are a natural fit for a microservice based architecture. This is due to a few reasons. Firstly, the performance of a Lambda function is related to the size of the function. Secondly, debugging a Lambda function that deals with a specific event is much easier. Finally, it is just easier to conceptually relate a Lambda function with a single event. 2. The easiest way to share code between services is by having them all together in a single repository. Even though your services end up dealing with separate portions of your app, they still might need to share some code between them. Say for example; you have some code that formats your requests and responses in your Lambda functions. This would ideally be used across the board and it would not make sense to replicate this code in all the services.