Complex bubble searches or joins in dropsource


#1

Within Bubble, I’ve put together a “groupon” site. There are multiple vendors, each offer multiple deals.
I am trying to create a dynamic list of vendors in my dropsource android app. On each tile, I would like to list the number of deals belonging to the vendor.

In bubble, I search for all deals that contain the vendor’s vendor_id. The count of that result is what I’m looking to display.

How does that magic happen in Dropsource?


#2

There is a tutorial to connect to bubble data base

You just need to change the type of the constraint used in the tutorial to the one you need


#3

Are custom data types the same as constraints?


#4

No.

When you do a search in bubble you used constraints to narrow the result, in your case you would do a search for deals and set a constraint like “vendor contains vendors id” you can set that type of constraint in an API call from dropsource to bubble. The tutorial i have just mention is really usefull for that types of API call


#5

If you used stoplight to create your API swagger file then it will include 200: response that you can use in your app for counting how many records were returned (see image)


#6

and this is how i use the count in my app to give feedback when no data is returned


#7

@Erics, Stoplight looks amazing. Really involved and a great way to visualize endpoints.

@karris7, Would it make more or less sense to create a custom Bubble endpoint for each app page? I don’t know enough about Dropsource to know if that’s a ridiculous question.

Thanks for your help with this.


#8

Hey @scottb50, what do you mean by “bubble endpoint for each app page”.
You can create as many api workflow endpoints in bubble as you want and call them in your dropsource app.
You can have several api calls on one page or call same api on different pages.


#9

I love that.

What I’m wondering is if it’s easier or wiser to create an endpoint in Bubble vs. Bubble constraints in Dropsource.

For example: 2 Bubble Tables

-Store
--store_id
--store-name
--store-address
--store-logo

-Coupon
--Coupon_id
--store_id
--Coupon-name
--coupon-start-date
--coupon-end-date

I could create an endpoint in Bubble that accepts the store_id and returns all elements from both the store and coupon tables. Or it seems like I can also create a Bubble constraint on the get/coupon endpoint for store table data.

Will both approaches return a table data from both tables?

Thanks as always!


#10

Yes you can let both of them return a table (object).
The issue is that when you create an API workflow that returns an object, e.g. Store, bubble only returns it as a string (text).
So you will have to manually open the swagger file and edit it to return an object.
It’s very east to do though.
Just look at how the other GET endpoints are defined to return an object type and copy and replace the string return type with the same thing.
It’s just a one line change.
Generally you can define your constraints in dropsource as others have explained above. But I find it more easier and flexible doing it in bubble with the api workflow. But you just have to make this small change I described to return a table (object)


#11

thanks @seanhoots you just open a world of possibilities, thanks @Erics. i would love to see and example of that, that what made me stuck. I have been told to use spotlight.io for that, but i feel a little lost with the tool, and manipulating API files.


#12

I just found this tutorial you posted in bubble forum. @seanhoots

I will do it as soon as possible.


#13

This is to clarify things for those that are still a bit confused with swagger, stoplight and Bubble swagger file.

  1. Swagger is a specification or a way to describe an api so that some services like dropsource can use the api. The swagger file define the path(link) to the api, the data and types that the api consume and returns.
  2. While u can create this file manually it is highly not recommended as you’re bound to make a lot of mistakes. That is where the stoplight tool comes in. It’s simply a tool to help you write a swagger specification given an api endpoint. The tool will ask you for things like the path for the api, the name and type of the parameters that the api consume. The name and type of parameters that the api return. Authentication method, etc. Then it will generate the swagger file for you which you can import in dropsource.
  3. Bubble in their attempt to simplify things for its users automatically generate this swagger specification from you bubble application. But there are some few instances where you will have to manually make some few changes to the swagger file that bubble automatically generates. e.g. sending a picture to an endpoint, returning an object type (user defined Things/Tables /Types) from an api workflow, etc. To make such changes you don’t need stoplight. You manually open the file and make the necessary small changes.

