Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Bracket (YC W22) – Two-Way Sync Between Salesforce and Postgres

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 82 posts

Re: Launch HN: Bracket (YC W22) – Two-Way Sync Between Salesforce and Postgres

#71

Post by ianyanusko »

no_wizard wrote: post #68
vinarun wrote: post #21

Earlier quoted context omitted.

Yeah agreed! We were surprised to hear how deeply bundled Heroku Connect is in their Enterprise plan. Reps not knowing about heroku connect coupled with their abandoned roadmap make us excited to build a better solution

I know this is a late comment, but I have to ask, what do you think the market opportunity is on this? 500 million? Billion? Billion plus? I'm curious how big a business like this can grow, by estimation, based on someone else's platform like this.

Good question. Our ultimate goal is to be the go-to for any two-way data syncs.

We think the Salesforce syncing market by itself is 500 million to 1B. If you start including all of the tools we have our eyes on (Hubspot, Monday, ERPs), the market size comfortably gets into the billions.

Going after Heroku Connect makes sense as a starting point, but we've got our sights beyond that.

Re: Launch HN: Bracket (YC W22) – Two-Way Sync Between Salesforce and Postgres

#72

Post by kunalrgarg »

atraac wrote: post #65

We've built similar thing to sync certain Salesforce objects to our .NET backend but Salesforce has their streaming all built around CometD which uses something I believe an insane person came up with - Bayeux Protocol. It's essentially an HTTP streaming, you shoot a GET call to an API and it starts streaming bytes of data. If it stops or timeouts, you're supposed to shoot another GET to continue streaming bytes, if…

Wow congrats on making it through with CometD and Bayeux. I think salesforce has realized that a lot of their APIs aren’t useful when using non standard approaches. I think the move from SOAP to also including REST was a signal that they’re trying to be more useful in this realm. I definitely agree a RabbitMQ sink would've been so ideal! I’m hoping it’s somewhere on their roadmap to make our lives easier.

Re: Launch HN: Bracket (YC W22) – Two-Way Sync Between Salesforce and Postgres

#73

Post by kunalrgarg »

robertlagrant wrote: post #66
atraac wrote: post #65

We've built similar thing to sync certain Salesforce objects to our .NET backend but Salesforce has their streaming all built around CometD which uses something I believe an insane person came up with - Bayeux Protocol. It's essentially an HTTP streaming, you shoot a GET call to an API and it starts streaming bytes of data. If it stops or timeouts, you're supposed to shoot another GET to continue streaming bytes, if…

From memory, one reasonably good solution I saw was with a company called Validic that did IoT integration stuff for medical devices. They got you to set up an HTTP SSE stream, that you just connected to and consumed from as and when events came through.

I haven’t heard of Valadic, but I’ll definitely check it out. Thanks for flagging!

Re: Launch HN: Bracket (YC W22) – Two-Way Sync Between Salesforce and Postgres

#75

Post by wmfiv »

atraac wrote: post #65

We've built similar thing to sync certain Salesforce objects to our .NET backend but Salesforce has their streaming all built around CometD which uses something I believe an insane person came up with - Bayeux Protocol. It's essentially an HTTP streaming, you shoot a GET call to an API and it starts streaming bytes of data. If it stops or timeouts, you're supposed to shoot another GET to continue streaming bytes, if…

I don't have any first hand experience but there is an integration with AWS EventBridge.

https://aws.amazon.com/blogs/compute/building-salesforce-int...

I know even less about Azure, but it looks like Azure Data Factory (?) provides some kind of similar functionality?

https://learn.microsoft.com/en-us/azure/data-factory/connect...

Re: Launch HN: Bracket (YC W22) – Two-Way Sync Between Salesforce and Postgres

#76

Post by jgraettinger1 »

trollied wrote: post #20

Get in touch if you want to expand to NetSuite. We can have a chat...

If one-way sync will do, we (Estuary) have been investing in a NetSuite connector that we've _just_ started testing with a few customers. Both SuiteAnalytics and SuiteQL with full support for custom tables & schema.

[1]: https://docs.estuary.dev/reference/Connectors/capture-connec...

Re: Launch HN: Bracket (YC W22) – Two-Way Sync Between Salesforce and Postgres

#79

Post by ianyanusko »

moneywoes wrote: post #64

most difficult part building this?

With Salesforce specifically, getting a stable and reliable event-driven stream. That's why we ended up adopting a hybrid approach of subscribing to pub/sub events, but also periodically polling the REST API in case pub/sub misses anything.

Salesforce's scattered docs don't make best practices super clear, so designing the syncs took us some time.

Re: Launch HN: Bracket (YC W22) – Two-Way Sync Between Salesforce and Postgres

#80

Post by _bry-guy »

ianyanusko wrote: post #62
_bry-guy wrote: post #60

I'm currently on a team tasked with thinning out our Salesforce App Exchange app. Bracket looks very cool. 1. Do you have any plans to release an API rather than utilizing a webapp for defining the sync? 2. Does your Salesforce integration support syncing metadata, including custom metadata? 3. Do you have data on the impact Bracket has on platform events and other Salesforce limits? 4. Can you share any information…

1. Yes, on our roadmap for Q1! Getting that request a lot 2. We don't currently sync metadata 3. Our footprint on your Salesforce API depends on whether you're using polling or streaming, and then it depends on the cadence of your syncs or frequency of changes. You can see some data on best/worst case scenarios here: https://docs.usebracket.com/connecting/salesforce_api 4. Yup, we priced based on the amount of data k…

Great, thank you! Syncing metadata may be a dealbreaker for me, but I'll be thinking of Bracket as we build solutions going forward. Cheers.
Post reply on HN