Does it make sense to use both Bubble and Backendless together?


#1

Hi dropsourcerers! Has anyone incorporated both Bubble and Backendless together into their Dropsource app?

I ask because I’ve been building everything using Bubble as a backend with great results, but as of late, Backendless has added some api functionality that solves one of my biggest hurdles involving natively making Stripe payments. Ideally I’m thinking what I want to do is tie Backendless into my current Dropsource + Bubble setup.

I’m rather new to Backendless but I’m a quick learner. Just wanted to get a few others’ opinions on this kind of setup. Thanks.


#2

I think using two different backends for the same app might cause some friction as you might have to transfer some data from to another.

Personally I’m begining to like Backendless for some of its features especially the ability to host my own instance.
So will consider it for some future projects where I require less server-side application logic.

But coming back to your use case, if the only reason you want to use backendless is the stripe integration then I will advice you not to use both.
You can do the same stripe integration that Mark showed with backendless in bubble easily.
I’ve intentionally refrained from showing how to do it in Bubble because while this approach is easy to integrate its going to take a lot of effort to be PCI compliant.
You can read the discussion I had with Mark on the post he showed the video of the Stripe integration in Backendless.

Also in terms of cost note that both bubble and backendless are not free so using both means paying for two backends.

So I will advice you to decide on one and use that exclusively.

There are many good reasons to use Backendless to power your dropsource app but if the only reason you’re considering is the stripe integration demonstrated then I will say don’t.
Because you can do the same stripe integration with Bubble.


#3

Thank you for the feedback. I currently have a working setup between Stripe, Bubble, and Dropsource by way of using webview.

I referenced your post here to figure that out:

I was thinking that maybe the backendless integration would allow for a better experience if I could keep everything native. I’ll continue to work with the bubble approach for now. Thank you again.


#4

You can actually do the same “native” stripe integration in Bubble like in the backendless without using webviews.


#5

@markpiller tapping you on the shoulder if you’d like to add any thoughts on the topic here.


#6

I can think of 1000 reasons why one would want to use Backendless vs Bubble, but being the founder of the former, my opinion would be somewhat biased :slight_smile: I’d be interested to see how “easy” it would be accomplish the same Stripe integration with Bubble and by same I mean not only proxying the requests, but handling callbacks, creating an audit record in the database and notifying all messaging subscribers in real-time when the transaction goes through, that’s what Backendless/Stripe integration is about.

Cheers,
Mark


#7

Bubble doesn’t offer real-time messaging so nothing to compare there.

For the rest its actually very easy. One could simply do all the card tokenization and charging client-side in dropsource. Personally i think that is more secured than proxying the request through the backend.

Handling callbacks in bubble and creating the records too is very easy.

Give me like 30mins and i will demonstrate these.


#8

When a transaction is processed, Stripe notifies it through a webhook, which requires a backend, so doing the entire thing in Dropsource would not give you a guaranteed notification of the transaction status.


#9

Yes agree but you could improve the security of the process by restricting the tokenization and charging to dropsource.
Then define a webhook in the backend that will be notified when stripe charges a card.

I’ve put something quick and dirty and will show it in a moment.


#10

With the way we did it, nothing prevents the developer to do tokenization directly with Stripe right from their Dropsource project and then process a transaction using token/amount with an endpoint we expose (there is an endpoint that does just that).


#11

Here is a quick demo of what i describe.
As you will see all the tokenization and charging are done in dropsource.

Then i setup a webhook in bubble that listens to notification from stripe when a charge is created.


#12

Yep.
IMHO i don’t think its worth it (for the sake of PCI compliance) proxying card details through your server just so you can save the developer making one api call.


#13

Thanks for the video, @seanhoots. What I see is a demo showing that it is possible, however, what I demonstrated here is not just a demo but also a solution which actually shows how to accomplish it. You’re not that far though, to make it useful, it would help to show or share your Swagger file and any code you had to create to process the webhook callback.

Cheers,
Mark


#14

Yes as i said i wanted to show you that it was possible and very “easy” to do this.
I spent only about an hour for the entire process (I’ve worked with stripe a lot and have created stripe plugins for bubble so i knew my way around things).

This wasn’t meant to be a tutorial but just to show that it was possible and “easy” to do when you threw me the challenge.
Again as i mentioned up in this thread i’ve tried to refrain myself from doing this for myself or showing this on this forum for about a year now because of the PCI compliance issue we discussed on your tutorial post.

I will find time to show how i did it and share my swagger file.


#15

Here is the walk-through tutorial for the card process with a link to the swagger file used.

Since this integration doesn’t require any backend i’ve separated it from the webhook part.
I will create a separate video for the webhook using Bubble.