[FIXED] How to manage axios in monorepo

Issue

I have monorepo with multiple clients and I try figure out how to manage axios in this project.

Assumptions:

1. Multiple clients may or may not have the same interceptors,
2. clients have shared API endpoints (shared composables i.e. user.composable -> getUser(): IUser), but also have own ( user.composable -> getClientXData(): unknown) which cannot be compiled and visible at others builds.

monorepo/
├─ apps/
│  ├─ client1/
│  │  ├─ composables/
│  │  │  ├─ user.composable.ts
│  ├─ client2/
│  │  ├─ composables/
│  │  │  ├─ user.composable.ts
│  ├─ client3/
│  │  ├─ composables/
│  │  │  ├─ user.composable.ts
├─ packages/
│  ├─ composables/
│  │  ├─ user.composable.ts
│  ├─ models/
│  │  ├─ IUser.ts

Do you have any ideas how to manage this?

Solution

I would have create an axios service package which any app can consume, but not exactly as it sounds.

First, avoid adding interceptors on the default axios instance. Instead, create new instances which any app will consume by it own needs. (you can also defined shared interceptors for them on the default axios instance)

In addition, I might follow OOP principals with Factory Design Pattern. I would have create a class with all shared API endpoints, and some other classes for each app or behavior which extends the base class with it own API endpoints. now any app can consume the axios-service and get it relevant endpoints the property it pass to the factory.

Answered By - Yarin Barnes

Answer Checked By - Dawn Plyler (PHPFixing Volunteer)

Read More

[FIXED] How to version products inside monorepo?

Issue

I have been educating myself about monorepos as I believe it is a great solution for my team and the current state of our projects. We have multiple web products (Client portal, Internal Portal, API, Core shared code).

Where I am struggling to find the answer that I want to find is versioning.

What is the versioning strategy when all of your projects and products are inside a monorepo?

• 1 version fits all?
• Git sub-modules with independent versioning (kind of breaks the point of having a mono repo)
• Other strategy?

And from a CI perspective, when you commit something in project A, should you launch the whole suite of tests in all of the projects to make sure that nothing broke, even though there was no necessarily a change made to a dependency/share module?

Solution

What is the versioning strategy when all of your projects and products are inside a monorepo?

I would suggest that one version fits all for the following reasons:

• When releasing your products you can tag the entire branch as release-x.x.x for example. If bugs come up you wouldn't need to check "which version was of XXX was YYY using"
• It also makes it easier to force that version x.x.x of XXX uses version x.x.x of YYY. In essence, keeping your projects in sync. How you go about this of course depends on what technology your projects are written in.

And from a CI perspective, when you commit something in project A, should you launch the whole suite of tests in all of the projects to make sure that nothing broke, even though there was no necessarily a change made to a dependency/share module?

If the tests don't take particularly long to execute, no harm can come from this. I would definitely recommend this. The more often your tests run the sooner you could uncover time dependent or environment dependent bugs.

If you do not want to run tests all the time for whatever reason, you could query your VCS and write a script which conditionally triggers tests depending on what has changed. This relies heavily on integration between your VCS and your CI server.

Answered By - bitshift

Answer Checked By - Willingham (PHPFixing Volunteer)

Read More

[FIXED] What is the best strategy for building microservices in a mono repo?

Issue

I have a mono repo (git) which houses multiple microservices that I am working on. On push, the 3rd party build service detects this push and starts processing the build and deployment.

This works great. But now I am trying to optimize this process and I would only like it to build the particular services I have been working on. This means that the build services has to detect which folders have been changed and build those services only.

I have gotten this process to work on Travis pretty well because it has a GIT_COMMIT_RANGE environment variable. So I can get all the commits in my latest push and then across all those commits get the folders that have changed.. this works really well.. but ONLY on travis.

I wish to cut out travis and build my docker images directly on a GCP or whatever other 3rd party container builder I am using, but I only wish to build the folders that have changed.

I am thinking that it might be possible to do this with a git commit hook. Through this hook I can start generating a list of folders to mark for the build server to build, or even start generating a build file (cloudbuild.yaml). Then on some git push hook, (is there even a post-push hook) I reset the contents of the cloudbuild.yaml file locally.

Solution

I have actually managed to solve this problem in a different repo using github actions

lucky for me someone created a github action to filter folders that have changed

- uses: dorny/paths-filter@v2
    id: changes
    with:
      filters: |
        src:
          - '<folder to check>/**'

In your following build steps you can then use an if statement to trigger the step if the path filter has returned true:

- name: Build node
    if: steps.changes.outputs.src == 'true'
    run: |
      <command goes here>

As you can see src will return true if anything in the subfolder has changed.

The action repo is available here https://github.com/dorny/paths-filter

Answered By - tensai

Answer Checked By - Mary Flores (PHPFixing Volunteer)

Read More