Organizing Serverless Projects

Chapter Comments
1

Link to chapter - https://serverless-stack.com/chapters/organizing-serverless-projects.html

2

Great chapter. I could really use examples of a monorepo.

What are best practices if mulitiple services use the same dynamodo or Cognito setup.

How do you deploy multiple services with the same domain? Example - api.example.com?

I feel a chapter on this would be amazing. People are using monorepos but there are not examples outside of claiming you put severless.yml in different folders.

1 Like
3

Thats a great point. Thanks for feedback. I’m going to write a couple of chapters on these very shortly. But here is the general idea:

4

Thank you so much @jayair this is a good start. Look forward to seeing the chapters. This guide has been indispensable and one of the best technology books/tutorials I have seen in my long career doing web development.

2 Likes
5

Thank you! I’m glad you’ve found it helpful!

6

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.

I think it would be interesting to expand on that a bit. The example provided is great but does not illustrate how to handle dependencies, and shared code between services which is a fairly common issue

7

That’s a good point. We’ve gotten a couple of requests for this in past. We’ll be updating this with a more detailed example.

8

How did you tackle the problem? By deploying every single service on aws, the common node_modules dir is not loaded

9

If anybody is looking for an example of how to handle your package.json in a monorepo app, we wrote about it here:

I’ll add a link to this in the chapter.

1 Like
10

Hi. I managed to successfully follow your worderful tutorial with the proposed structure of the two repositories (resources and api). Now I am trying to replicate the structure in a project of my own and a little more complex. My project handles four Dynamo tables. The functions of each table may or may not require the user to be authenticated. On the other hand, there are functions that must be restricted for some particular users, which I do not know if the best way is to manage it though Cognito groups or roles. It is also unclear to me whether it is convenient for the four tables to share the same serverless.yml or rather to keep them independent. But really the most complex thing for me has been understanding how to handle the permissions of the functions for authenticated and unauthenticated users. I’m stuck there.

11

Well to start with you can create public APIs for your functions that don’t need auth. Remove the authorizer option from your serverless.yml:

12

I’ve been following along with the tutorial from the beginning. I’m going through the process of breaking apart concerns into multiple serverless projects, but this chapter appears to make some steps that are not discussed in the tutorial. For example, earlier in the tutorial, we created a handler-lib.js that wraps each lambda function and provided simple error handling. The serverless stack demo ext API repo appears to have gotten rid of this abstraction and included a few others (e.g. response-lib).

Maybe I missed it, but were these changes covered in the tutorial? I like to understand the motivations for code refactors, and this particular change was not discussed.

1 Like
13

It’s the other way around. We added these details to the main guide recently. For the extension we don’t want to overload the concepts so we are keeping the app relatively simple.

14

Understood, that makes sense. There’s a lot of ground to cover in making a tutorial like this.

For example, I’m setting up SNS events in my serverless app. I have been using the Serverless Stack Demo EXT API as a reference, namely how the Billing service produces SNS messages and the Notify service consumes SNS messages. These examples have been very useful!

The Organizing Serverless Projects chapter refers to these services, but doesn’t go into detail about how they were created and the decisions made along the way. This was the first time I saw them references in the Serverless Stack demo, and it left me wondering if I skipped or otherwise overlooked that discussion in the guide.

Thanks again for this resource, it’s been tremendously helpful.

1 Like
15

Good news to the CloudFormation resource limit error posted here!

Error --------------------------------------------------

The CloudFormation template is invalid: Template format error: Number of resources, 201, is greater than maximum allowed, 200

AWS just announced service limit increases for CF stack resources up to 500!!! (up from 200)

You will need to open a service limit increase support case in your AWS account to do this.

16

Yeah that is great news! Let me add a note to the chapter.

17

Thanks for the amazinng guide. I was wondering how you’re able to access the common “libs/” directory in all the services of the monorepo cause the serverless api that is being deployed exists within “services/notes-api/”

1 Like
18

In our case we use https://github.com/AnomalyInnovations/serverless-bundle to Webpack the common code into the bundle. So we aren’t directly copying over these files.

19

This is a beneficial guide! I’m building a react native app and wonder how to organize that project best while using serverless. In the demo app for the sst guide, we place our react web app within a front-end folder within the same repo. This is also how the guide for the expo app structures its repo. I wonder if it makes sense to start out this way and eventually split the serverless backend into its own dedicated repo. I know there must be pros and cons to both approaches but I’d appreciate any suggestions!