After thinking a lot, I decided to architecting a ...
# helpj
Josimar Zimermann
10/05/2021, 2:38 PMAfter thinking a lot, I decided to architecting a solution using the multi repo concept. I reached that conclusion after reading this article: https://aws.amazon.com/blogs/compute/best-practices-for-organizing-larger-serverless-applications/
Some of the functions will need to share common code. To suite that, I'm thinking about Lambda layers. So, each layer would have its own repo. How can I test locally a function that uses a layer in another repo?
If you have another approach or suggestion, I will appreciate to hear that.
a
Adrián Mouly
10/05/2021, 2:39 PMWould like to know more.
Adrián Mouly
10/05/2021, 2:39 PMI have too many stacks in the same repository.
j
Josimar Zimermann
10/05/2021, 2:51 PMWe are going to write scraper functions to get information about insurance policies from insurance companies in Brazil (there are more than 100 companies). For a single company, for example, will be needed to write more than 10 functions. And every function will start with authentication. So, I want to write the authentication function one time and share between all the other functions.
t
thdxr
10/05/2021, 3:01 PMI think generally the patterns for this aren't specific to sst.
thdxr
10/05/2021, 3:02 PMIf you have common code in a repo, it needs to be versioned and distributed. You can do this via an npm package (which is what I recommend) or a layer if you really want. I'm not sure if using a layer has a lot of benefit and it still creates the problem of accessing that code in local development
thdxr
10/05/2021, 3:03 PMI would strongly suggest considering a monorepo. You can use this structure (plus some of the options I suggest in readme for bigger projects): https://github.com/serverless-stack/serverless-stack/tree/master/examples/typescript-monorepo
thdxr
10/05/2021, 3:04 PMIt's best to start with a monorepo so you have flexibility to learn about your boundaries and then pull things out if there's truly an advantage.
Even if you have a 100 companies, having 100 folders in the repo isn't too different than having 100 repos
j
Josimar Zimermann
10/05/2021, 3:09 PMMy worry is about updating a common function. For example, if I change the authentication function I will need to update all functions that uses that authentication function, right?
t
thdxr
10/05/2021, 3:13 PMas long as you have versioning it can work fine
thdxr
10/05/2021, 3:13 PMSome functions can use the old one
thdxr
10/05/2021, 3:14 PMSorry I thought you were referring to layers. Yes if you're concerned about using multiple versions of the same code, then you should put that code in its own repo. Keep everything else together
thdxr
10/05/2021, 3:15 PMI also recommend you do not use multiple versions of the same code. It might seem tempting at first but it usually leads to growing pain
thdxr
10/05/2021, 3:16 PMThe way the monorepo example is setup, you can create discrete packages in the same repo. If over time you really want to have a package live on its own, it's easy to extract into its own repo
j
Josimar Zimermann
10/05/2021, 3:18 PMUnderstood. A monorepo looks like easier to start and split when necessary.
t
Thomas Ankcorn
10/05/2021, 4:03 PMFor example, if I change the authentication function I will need to update all functions that uses that authentication functionThings like this can be a sign that you are trying to prematurely abstract things. Sandi Metz says it best but generally if you find the need to do this it’s often much cheaper to create a new module/function for the new requirements. https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction
4 Views