3

We've created a Google Cloud Function that is essentially an internal API. Is there any way that other internal Google Cloud Functions can talk to the API function without exposing a HTTP endpoint for that function?

We've looked at PubSub but as far as we can see, you can send a request (per say!) but you can't receive a response.

Ideally, we don't want to expose a HTTP endpoint due to the extra security ramifications and we are trying to follow a microservice approach so every function is its own entity.

Matthew P
  • 717
  • 1
  • 7
  • 22
  • 1
    Maybe this will help https://stackoverflow.com/questions/42784000/calling-a-cloud-function-from-another-cloud-function – Vaisakh PS Aug 31 '18 at 15:13
  • @VaisakhPS That's basically what I said below, but the question was specifically asking about a function call. I added more options here. – Doug Stevenson Aug 31 '18 at 17:19

2 Answers2

2

I sympathize with your microservices approach and trying to keep your services independent. You can accomplish this without opening all your functions to HTTP. Chris Richardson describes a similar case on his excellent website microservices.io:

You have applied the Database per Service pattern. Each service has its own database. Some business transactions, however, span multiple services so you need a mechanism to ensure data consistency across services. For example, lets imagine that you are building an e-commerce store where customers have a credit limit. The application must ensure that a new order will not exceed the customer’s credit limit. Since Orders and Customers are in different databases the application cannot simply use a local ACID transaction.

He then goes on:

An e-commerce application that uses this approach would create an order using a choreography-based saga that consists of the following steps:

  1. The Order Service creates an Order in a pending state and publishes an OrderCreated event.
  2. The Customer Service receives the event attempts to reserve credit for that Order. It publishes either a Credit Reserved event or a CreditLimitExceeded event.
  3. The Order Service receives the event and changes the state of the order to either approved or cancelled.

Basically, instead of a direct function call that returns a value synchronously, the first microservice sends an asynchronous "request event" to the second microservice which issues a "response event" that the first service picks up. You would use Cloud PubSub to send and receive the messages.

You can read more about this under the Saga pattern on his website.

Martin Omander
  • 3,223
  • 28
  • 23
0

The most straightforward thing to do is wrap your API up into a regular function or object, and deploy that extra code along with each function that needs to use it. You may even wish to fully modularize the code, as you would expect from an npm module.

Doug Stevenson
  • 297,357
  • 32
  • 422
  • 441
  • Thanks, Doug, this is a solution, however, this approach doesn't fit with our ideal of every function being a small/microservice, particularly as our API is relatively large and intertwined, it makes it a bit messy. – Matthew P Aug 31 '18 at 16:54
  • I don't think you have an alternative. A microservice doesn't realy imply a small amount of code, it just implies a small amount of overall functionality. – Doug Stevenson Aug 31 '18 at 17:18
  • 1
    Yes, there seem to be no alternatives hence this question however it seems crazy that functions can't directly invoke each other in a request/response fashion. When I was referring to microservices above I was meaning in terms of functionality rather than size - my fault for being unclear. Appreciate your responses. – Matthew P Aug 31 '18 at 17:34
  • 1
    There's nothing stopping you from directly invoking one of your HTTP functions from another function using some HTTP client library. You just have to enable billing on your project. I personally don't think this is a good idea, as it will cost you more and perform worse than just including the code directly into the first function. – Doug Stevenson Aug 31 '18 at 17:45
  • Yes, that was our thinking too and as you say the cost aspect is the pain point due to the one function waiting for a response from the other function whilst still billing us for both. Thanks! – Matthew P Aug 31 '18 at 18:01