How do I organize software projects with heavy frontend?
November 18, 2023 8:56 PM Subscribe
I’m still struggling with frontend development. Basically I get out on projects that have common elements (React, web components, mostly API based, light backend). The requirements aren’t known at the beginning, even the hosting platform, and I’ve made recent success moving the complexity of frontend to a simple make file but I’m curious about organization.
I want to move complexity to the build system, and the way teams are based here we’ll have some that will do components, some do the API, some take common components and make it into something complex like a checkout process, as an example.
The team has agreed on some basic things like using Stencil as the common library (style and put it in /lib/stencil … use typescript as much as possible, then put features like checkout in /apps/checkout. Have maybe a component with a mock api that can be designed under day app/checkout/component using the built stencil components then have the “real” component under /app/checkout/src.
Have the build system put these “apps” under a temporary /dist folder that will build maybe something like storybook or ladle and integrate it into a light web framework so you can see like the menu along with the checkout, etc. the idea is to keep everything the /apps as light as possible and allow devs, compile everything and bundle in the end. Use node as little as possible, basically keep dependencies down as little as possible and use super light weight web servers in development, while allowing the apps to use whatever they need. Checkout might have specific needs but in the end I’d like to compile it into web components or react components wrapping web components. I don’t want to constrain different “apps” and want to get away from hottest framework at the moment while also allowing flexibility. I find opinionated frameworks that put components in “islands” as kinda restraining.
There’s a lot of jokes on here but I’d like to scaffold apps in make and spin them up individually. There will need to be refactoring, bundling and dependency issues, but I like the monorepo setup. Eventually it’ll have to move to a sophisticated build system like ninja but can start out as make and call “checkout” done.
I feel nx pits a heavy dependency on frontend, and make might be the most intuitive but it has solved a lot of things. Really want I’m trying to do is keep a monorepo, keep it simple and assume “apps” won’t have interdependencies at first. Like there might be a change in the menu after checkout but don’t get complicated early and add a “middleware” layer as needed. Checkout is a complex example as it might have cross domain iframes so mocking that out is complex but I’m wanting teams to get stuff done and assuming the “apps” can be largely not interdependent.
I hate seeing all kinds of complex build files in the project root. I’d also like to decompose it as much as possible. Does anyone have suggestions or examples? Like I want each section to be as independent and simple is my main goal but if a portion or page of the project has complexity I don’t want to restrict it.
This is meandering a bit but complex backend apps seem simpler than this. I kinda want to treat it as if targeting a different OS tries to hide it in a build toolchain. I am comparing frontend to something like LVVM. It would be easier to know what platform or hosting environment I’m targeting. So unlike a product like Netflix which may say we have “x” standards up front I am having to deal with things like cloud selection, web server used and devs sitting around. There will be refactoring but I want devs not to be frustrated and basically try to build this as
much in the build layer with smallest components as possible? Think Chromium targeting multiple OSes some must have a good solution.
I want to move complexity to the build system, and the way teams are based here we’ll have some that will do components, some do the API, some take common components and make it into something complex like a checkout process, as an example.
The team has agreed on some basic things like using Stencil as the common library (style and put it in /lib/stencil … use typescript as much as possible, then put features like checkout in /apps/checkout. Have maybe a component with a mock api that can be designed under day app/checkout/component using the built stencil components then have the “real” component under /app/checkout/src.
Have the build system put these “apps” under a temporary /dist folder that will build maybe something like storybook or ladle and integrate it into a light web framework so you can see like the menu along with the checkout, etc. the idea is to keep everything the /apps as light as possible and allow devs, compile everything and bundle in the end. Use node as little as possible, basically keep dependencies down as little as possible and use super light weight web servers in development, while allowing the apps to use whatever they need. Checkout might have specific needs but in the end I’d like to compile it into web components or react components wrapping web components. I don’t want to constrain different “apps” and want to get away from hottest framework at the moment while also allowing flexibility. I find opinionated frameworks that put components in “islands” as kinda restraining.
There’s a lot of jokes on here but I’d like to scaffold apps in make and spin them up individually. There will need to be refactoring, bundling and dependency issues, but I like the monorepo setup. Eventually it’ll have to move to a sophisticated build system like ninja but can start out as make and call “checkout” done.
I feel nx pits a heavy dependency on frontend, and make might be the most intuitive but it has solved a lot of things. Really want I’m trying to do is keep a monorepo, keep it simple and assume “apps” won’t have interdependencies at first. Like there might be a change in the menu after checkout but don’t get complicated early and add a “middleware” layer as needed. Checkout is a complex example as it might have cross domain iframes so mocking that out is complex but I’m wanting teams to get stuff done and assuming the “apps” can be largely not interdependent.
I hate seeing all kinds of complex build files in the project root. I’d also like to decompose it as much as possible. Does anyone have suggestions or examples? Like I want each section to be as independent and simple is my main goal but if a portion or page of the project has complexity I don’t want to restrict it.
This is meandering a bit but complex backend apps seem simpler than this. I kinda want to treat it as if targeting a different OS tries to hide it in a build toolchain. I am comparing frontend to something like LVVM. It would be easier to know what platform or hosting environment I’m targeting. So unlike a product like Netflix which may say we have “x” standards up front I am having to deal with things like cloud selection, web server used and devs sitting around. There will be refactoring but I want devs not to be frustrated and basically try to build this as
much in the build layer with smallest components as possible? Think Chromium targeting multiple OSes some must have a good solution.
Can you push each component in a child repo using git submodules? Then they build in their own space and you run git submodule update to pull them in when assembling the full project?
posted by k3ninho at 8:38 AM on November 19, 2023 [1 favorite]
posted by k3ninho at 8:38 AM on November 19, 2023 [1 favorite]
Workspaces or even better packages using nx. One package for the actual app pages, one for library/common components, one for APi calls. We also have one for Cypress tests.
posted by billsaysthis at 10:03 AM on November 19, 2023
posted by billsaysthis at 10:03 AM on November 19, 2023
[paraphrased]- brian foote
reusable code doesn't come from superior insight and sheer force of will. code reuse comes from code reuse. in other words, it takes consistent refactoring within the domain, and natural evolution towards reuse.
posted by j_curiouser at 7:43 PM on November 19, 2023
You are not logged in, either login or create an account to post comments
posted by hoyland at 10:50 PM on November 18, 2023