5 ms·

Up until late 2018, my MBA 2013 was doing ok with a stack transitioning to full js/ts. Now it’s close to unusable as our projects build multiple containers, loa

Up until late 2018, my MBA 2013 was doing ok with a stack transitioning to full js/ts. Now it’s close to unusable as our projects build multiple containers, load hundreds of node packages etc. Unfortunately, the 2019 MBA isn’t much better. I’m still wondering whether to hold until a new MBP 13/14”, or give this a try.

ehutch79 7y ago
A typical JS developer is not building/rebuilding docker containers constantly.
- kasey_junk 7y ago
  It seems pretty typical for js backend systems to be heavily containerized such that I’d say it’s approaching the default deployment mechanism.
  - ehutch79 7y ago
    Why would you keep rebuilding the container constantly though?
    - kasey_junk 7y ago
      Typically build flows don’t mount the js with volumes they embed it in the image. I’m not cognizant enough of the trade offs to know why.
      - bpicolo 7y ago
        Optimizing your local workflows is worth the effort at every team size. I think the attempts to make local workflows mirror production 1:1 (local k8s, for example) are misguided. They miss too hard on the productivity story. Especially once you start having to swap out local debugging for remote debugging (which only a handful of languages support effectively). This is the biggest miss for many companies striving for microservice architecture. The local development story is terrible, and it stays terrible, without a lot of opinionated decisions around what your dev workflow needs to look like past the ~3-5 services mark. At a past gig I had to change 5 different repositories (5 separate PRs, all needing approval) to send an email. In a rails app that would have been a trivial task.
        inapis 7y ago
        > At a past gig I had to change 5 different repositories (5 separate PRs, all needing approval) to send an email. In a rails app that would have been a trivial task. That sounds like no thought was put in the system before development. Well thought out scopes & contracts between services should not create a situation like that. Reminds me of a commenter on HN who were rolling back changes to all microservices if one service needed a rollback. These kinds of issues are dead giveaways that devs are paying lip-service to "microservices." Also, devs need to understand that they don't need to be on microservices or on the latest fad. Use what works for the team. A 10-team of devs cannot necessarily adopt workflows of a FAANG.
        bpicolo 7y ago
        Here's the complexity story, if you're curious. 1. Terraform repo for AWS deploy 2. Step functions application logic (server-side polling daemon) 3. Email service template 4. Feature flag configuration 5. (Something in the monolith to trigger the workflow, probably?) This wasn't an entirely small engineering org - 300-400+ devs? I agree, though, is the point. I think folk don't put enough thought into the development story when going this route. I think monorepos are the only sensible way to go about it once folk have cross-service work to accomplish, and monoliths are a _good_ way to build applications for longer than folk give them credit. That said, some monoliths are more productive than others. Slow startup/compilation can destroy productivity.
    - ehutch79 7y ago
      kasey: For deployment that makes sense, but for development, that seems like a lot of work to be happening. If you change a small bit of css, the whole container is rebuilt? That seems super inefficient to me? My backends arn't JS, but I still couldn't imagine rebuilding a container everytime I changed a piece of code. Right now I change a file, django picks up the change and reloads. No noticeable delay.
      - nikanj 7y ago
        Because JS. And somehow we the developers convinced each other that -any- attention to performance whatsoever is "premature optimization".
        inapis 7y ago
        This has got nothing to do with JS. Plenty of devs (me included) work on frontend and backend JS without containers and everything is instant for us. OP has a special use case or build pipeline necessitating such complexity.
- solat 7y ago
  Not really but when you try new config/Dockerfiles/docker-compose setups it's nice to have power + bandwidth. Thus, I develop on a remote server.
- technotarek 7y ago
  That's correct. Not building/re-building the containers constantly. However, the initial build takes forever and some containers tend to crash (e.g., Prisma). Plus, in our case where we're using Angular, the recompiling of the app on change sends the fan into overdrive and I get noticeable lag on application switching. Again, this is on a 2013 MBA, which is almost ridiculous, but I'm that type of person. Still proudly sporting my iPhone SE. My development partner is on the 2019 MBA and has noticed improvement, but albeit rather underwhelming. As an aside, I haven't taken the time to pin point the exact problem, but as much I prefer to use Firefox, it doesn't seem to do a great job of managing resources for the SPAs we're building.
  - ricketycricket 7y ago
    Make sure your node_modules directory is mapped to a local volume inside docker (not synced to your Mac). This dramatically improves build performance in Docker for Mac. If using docker compose, try this out https://stackoverflow.com/questions/29181032/add-a-volume-to-docker-but-exclude-a-sub-folder/38601156#38601156 https://stackoverflow.com/questions/29181032/add-a-volume-to...
  - ehutch79 7y ago
    This is a dumb question, but you're talking about using docker, right? Doesn't docker spin up an entire vm for containers? That does seem pretty heavy for a MBA of any generation?
    - hobofan 7y ago
      > Doesn't docker spin up an entire vm for containers? (It generally does not. Instead it uses more lightweight isolation primtives. That has always been one of its main selling points.) EDIT: see reply > That does seem pretty heavy for a MBA of any generation? It very much depends on what you are running inside the containers. I regularly have a dev environment with ~8 relatively lightweight containers running on my Early 2014 MBA without any problems.
      - mikewhy 7y ago

