New Feature - Network Activity Log


#1

Hello everyone! Extremely pleased to highlight a new feature in today’s release that I think is going to make troubleshooting your API integrations in Dropsource a lot easier - Network Logging. :tada: :fireworks: :balloon:

With your app open in the simulator, switch on the Network Activity Log and check out the detail of what your API is doing when your app runs a request. Select the request (in the example below it’s the line that begins “json” and has a query string) and open Preview to see the structures the API is returning to the app.

Just a note that your log will clear when your Appetize session times out so to keep your info visible just interact with the virtual device when it displays “Inactivity Timeout” - this is something we’re hoping to improve in a future version of the feature.

You’ll find info on using the log in a couple of places in the help center - the interaction should be fairly familiar if you’re accustomed to using your browser dev tools:

I know from personal experience and from talking to our community members how much of a pain point figuring out what your requests are doing can be. What is Dropsource receiving, what is my API receiving, is the request running, is the data empty etc etc. In the past we’ve more or less had to rely on external tools such as Postman and Stoplight to troubleshoot these issues, but with this update we can get to the source of an issue without leaving Dropsource.

I’d love to hear what everyone thinks about this - try it and let us know how you get on! What problems can you see this helping to address in your projects? Is the network log easy to use or is there anything you find confusing about it? Anything else you’d prefer done differently?


#2

Great! Thanks guys.
Definetely this is going to be very useful in debuging.
Most web developers are familiar with the Network tab in the chrome developer tools so this is a very welcomed addition.

Already I think i’ve been able to use it find a bug in Dropsource.
Dropsource is sending the wrong Patch request when the table contains a bubble geographic address field and it is not bound in the request.

You may have seen users complaining about not being able to make patch calls to their Bubble backends.
I think this is one of the reasons.

I just built an example app to figure out why making the calls in postman works but making it from dropsource isn’t working.
Using the new network logs feature, it shows that Dropsource is sending a bad request when making a PATCH request to a bubble table that has a geographic location field.

In my example below, i have a Patch call to my User table in bubble and i just want to change the age field.
As you can see below, i’ve not bound the location (a bubble geographic address), first name, last name and last tracking fields, only the age field is bound to a value because that is what i want to update.

But from the logs below, Dropsource seems to be adding the location field to the call to the patch call even though i didn’t bind the location field. So the call fails because the location field that Dropsource added doesn’t have any values.

To verify this, first i decided to bind both the age and location fields living the other fields and this time the call succeeded.

Also when i deleted the location field (a bubble geographic address) address from my table, the call succeeded as shown below


[Half -Solved] APP Crash on PATCH Api Request
#3

This is indeed an awesome addition! Thank you @sue and the rest of other dropsource team!

@seanhoots, Interesting observation. I checked my own patch problem and noticed that the same problem.


#4

Wow you put that to use quickly! :grin:

With the patch endpoint I wonder if there is something different about the way the location fields are represented in the Swagger spec - would you mind forwarding me the spec for this or a link to it so that we can troubleshoot?


#5

Great. I’ve messaged it to you.


#6

Thanks for that, I’ll share it with our QA team and developers to see if we can troubleshoot.


#7

Just to clarify, is this location field the only thing you’ve encountered this with or do you think it’s more general to patch requests?


#8

I haven’t tried with other fields. Have only had issues with the geographic location. But i won’t be surprised if it is general to non-basic fields. By non-basic i mean a field that is not a simple time like text, number, etc.
As you may be aware the geographic location field consists of three components (lat, lng, name). I wan’t to suspect any table that has a complex field might experience that issue. That is something your engineers could test.


#9

Thanks, that’s exactly what I was thinking too, I’ve used patch requests to Bubble successfully before but I think my endpoints just had simple fields, no objects etc.


#10

Any idea how I can quickly populate a field in my test Bubble backend with a sample value of geographic address type? Just so that I can try out an endpoint using it.


#11

It’s cool I just used the post endpoint to create one from my Dropsource app lol.


#12

So i don’t think you can just type into an address field some address because it is an object with name,lat,lng.
So you will have to create a page, add a Search box and set the Choices style to Geographic places.
Then you can add a button and create a workflow to save the value in the Search box to a thing.
When you preview the page you will be able to auto type in an address.
Alternatively you can pm me your bubble editor and i can do that for you.


#13

OK I believe I have reproduced this, I’m seeing an empty object being sent for both patch and post requests containing the geographic address type when the fields inside it have not been bound. Does that sound correct or have you used this successfully with post requests?


#14

I can send a post and patch successfully when the geographic address is bound. The only problem is when you make a patch request and you don’t bind the geographic address.
With a patch request i should be able to bind any of the fields but it seems dropsource always include the geographic address field even if you don’t bind it thereby causing the bad request error


#15

OK just to confirm we have been able to reproduce the issue with Bubble endpoints and our QA engineers are looking into it.


#16

It looks like it has been 12 days since last post. Has the Dropsource team been able to solve this?


#17

A fix for the empty object issue is in development but has not been released yet, I’ll post back here when it’s released.


#18

Any update on API Patch? What’s the solution now if the table has geographic address but we don’t plan to update it through API call?


#19

Hi guys, apologies for the delay, the fix for this issue has turned out to be a complex one that affects other areas so it’s taking a bit longer than expected but is being worked on.


#20

Hi @Dropsource, why is my Preview and Response tabs of the Network Activity log always empty even when the api has a response data that is correctly being displayed in the app?