Wish I could get this same reporting for Javascript and get out of Sentry. Maybe one day! Firebase Functions being able to debug to Crashlytics would be cool.
If you're looking to get more context on exceptions in JavaScript, you could try LogRocket (https://logrocket.com). Similar to how Crashlytics' breadcrumbs feature records user actions leading up to a crash, LogRocket records user actions, network requests, console logs, DOM, and application state in web apps.
For context I’m the founder, CEO, and original author of Sentry. We provide an immense amount of data for every platform and hear the exact opposite of this sentiment (“id love to use Sentry for my mobile apps”).
We’re long past the days of one vendor being able to accomplish every problem (there’s evidence everywhere that this is bad) and while I appreciate competition in the space that’s far different from expecting whichever provider you choose to be a one stop shop.
That’s besides the point that Sentry is open source and we’re the only option out there for a lot of people.
If it’s simply you think Firebase can do a better job than us I want to know why. If it’s consolidation then ask yourself why shouldn’t Google work with others instead of trying to own every space in every market? There’s a lot more value in specialization than there is in checkboxes, especially if it means working with a wider ecosystem.
I mean this as no slight to Firebase as I’ve quite enjoyed prototyping things on the platform, but I can’t get behind the idea that Google or anyone else should hold a monopoly over our ability to write software and build businesses.
For the 'indie' developer, Firebase is a gift. By way of example, I (re)started building an app that tracks anomalies in cryptocurrency volume at the weekend. By building on Firebase (Auth, FireStore, Functions) it's all but ready.
That lack of friction between idea and reality didn't exist too long ago. (Firebase ain't the only ones, Zeit are also doing slightly-different-but-equally-incredible work).
Two points of frustration:
Cost - $0.06 per 100,000 document-reads sounds cheap until you're continuously analyzing streams of market data...but that could simply be a problem with my inefficient code.
Quotas - there's a few minutes delay on removing the quota after upgrading from free to paid plan that shouldn't exist.
Edit: make that three:
The Console - there's quite a few products squeezed into the console and so far it works. But please refrain from becoming like the Google Cloud Platform console which seems to have borrowed design cues from space-shuttle dashboards.
I tried a few charting libraries including Chart.js, Taucharts and D3.
Much of Taucharts is undocumented, Chart.js requires a lot of configuration for something like a mixed chart with stacked bars, and D3, yikes. Its API documentation is thicker than Ulysses.
Highcharts required minimal configuration, had an intuitive and clear API and - most importantly - handled all sorts of messy data I threw at it. It just worked, out-of-the-box.
Thanks for engaging, and hats off for a solid product.
Regarding costs, the quota was hit pretty quickly due to the trial and error of deciding the best way to structure my data so likely a once off spike in DB reads. But good to know I can reach out.
Tbh, I'd trade all my concerns for a timeline on when we'll see collection group queries ;)
As a somewhat frustrated user I can't understand the design decision Crashlytics did that they won't notify you of crashes unless they have a matching dSYM.
I've tried to explain why this complicates the use case for Bitcode enabled apps but so far I've only gotten a shrug back. Their stance is that everyone should check the dashboard daily and see the badge indicating that there's a dSYM missing.
16 comments
[ 1.9 ms ] story [ 15.6 ms ] thread[disclaimer: I work at LogRocket]
For context I’m the founder, CEO, and original author of Sentry. We provide an immense amount of data for every platform and hear the exact opposite of this sentiment (“id love to use Sentry for my mobile apps”).
We’re long past the days of one vendor being able to accomplish every problem (there’s evidence everywhere that this is bad) and while I appreciate competition in the space that’s far different from expecting whichever provider you choose to be a one stop shop.
That’s besides the point that Sentry is open source and we’re the only option out there for a lot of people.
If it’s simply you think Firebase can do a better job than us I want to know why. If it’s consolidation then ask yourself why shouldn’t Google work with others instead of trying to own every space in every market? There’s a lot more value in specialization than there is in checkboxes, especially if it means working with a wider ecosystem.
I mean this as no slight to Firebase as I’ve quite enjoyed prototyping things on the platform, but I can’t get behind the idea that Google or anyone else should hold a monopoly over our ability to write software and build businesses.
For the 'indie' developer, Firebase is a gift. By way of example, I (re)started building an app that tracks anomalies in cryptocurrency volume at the weekend. By building on Firebase (Auth, FireStore, Functions) it's all but ready.
That lack of friction between idea and reality didn't exist too long ago. (Firebase ain't the only ones, Zeit are also doing slightly-different-but-equally-incredible work).
Two points of frustration:
Cost - $0.06 per 100,000 document-reads sounds cheap until you're continuously analyzing streams of market data...but that could simply be a problem with my inefficient code.
Quotas - there's a few minutes delay on removing the quota after upgrading from free to paid plan that shouldn't exist.
Edit: make that three:
The Console - there's quite a few products squeezed into the console and so far it works. But please refrain from becoming like the Google Cloud Platform console which seems to have borrowed design cues from space-shuttle dashboards.
Tech-wise it's Vue.js and Highcharts on the front-end, Firestore on the back, and Zeit now/Firebase functions doing the grunt work on the APIs.
Once it's ready to go I'll pop it on show HN and go into more detail on how it works.
Much of Taucharts is undocumented, Chart.js requires a lot of configuration for something like a mixed chart with stacked bars, and D3, yikes. Its API documentation is thicker than Ulysses.
Highcharts required minimal configuration, had an intuitive and clear API and - most importantly - handled all sorts of messy data I threw at it. It just worked, out-of-the-box.
Feel free to email(dan + mcg at google), Twitter DM, etc more details about your cost concerns.
The quota change issue is complex, but yes we'd like to make it faster :)
Regarding costs, the quota was hit pretty quickly due to the trial and error of deciding the best way to structure my data so likely a once off spike in DB reads. But good to know I can reach out.
Tbh, I'd trade all my concerns for a timeline on when we'll see collection group queries ;)
I've tried to explain why this complicates the use case for Bitcode enabled apps but so far I've only gotten a shrug back. Their stance is that everyone should check the dashboard daily and see the badge indicating that there's a dSYM missing.