4 ms·

The Majestic Pseudo-Monolith

26 points by sergiomattei 5y ago

torben-friis 5y ago
I don't see how this has anything to do with a monolith (in the sense of the monolith vs. microservices approaches). It's not really front page material either (IMO), it's just a basic article about placing frontend and backend code in the same repo and making a script to run both locally. It doesn't even tackle any interesting problems like handling the separate needs of both codebases in the CI scripts, nor it gets much out of bundling the two together except for opening them in the same editor - which is somewhat conflated with it being a monorepo? (you could simply open a parent folder with two different codebases inside and achieve pretty much the same).
- jdsleppy 5y ago
  It's surprisingly easy to stay on the front page for a while. Anyways, I always enjoy seeing how other people set up this interstitial stuff, the ergonomics, and little scripts. I get a lot of valuable learning seeing other people do things, even things I know how to do (a different way).
- sergiomattei 5y ago
  Hi! Author here. My point with the article was to try and solve (and start a conversation) about some of the cognitive overhead problems of a frontend-backend stack. It's definitely not a monolith - hence the pseudo bit. For me, the ease of a monolith comes with having a deeply interconnected system with similar standards. Little context switching. About tackling bigger problems, I'll probably update it later once I face them. I'm a small, indie dev - I don't face huge problems!
noway421 5y ago
Nice! In terms of switching between different editors - I use Command+` for that. I usually have UI and API open, and switching between those 2 is as easy as pressing that hotkey. Don't have to muck around with Command+Tab. In terms of running 2 things at once, I prefer apple scripts - I have a script which opens up a bunch of iTerm tabs with all the watchers I need. All in all, nice setup, good job! Always interesting to see how other peeps organise that stuff.
- sergiomattei 5y ago
  Thanks! Didn't know that key shortcut tip.
lmm 5y ago
A boilerplate doesn't get updated and so practically ensures that your components will drift out of sync. Far better to use a library (if your build system doesn't support that, get a better one - plenty of "backend" build systems integrate npm or yarn). And if you only have one repo and you often edit multiple components at the same time, maybe consider making it an actual monolith?
lprd 5y ago
Really enjoyed your article! I usually write my API's in Go and always reach for NextJS for my front-ends. How you handle things like authorization and authentication?

26 points by sergiomattei 5y ago

I don't see how this has anything to do with a monolith (in the sense of the monolith vs. microservices approaches). It's not really front page material either (IMO), it's just a basic article about placing frontend and backend code in the same repo and making a script to run both locally. It doesn't even tackle any interesting problems like handling the separate needs of both codebases in the CI scripts, nor it gets much out of bundling the two together except for opening them in the same editor - which is somewhat conflated with it being a monorepo? (you could simply open a parent folder with two different codebases inside and achieve pretty much the same).

jdsleppy 5y ago
It's surprisingly easy to stay on the front page for a while. Anyways, I always enjoy seeing how other people set up this interstitial stuff, the ergonomics, and little scripts. I get a lot of valuable learning seeing other people do things, even things I know how to do (a different way).
sergiomattei 5y ago
Hi! Author here. My point with the article was to try and solve (and start a conversation) about some of the cognitive overhead problems of a frontend-backend stack. It's definitely not a monolith - hence the pseudo bit. For me, the ease of a monolith comes with having a deeply interconnected system with similar standards. Little context switching. About tackling bigger problems, I'll probably update it later once I face them. I'm a small, indie dev - I don't face huge problems!

noway421 5y ago

Nice! In terms of switching between different editors - I use Command+` for that. I usually have UI and API open, and switching between those 2 is as easy as pressing that hotkey. Don't have to muck around with Command+Tab. In terms of running 2 things at once, I prefer apple scripts - I have a script which opens up a bunch of iTerm tabs with all the watchers I need. All in all, nice setup, good job! Always interesting to see how other peeps organise that stuff.

sergiomattei 5y ago
Thanks! Didn't know that key shortcut tip.

lmm 5y ago

A boilerplate doesn't get updated and so practically ensures that your components will drift out of sync. Far better to use a library (if your build system doesn't support that, get a better one - plenty of "backend" build systems integrate npm or yarn). And if you only have one repo and you often edit multiple components at the same time, maybe consider making it an actual monolith?

lprd 5y ago

Really enjoyed your article! I usually write my API's in Go and always reach for NextJS for my front-ends. How you handle things like authorization and authentication?