Microservices Pattern

Idea
1

This is what I am thinking…

Lets say I have a client who wants an application to do the following:

  • contact management (i.e. CRM)
  • content management (i.e. CMS)
  • asset management (document, image sharing)
  • event management
  • campaign management (integration with Mailchimp)
  • comms management (integration with Twilio)

What I would like to do is set up a Bubble application for each area of responsibility (i.e. microservices). Then use API to pass messages across applications to change state.

What I would also like to do is have a separate Bubble application (although this could be done using a message service like Kafka) to keep a log of all component activity for auditing (and reporting).

I am wondering if:

  • this is overkill
  • I will end up having a massive bill from Bubble because I am using so many applications (I presume each app will need to be on a paid plan?)
  • managing the client user permissions across applications will get unwieldy

I also haven’t found a way to trigger a workflow to keep the audit trail. What I want to do is say: “if any field in this application is updated, then update an audit log table with the detail” (I was thinking a dedicated data type to track this would be the way to go; but what I would really like is a server-side API workflow to push the change directly to a dedicated Bubble app for logging, or to a Kafka instance).

I dunno… I’m still working on the idea but would really appreciate any feedback or suggestions! Thanks :smiley:

2

This is totally overkill for Bubble, IMO. For one, you’ll likely need a paid account for each app. The second issue I see is related to speed. Microservices work best in environments with low-latency and high dependability, neither of which are really Bubble’s strengths. You’re also going to run into the issue of capacity. If there’s high traffic to the point where microservices make sense, you’ll need to worry about not one, but MANY Bubble apps timing out due to capacity thresholds being met.

3

To me it seems like overkill to build separate apps.

For auditing, I think an “audit” table would be ideal. This will require adding some type of action/step in all your workflow to “log” to the audit table.

A few of us have created “log” tables before to help with troubleshooting, but an “audit” table would/could be very similar.

image
image1308×717 114 KB

You could even go so far as to create a “deleted records” table to store all deleted records for some time period – although this may take some thought around how to make a unified table for all data types – maybe store them as JSON in a field that you can restore into the correct data table in the future.

4

Cool, thanks for the feedback.

I suspected it was overkill but good to sense-check these things!

I’ll just incorporate all the functionality within a single app and monitor the performance.