Backend (Bubble) Setup
Last updated
Was this helpful?
Last updated
Was this helpful?
If you don't already have an existing Bubble account and app, sign up / log in and create one now. If you have an existing Bubble app you're using you can skip this step.
In your new Bubble app, open Data tab. There will be a default User table with three default fields, email, Modified Date and Created Date.
For this tutorial we will simply add one new field to the User table called Name.
To do this click on the Create a new field and enter Name and select text as the type of data. This will be all that we need for this minimal example. In your application you can add as many fields as you want here including creating new tables (New data type).
Even though you don't see any password field on the User table, there is actually a password field that Bubble hides from for security reasons.
The two fields Modified Date and Created Date are default table fields that Bubble automatically adds for every table so you don't need to create or update the values of these two fields.
You can add some initial data to the user table for testing purposes. To do this, in the App Data tab, click on the User table and click New Entry to add a few rows of users.
This is all that is needed for simple database.
It is always advisable to protect your app data by defining some privacy rules which specifies who can access what information. You can do this in bubble using the Privacy tab. In this tutorial we will skip this step to keep things simple.
In order for any external app (e.g. an appygyver app) to connect to your Bubble backend you need to expose your apps database (Data API) and backend logic (Workflow API).
Bubble has two kinds of API endpoints: 1. Workflow/Backend API - These are endpoints that you use to define some backend logic or operation to perform. For example to sign up or log in users, we will create workflow API endpoints. A workflow endpoint can be a simple action or a very complex logic involving several actions as well as calling even other internal or external endpoints. 2. Data API - These are endpoints that provide CRUD (Create, Read, Update, Delete) operations for your database. For example to retrieve a User or list of Users we will use a data API endpoint.
To do this click on the Settings on the left side bar and click on the API tab. Check the box This app exposes a Workflow API. This means that external apps can connect to the API endpoints you define in you backend. The provided endpoint is what you will use in AppGyver as your base endpoint (will come to this later).
Check the box This app exposes a Data API. This will ensure that external apps can assess your database tables. Since we have only the User table in this example check. If you have more tables in your database you can select which of the tables you want to expose to external apps.
We will define 3 endpoints for signup, login and logout.
Click on the top left page search bar as indicated below and click on Backend Workflow.
Click on Click here to add an endpoint ... and choose General > New API Endpoint.
Give the endpoint a name such as signup. Check the option to run the endpoint without authentication, and add three text parameters, one for the email address and one for the password and one for the name.
Add an action under the new endpoint, selecting Account > Sign the user up. Select the email and password parameters you specified. Click on Change another field and select the Name field that we created.
Using the same process as the signup endpoint above, add another endpoint for login with two text parameters, email and password.
Add an action under the new login endpoint, selecting Account > Log the user in. Select the email and password parameters you specified.
Check Stay logged in. This will cause the user to remain logged in for 1yr (31536000 seconds) unless they log out. If you don't check this box the user will remain logged in only for 24hrs.
Pro Tip: Whenever you call the login endpoint Bubble will return a field called expires which determines how long the user will be signed in until they log out. So you can use this field to determine when to refresh the log in token.
Using the same process as the signup and login endpoints above, add another endpoint for login this time without any parameters since a logout doesn't require any.
This time uncheck the box This endpoint can be run without authentication. As you may expect you need to be logged in to logout and therefore this call needs to be authenticated, i.e. you will need to provide a token in the Authorization header of the call (will explain the Authentication process later below). Bubble uses the authentication token to determine which user to logout (technically bubble simply makes that token invalid or expires it)
Add an action under the new login endpoint, selecting Account > Log the user out.
We have not completed creating our api endpoints and together with the CRUD data endpoints Bubble automatically generates we have all we need for our backend. Before heading to AppGyver to setup our front-end, let us generate an API documentation for our endpoints and test them.
Bubble automatically generates a Swagger (OpenAPI) specification file for your app. This file basically describes the structure of your API allowing you to generate documentations or importing your APIinto tools that supports this (hoping that AppGyver will support importing a swagger file instead of manually specifying endpoints one by one in the AppGyver editor).
Every bubble app that exposes an API (either Workflow or Data) has a swagger file located at :
where yourappnameurl is the url for your app. For example our app name url is https://appgyvertutorials.bubbleapps.io/version-test
So our swagger specification will be hosted at https://appgyvertutorials.bubbleapps.io/version-test/api/1.1/meta/swagger.json
By default every bubble app will have the bubbleapps.io domain suffix. So if you name your app myapp1 your initial domain name will be https://yapp1.bubbleapps.io. You can move your app to your own domain to remove the bubbleapps.io suffix so that your app can be hosted at say https://myapp1.com
Bubble automatically creates two versions of every app. A development version and a live version. The development version will always be hosted at yourappdomain/version-test
Enter your swagger url into any browser and you will see the content or your swagger like below:
For this tutorial we will use the online swagger editor for testing our created API. Copy all the text from your swagger file above and head over to the online free swagger editor at https://editor.swagger.io/
Click on File > Import URL and enter your swagger url into the text box and click OK.
The tool will import your swagger file and generate a nicely organized api documentation for you (You can can actually host this online and share with your developers or other 3rd parties that may need to consume your app API). On the right handside you will see the three workflow endpoints we created for the signup, login, and logout as well as the data CRUD endpoints that Bubble generates based on your database. You can also see the base url for your API (we will need this in AppGyver).
To test any of these endpoints click on the name of the endpoint, example signup, and click on Try it out. As you can see below the documentation shows the specification of the endpoints request and different responses.
Enter some values for the email, password and Name fields. and click on the Execute button.
As you can see from the example above, the call was successful and returned a 200 Response. The body of the 200 response contains the fields user_id, (a unique id for the newly created user), token (an authorization value to make authenticated calls as this user) and expires (number of seconds before this token expires).
If we were to inspect our bubble database we will see the newly created user as shown below:
Bubble uses the Bearer Authentication scheme for authorizing calls. This means that all authenticated calls should include in the Header the following Authorization field.
Where the <your_api_token_here> is the token received when you call a login or signup endpoint.
Bearer tokens can also be passed as in as url query strings. This is how the Swagger file generated by Bubble is specified. But for security reasons when making calls to your Bubble API Bearer tokens SHOULD NOT be passed in page URLs (for example, as query string parameters). Instead, bearer tokens SHOULD be passed in HTTP message headers or message bodies for which confidentiality measures are taken. Browsers, web servers, and other software may not adequately secure URLs in the browser history, web server logs, and other data structures. If bearer tokens are passed in page URLs, attackers might be able to steal them from the history data, logs, or other unsecured locations.
For our testing purpose since the default swagger file generated by bubble uses the token in the as url query string we will stick with that (but when making calls from AppGyver we will user the Header instead). In the Swagger Editor you can test authenticated calls by clicking on the Authorize .
Enter the api token value returned from the login or signup call and click Authorize .
Now all calls that require authentication will be passed the token specified.
Now let us try to retrieve a User from out data API. The enpoint for this is the GET baseURL/obj/user/{UniqueID}.
Click on it from the list of endpoints. For the UniqueID parameter enter the test one authenticated call, example the GET User endpoint. Click on the endpoint and enter the user_id returned from the signup (login) call and click on Execute.
This should return a 200 response as like below showing the details of the user we created earlier.
This completes the Bubble part of this tutorial. We can now head over to AppGyver to create an app using our Bubble API.