So @karris7, if you’re using bubble and have all your endpoints defined in bubble, then you don’t need to touch stoplight. Just download the bubble swagger file (the link you enter into dropsource) and make the manual edits when needed.


#14

This video is hot off the press, more background on swagger API standard
https://swagger.io/blog/api-development-with-openapi-and-swagger/?utm_source=email&utm_medium=DDD&utm_campaign=swaggerhub


#15

Am I comparing the correct two snippets (below)?

Is it the beginning “get”/“post” or is it the the tags “Workflow”/“Data”?

Workflow:

"/wf/deal-search": {
            "post": {
                "description": "Triggers the workflow deal-search",
                "parameters": [
                    {
                        "name": "deal-search request body",
                        "in": "body",
                        "description": "Body of the POST request",
                        "schema": {
                            "$ref": "#/definitions/deal-searchBody"
                        }
                    }
                ],
                "tags": [
                    "Workflow"

Get:

 "/obj/deal": {
        "get": {
            "description": "Retrieve a list of things of type deal with some optional search constraints. Retreives 100 items at most at once.",
            "tags": [
                "Data"
            ],

It also seems like parameters are structured different differently, but that’s more than one line of changes.

Thanks!


#16

Am I comparing the correct two snippets (below)? Is it the beginning “get”/“post” or is it the the tags “Workflow”/“Data”?

Get:

 "/obj/deal": {
        "get": {
            "description": "Retrieve a list of things of type deal with some optional search constraints. Retreives 100 items at most at once.",
            "tags": [
                "Data"
            ],

Workflow:

"/wf/deal-search": {
            "post": {
                "description": "Triggers the workflow deal-search",
                "parameters": [
                    {
                        "name": "deal-search request body",
                        "in": "body",
                        "description": "Body of the POST request",
                        "schema": {
                            "$ref": "#/definitions/deal-searchBody"
                        }
                    }
                ],
                "tags": [
                    "Workflow"

It also seems like parameters are structured different differently, but that’s more than one line of changes.

Thanks!


#17

Are you returning a single object or you’re returning a list (array) of objects?
Also note that"$ref": "#/definitions/deal-searchBody" is for the body (input parameters) of the endpoint.
What you need is the return (output) definition. Should be something like "$ref": "#/definitions/deal".

If your endpoint is returning an array of objects instead of a single object then you should be looking at "obj/deal/{UniqueID}" and not "obj/deal" which is getting or posting an array of deals


#18

Here is an example form my app. I had an object called Entry.
What bubble generated for the Post method of "obj/entry/{UniqueID}:

"200": {
		"description": "Workflow response",
		"schema": {
			"type": "object",
			"properties": {
				"status": {
					"type": "string",
					"description": "Outcome of the workflow"
				},
				"response": {
					"type": "object",
					"properties": {
						"entry": {
							"type": "string",
							"description": "entry ('entry' represented by a unique ID)"
						}
					}
				}
			}
		}
	},

The change i made for a workflow endpoint that returns a single entry object "wf/nextentry"

"200": {
		"description": "Workflow response",
		"schema": {
			"type": "object",
			"properties": {
				"status": {
					"type": "string",
					"description": "Outcome of the workflow"
				},
				"response": {
					"type": "object",
					"properties": {
						 "entry": {
							"$ref": "#/definitions/entry"
						}
					}
				}
			}
		}
	},

As you can see it’s only one line change from type: string to "$ref": "#/definitions/entry".
That is bubble was just returning a string. But you want it to return a whole object with several fields which are defined in the definition sections.

For a list of objects it should be something like:

"results": {
	"type": "array",
	"items": {
		"$ref": "#/definitions/entry"
	}
}

#19

I changed #/definitions/deal-searchBody to #/definitions/deal-search and received:

If I use the #/definitions/deal in the description of the wf/deal-search, the API gets updated in Dropsource, but I get the info as if I were to use the regular Get statement.

I’m looking for an array of all deals returned.

This is how it looks in Bubble with the return of the “deal” data combined with the deal’s destination data


#20

I’m trying your fix now