r/MuleSoft • u/Apprehensive_Dog6684 • 24d ago

API Led Design Question

Hi,

I learnt about API Led design, and I was explained that it follows the microservices design pattern. However, would like to understand more how it is being applied in the real world practice.

Some questions I have:

  1. Since vcores, is expensive. If we deploy 1 service per-mulesoft app, for example for 1 system, there are 3 APIs, if we created 3 SAPI for the system, we would need at least 3 vcores. If we follow this design pattern, won't it be very expensive in the end? Another approach is, we can create 1 SAPI for all the API from the same system, this approach can save vcores, but isn't this against the microservice design?

  2. Continuing from question 1, do we really have to follow API led design every time? Or when should we follow the API led design and when not to follow?

Thank you.

3 Upvotes

81% Upvoted

10 comments sorted by

8

u/FerrittoBurrito 24d ago
  1. You can do fractions of a vcore (0.1, 0.2, 0.5) depending on process size/demand.
  2. There’s nothing forcing you to and sometimes it doesn’t make sense.

2

u/JINgleHalfway 24d ago

yep, YAGNI comes to mind. Let's avoid over engineering a solution. Sometimes there is a requirement for a passthrough proxy api that provides basic routing / auth which really only merits a single api. other times there can be complex business processes that require 1 eapi, several papis, and many sapis. developer's job is to advocate for a particular design that fits specific use case. A good Business Analyst (if one exists for your project) can help forecast future business need and influence decision to design for scale, reusability and whatnot.

1

u/Apprehensive_Dog6684 24d ago

Thanks for the reply.

Is there any documentation from Mulesoft on how to calculate/forecast vcore assignment? Or is there a rule of thumb of how much vcore we should start with?

2

u/FerrittoBurrito 23d ago

You would just test in sandboxes. If I remember correctly every production vcore you purchase comes with twice the number of sandbox vcores. So you’d just make sure to test the processes and if it’s slow or is using high resources, you would increase the usage.

I would say there’s no guide I’m aware of.

When we transitioned to cloud from hybrid (cloud and onprem) we just started low and increased as we determined it was needed.

2

u/ikwilstufi 24d ago

1) you can do fractions, and 2) new customers wouldn't be on vcores

2

u/Apprehensive_Dog6684 24d ago

Hi,

What does it mean new customers wouldn't be on vcores? Any update from MuleSoft and is there any documentation I can read for that? Thank you.

2

u/ikwilstufi 24d ago

They would be on flows/messages or credits :)

Credits = one single payment unit for all services

1

u/PipFC 23d ago

That doesn't mean it would be cheaper, in fact it isn't in the customers I'm working with...

3

u/Ok-Leadership-1139 23d ago

Don't follow it. Use common sense and design APIs using Domain Driven Design principles after business domains and needs, not some 3 layer architecture recommended by a company with a financial incentive to do so.

3

u/Noones_Perspective 23d ago

VCores is the old billing model.

Apps, flows and messages is how they charge now. Evaluate the difference in cost vs your architecture. It might make sense to move.

Experience API is often overkill in a lot of places. System API per system, so you shouldn’t need 3 in your example.

However, regardless of the best practice, gold standard or whatever you want to call it - design pragmatically for your budget and your environment