Replies: 4 comments 6 replies
-
|
From my side, there are several other things that are becoming more and more cumbersome: Too much of the repetitive boilerplate code for every tiny Lambda functionEvery lambda is a workspace, with its own copy of babel, tsconfig, package.json, etc. 90% of those files are redundant and completely irrelevant to developers building their custom stuff. The only thing that's really necessary is the Difficult to share repetitive code across Lambda handlersFor example, setup of Headless CMS and GraphQL can share the source codeThis is driven by the fact that we often need to hook into lifecycle events of Headless CMS models/content, and execute something on the Page Builder, and vice versa. This led me to this idea of merging the source code of |
Beta Was this translation helpful? Give feedback.
-
|
There is a lot of redundant code in the pulumi directories, too. I'd recommend factoring out some common code into a pulumi library. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback @snstanton. Can you clarify please? What did you mean here? Maybe you were referring to |
Beta Was this translation helpful? Give feedback.
-
|
Yes, the dev and prod folders are almost identical, so I end up needing to make changes in both places for anything I add/update. Keeping them in sync is annoying since most of the time, the only difference is the vpc config and the protectedEnvironment flag. If those could be abstracted into parameters, then everything else could be shared and the dev/prod folders would become a lot smaller and mostly consist of the same calls with a few parameter tweaks. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds good @snstanton, we'll definitely take this into consideration! 🍻 |
Beta Was this translation helpful? Give feedback.
-
|
Here's an idea that could massively simplify the setup and maintenance. Following the // Import handler factories from a new "serverless-cms" package
import {
createGraphQLHandler,
createHeadlessCMSHandler,
} from "@webiny/serverless-cms-ddb";
// Import scaffolded and custom plugins
import plugins from "./plugins";
export const graphQLHandler = createGraphQLHandler({
// Enable features (can also accept simple configurations)
features: {
pageBuilder: false,
formBuilder: false,
headlessCMS: true,
security: {
cognito: true,
},
},
// Pass in extra plugins
plugins,
});
export const headlessCMSHandler = createHeadlessCMSHandler({
features: {
// Enable Page Builder context on this handler (for example)
pageBuilder: true,
security: {
cognito: true,
},
},
// Pass in extra plugins
plugins,
});This same approach can be used for Pulumi infra configs. |
Beta Was this translation helpful? Give feedback.
-
|
This would help with the recent upgrade change where we need to hand-merge changed code. If we can minimize the number of places that patches are required, then upgrades will be much simpler. |
Beta Was this translation helpful? Give feedback.
-
|
Exactly! |
Beta Was this translation helpful? Give feedback.
-
|
I'm all for shallow folder structures and more verbose naming conventions, I've seen it really helps discoverability. It also makes a lot of sense to have |
Beta Was this translation helpful? Give feedback.
-
|
With 5.29.0, we've introduced a significantly simpler project structure, and for now, we're not looking into any more complex. For the time being, this discussion is to remain locked. |
Beta Was this translation helpful? Give feedback.
-
I wanted to start a public discussion on the current organization of folders and files in a Webiny project, the problems with it, and possible improvements. The following are some of my thoughts on the subject, but, everybody is more than welcome to share their thoughts as well.
1. Too Many Subfolders
The first and main problem for me is the fact that there's just too much nesting of folders. This is the current organization (files excluded from the directory tree):
api ├── code │ ├── dynamoToElastic │ │ └── src │ ├── fileManager │ │ ├── download │ │ │ └── src │ │ ├── manage │ │ │ └── src │ │ └── transform │ │ └── src │ ├── graphql │ │ └── src │ │ └── plugins │ ├── headlessCMS │ │ └── src │ │ └── plugins │ ├── pageBuilder │ │ ├── exportPages │ │ │ ├── combine │ │ │ └── process │ │ ├── importPages │ │ │ ├── create │ │ │ └── process │ │ └── updateSettings │ │ └── src │ └── prerenderingService │ ├── flush │ │ └── src │ ├── queue │ │ ├── add │ │ └── process │ └── render │ └── src └── pulumi ├── dev └── prodSo, first we have the
apifolder, and in it the twocodeandpulumifolders. To get to the actual application code, the additional folder in thecodefolder that users also need to get through issrc.This can be a bit cumbersome to deal with. For example, in order to extend the default GraphQL API, a plugin needs to be created in the
api/code/graphql/src/pluginsfolder.So, let's see if we can simply this. The current idea is to try performing the following two improvements.
First we remove the
codefolder. So, in theapifolder, let's immediately havegraphql,headlessCmsand other existing folders (files excluded from the directory tree):api ├── dynamoToElastic │ └── src ├── fileManager │ ├── download │ │ └── src │ ├── manage │ │ └── src │ └── transform │ └── src ├── graphql │ └── src │ └── plugins │ └── scaffolds ├── headlessCMS │ └── src │ └── plugins │ └── scaffolds ├── pageBuilder │ ├── exportPages │ │ ├── combine │ │ │ └── src │ │ └── process │ │ └── src │ ├── importPages │ │ ├── create │ │ │ └── src │ │ └── process │ │ └── src │ └── updateSettings │ └── src ├── prerenderingService │ ├── flush │ │ └── src │ ├── queue │ │ ├── add │ │ │ └── src │ │ └── process │ │ └── src │ └── render │ └── src └── pulumi ├── dev └── prodNotice how nothing has happened with the
pulumifolder. We're leaving it as-is.Once that's in place, the next step would be to try to remove the
srcfolder. Then we'd end up with the following (this time I've included the files in the directory tree):Still a lot of code, but at least, if we were to revisit the initial example of adding a GraphQL API plugin, instead of adding it in the
api/code/graphql/src/plugins, now we're adding it inapi/graphql/plugins. So, there's two levels we don't need to think about anymore.2. Rename
codetoappandpulumitoinfraor SimilarThe idea here was to rename the
codefolder toappandpulumitoinfraor something similar, resembling the two types of code the developer is writing - application and cloud infrastructure code.If we were to apply the first 1. Too Many Subfolders improvement, then the
codefolder is no longer relevant. Butpulumistill is. I think renaming this to something more closer to the "cloud infrastructure" term would improve DX / make things easier to grasp. Some suggestions from my side:cloudInfrastructure(definitely too long)infrastructureinfracloud3. Rename
apitobackendandappstofrontendAnother rename I'd do is rename
apifolder tobackendandappstofrontend. Simply, it's just more straightforward and I believe more clear for the user.4. Move Root
Pulumi.yamlandtsconfig.jsonFiles Into Pulumi FolderThese two files are really just part of the Pulumi code. Again, to make it a bit more clear, let's move them into the
pulumifolder. With this change, theapifolder would look like the following:Beta Was this translation helpful? Give feedback.
All reactions