ehutch79 7y ago

A typical JS developer is not building/rebuilding docker containers constantly.

kasey_junk 7y ago
It seems pretty typical for js backend systems to be heavily containerized such that I’d say it’s approaching the default deployment mechanism.
- ehutch79 7y ago
  Why would you keep rebuilding the container constantly though?
  - kasey_junk 7y ago
    Typically build flows don’t mount the js with volumes they embed it in the image. I’m not cognizant enough of the trade offs to know why.
    - bpicolo 7y ago
      Optimizing your local workflows is worth the effort at every team size. I think the attempts to make local workflows mirror production 1:1 (local k8s, for example) are misguided. They miss too hard on the productivity story. Especially once you start having to swap out local debugging for remote debugging (which only a handful of languages support effectively). This is the biggest miss for many companies striving for microservice architecture. The local development story is terrible, and it stays terrible, without a lot of opinionated decisions around what your dev workflow needs to look like past the ~3-5 services mark. At a past gig I had to change 5 different repositories (5 separate PRs, all needing approval) to send an email. In a rails app that would have been a trivial task.
      - inapis 7y ago
        > At a past gig I had to change 5 different repositories (5 separate PRs, all needing approval) to send an email. In a rails app that would have been a trivial task. That sounds like no thought was put in the system before development. Well thought out scopes & contracts between services should not create a situation like that. Reminds me of a commenter on HN who were rolling back changes to all microservices if one service needed a rollback. These kinds of issues are dead giveaways that devs are paying lip-service to "microservices." Also, devs need to understand that they don't need to be on microservices or on the latest fad. Use what works for the team. A 10-team of devs cannot necessarily adopt workflows of a FAANG.
        bpicolo 7y ago
        Here's the complexity story, if you're curious. 1. Terraform repo for AWS deploy 2. Step functions application logic (server-side polling daemon) 3. Email service template 4. Feature flag configuration 5. (Something in the monolith to trigger the workflow, probably?) This wasn't an entirely small engineering org - 300-400+ devs? I agree, though, is the point. I think folk don't put enough thought into the development story when going this route. I think monorepos are the only sensible way to go about it once folk have cross-service work to accomplish, and monoliths are a _good_ way to build applications for longer than folk give them credit. That said, some monoliths are more productive than others. Slow startup/compilation can destroy productivity.
  - ehutch79 7y ago
    kasey: For deployment that makes sense, but for development, that seems like a lot of work to be happening. If you change a small bit of css, the whole container is rebuilt? That seems super inefficient to me? My backends arn't JS, but I still couldn't imagine rebuilding a container everytime I changed a piece of code. Right now I change a file, django picks up the change and reloads. No noticeable delay.
    - nikanj 7y ago
      Because JS. And somehow we the developers convinced each other that -any- attention to performance whatsoever is "premature optimization".
      - inapis 7y ago
        This has got nothing to do with JS. Plenty of devs (me included) work on frontend and backend JS without containers and everything is instant for us. OP has a special use case or build pipeline necessitating such complexity.
solat 7y ago
Not really but when you try new config/Dockerfiles/docker-compose setups it's nice to have power + bandwidth. Thus, I develop on a remote server.
technotarek 7y ago
That's correct. Not building/re-building the containers constantly. However, the initial build takes forever and some containers tend to crash (e.g., Prisma). Plus, in our case where we're using Angular, the recompiling of the app on change sends the fan into overdrive and I get noticeable lag on application switching. Again, this is on a 2013 MBA, which is almost ridiculous, but I'm that type of person. Still proudly sporting my iPhone SE. My development partner is on the 2019 MBA and has noticed improvement, but albeit rather underwhelming. As an aside, I haven't taken the time to pin point the exact problem, but as much I prefer to use Firefox, it doesn't seem to do a great job of managing resources for the SPAs we're building.
- ricketycricket 7y ago
  Make sure your node_modules directory is mapped to a local volume inside docker (not synced to your Mac). This dramatically improves build performance in Docker for Mac. If using docker compose, try this out https://stackoverflow.com/questions/29181032/add-a-volume-to-docker-but-exclude-a-sub-folder/38601156#38601156 https://stackoverflow.com/questions/29181032/add-a-volume-to...
- ehutch79 7y ago
  This is a dumb question, but you're talking about using docker, right? Doesn't docker spin up an entire vm for containers? That does seem pretty heavy for a MBA of any generation?
  - hobofan 7y ago
    > Doesn't docker spin up an entire vm for containers? (It generally does not. Instead it uses more lightweight isolation primtives. That has always been one of its main selling points.) EDIT: see reply > That does seem pretty heavy for a MBA of any generation? It very much depends on what you are running inside the containers. I regularly have a dev environment with ~8 relatively lightweight containers running on my Early 2014 MBA without any problems.
    - mikewhy 7y ago