I try with the web example, for work with functions and real-time database, and I can't deploy the project when I add the new function 'makeUppercase'. Seems a problem with functions.databasae, because, if I comment the addMessage function all works great. Firebase database collection, You will see only one document. Navigate to the left panel to a grow tab and click on cloud messaging. Click on Cloud Messaging. Now we need to fill in the necessary data. Enter the text of your message and provide the token of the device from the database we just copied.
While I'm sure that Firebase offers a solution to every problem mentioned. I think the real issue here is that by the time you figure out all the little details of how to customize Firebase to work exactly how you want it, you could just have easily have achieved the same result by just using plain Socket.io or a similar library - And the solution would be simpler, cheaper and more maintainable. My point here is not that firebase is the end all be all, but that when you choose to rely on a technology/PaaS you need to do your own due diligence.
Every person, project, company, etc has their own requirements and ability to make certain types of trade offs.If one fails to do their proper due diligence, then they'll end up in a similar situation to OP. And that's okay, it happens to all of us every now and then. But when you screw up that decision despite there being ample documentation, blogs, and known limitations readily available to you with a few Google searches, then IMO it's inappropriate to write a slam piece against the technology/PaaS like OP did. you could just have easily have achieved the same result by just using plain Socket.io or a similar libraryIs this an easier problem than I think it is? Is there a well known path for scaling socket connections and synchronizing data across clients?I suspect most cases where devs talk about a messaging problem, it's really a data synchronization problem. I'm starting to suspect the sweet spot for Firebase in a large application is as a cache and communication mechanism rather than the primary datastore. Is that along the lines of what you're seeing?Firebase has a few subtleties, but its API footprint is small for a datastore.
How much sympathy do we need to have for people that use a tool without reading the docs first?' Free them from having to manage a backend' For a certain class of mobile apps it does. If we want the marketing material to apply to every customer, what PaaS or SaaS company will be left standing? Firebase is great for a couple of use cases - not for an entire SaaS app.Would I use Firebase as a replacement for a relational DB in a traditional SaaS app? However, if I had to add real time chat to an app that had no other real time components I'd probably use it.I agree with many of the author's critiques of the platform in general, hence my suggestion at using it sparingly when you fully understand the cost benefit analysis. If used correctly (real time features that don't involve mission critical data) Firebase is a game changer. It eventually becomes a reputation and perception problem.
For example, I've been happily using MongoDB for years now. The problems I've had with it are either:1. Problems that I can solve by doing enough research up-front (how to model my data, enforcing constraints on my collections, testing something on small datasets first).2. Problems I would have had on other systems (crashes where I didn't backup data, slow queries, etc.)I love PostgreSQL, and I keep getting amazed by it as I dig deeper into it. I've however chosen to rather learn, and not have unhealthy biases towards and against certain tools and technologies.I could say the same about the effort I put into most other tools that I rely on. I was playing around with Firebase a bit during the last few days.My biggest complaint so far: they haven't made the unminified source for the JS client available! You go on npm and you get the minified source.
How is that acceptable? Heck, it's completely pointless too, because if I really wanted to 'steal' the source I could prettify it and clean it up. It'd take a bit of effort, but it doesn't protect or hide anything. The reason why I wanted to use firebase was so I could hack up something quick. But as I was wiring stuff up, I got confused with their docs and figured I'd take a look at the source. Only to find a minified mess.On top of that, they're not developing the project in the open.
There's no public repo, so you can't contribute. I tweeted at them earlier today; hopefully it's an oversight and they fix it.Otherwise, it's unlikely I'll consider ever using firebase for anything, if they continue with these anti-developer practices. Firebase founderWe hear you on both counts.FWIW the 2.x JS SDK was available unminified (see: ). With our expansion launch at Google I/O we had to upgrade our serving infra - along with virtually everything else - and haven't added the capability back in to 3.x yet.The closed source SDKs feedback is something we hear frequently.
Unfortunately I can't give you anything better than 'hang tight' at the moment.Being 'anti-developer' is the antithesis of the Firebase ethos. We strive to be as developer friendly as we can. There are areas where we're not doing a good enough job right now and we're actively working to get better.I hope that helps add some color. I evaluated firebase and it convinced me to use couchdb+pouchdb. The things firebase improved were nice but not worth it and ultimately running our own DBs in European providers without external auth was less stressful for legal and estimating costs, performance, etc.For the criticisms not related to SaaS, some of them look like familiar debates, and I'd say a drawback of using noSQL is that I have something that looks ready faster but then I need to consciously hold it back from production until I've thought through structural problems which I would have worked out first in SQL. There's so many red flags in this article I'm not sure what I can really take away from it. These things may still be 'hacked' using Firebase, but it means that you will have to add even more code to your web-app, and it could be a nightmare to maintain if you have a mobile app too.So don't hack it and don't repeat it.
Do it once on your server. You may query directly Firebase over the network, right from your backend, but you should avoid doing this because it is really slow at scale.So queries from a browser and mobile client are more performant than a server running in Google's own datacenter? I'm guessing they're running queries that don't fit Firebase. It's a key/value store with a single simple query mechanism. The awesome feature is that it will solve the data synchronization problem. On the forums and stackoverflow, the Firebase team is quick to point people to using a server process to keep things simple. dealing with relations with Firebase is pain in the ass.Why are you using a key/value store?
it's not possible to export your users dataAre the Firebase docs lying to me? Complex queries are impossibleIt's a key/value store. Want to build an API for your product? It's impossible.WTF? old-fashioned SQL Database, which overs 90% of our data storage needs.
For the 10% part, we decided to use MongoDB to store messages and conversations at scale.So no ONE datastore that you could find solves your problems well, but Firebase sucks because it didn't?Sorry, I've been building a prototype with Firebase lately and this article goes beyond unhelpful into the land of complete nonsense. If someone has run into these issues, I'd love to dig into specifics. Is no one else a little alarmed by the language used on their home page? Does anyone know whether or not this is a legal privacy concern?' Crisp discovers every tiny detail on each visitor you chat with. From geolocation to device information, to full name and social profiles (LinkedIn and more). Crisp also discovers the company of the visitor.
Are my visitors aware of this feature? Your visitors cannot see that you know so much about them.'
'MagicType lets you view messages as they are typed. Visitors are not aware of MagicType, and cannot see what you type in response. Only you can see this.' I didn't downvote you, but thought it'd be better to make it clear what the person was referring to. The scenario mentioned was chatting with customer service on a website (like chatting with Apple customer care on Apple's website, foe example), where any message you type or edit would be seen by the customer service agent while you type, even if you didn't hit Enter or click on Send. This is not related in any way to the autocomplete feature on Apple's iOS keyboard or about what third party keyboards on iOS can do. Reason #1 to use Firebase (or any other reliable BAAS): it is the next logical step of cloud computing.If you've been around long enough, you probably had to convince the IT manager of one of your corp clients that it was a better idea to host the company's website on a hosting provider's server rather than in-house.
Didn't you?The argument of shouldn't trust your data to a BAAS provider is just silly: where's your data when you rent a VPS and mount your own back-end?Maybe Firebase was not the right choice for this particular product, but don't trash it for it.For me, the only missing feature is full-text search, yet the workaround is not as painful. All of these sounds like surmountable engineering challenges that one should have weighed when evaluating the data layer.'
You don't own your data' is downright false - you own it, you just don't host it. But do you ever really host it these days? Unless you're running it on your own hardware in your own facilities, probably not. So what the author should say is 'migrating is expensive because we chose to build on top of a SaaS product using a proprietary API and we're surprised by this because we didn't plan any further than a single 3 week sprint'. I have been using Firebase for two months now and it is a total nightmare to me. The support is awful.1) I don't get answers on Stackoverflow.2) I have stopped using your slack as it's close to impossible to get any answer.
It's a complete joke.3) When I tried to google, I often end up getting the legacy documents which are deprecated4) There are too many breaking changes between your different versions. This makes it so confusing to use angularfire/firebase and finding deprecated code examples.5) The youtube videos feels like a huge marketing stunts and you are all busy trying to promote an ever changing/incomplete firebase. 10 month old videos are no longer valid because of breaking changes.6) The security rules difference between firebase storage & firebase database7) Querying being such a huge pain. There was an effort made in a 2014 blog post but obviously code is obsolete.I know in the end.
It must be the developer's fault who’s not smart enough for firebase maybe. Interesting read, although other users have pointed out that some of the problems are solvable.I started using Firebase in May after the integration with Google Play. I run a public transit app/website (movinggauteng.co.za), and I have a few 'real-time' features such as basic chat and public transit updates/delays during peak periods.After hours on the Firebase docs, I'm still convinced that I'm better off with my own storage and database. I only use Firebase for Auth, Notifications (at times), Device testing, and almost everything else that doesn't require storing data that I don't already store myself.I've been a fan of MongoDB from the very start of the project, and I'm still going strong with it.
Firebase engineer here:BaaS (and 'serverless' in general) mean that since you don't control your database/storage/servers/etc. You no longer have the ability to implement your own custom Authentication and Authorization.Firebase solves this by using Firebase Authentication to determine who a user is and Firebase Rules (currently implemented in the Realtime Database , which this article mentions, and Firebase Storage ) to determine what a user can do. Yes, they're different languages, and we're working on upgrading the Realtime Database to use the new language syntax (we know it's a pain point, and we plan to address it).I strongly recommend watching our I/O talk on 'The Key to Firebase Security' which walks through the basics as well as shows the power of our rules system. While you probably can't specify all of your business logic in our Rules languages, you can enforce a vast majority of cases (including building things like per user rate limiting: and secure client side only trades: ).FWIW, this system is not a concept unique to Firebase. Parse has user ACLs (PFACL, PFRole on iOS for instance: ), and Horizon has it's own Rules templating system ( ).
It's half-true that you can't export emails. You can't do it directly, but if you save each email address on the user during account creation, then you're covered.It's not documented, but apparently you can request the password hashes as well.Firebase's querying methods are also severely limited. Yes, you can be smart about how you structure your data to overcome some of these limitations, but I've noticed that many db operations that are typically simple and inexpensive tend to require trickery and gymnastics with firebase.I think my least favorite part of my experience with firebase has been the use of their security rules. First off, the 'bolt' compiler is really bad, but necessary to avoid writing a huge mess of json.
Often times, it compiles your security rules into a single line of json, and then checks for errors, giving you an unhelpful message that the compilation failed on line 1, column 32,513.The security rules are not only cumbersome to write, and in a language you have to learn specifically for firebase, but also completely different when using the firebase database and firebase storage. For storage, you have a new language and new syntax to learn.Moreover, it's pretty common that you'll update the schema for some object in the database and then be faced with a 'Permission denied' error on all future writes. It's impossible to put the application into dev mode to get a more helpful error message saying which specific field the write failed on.
And even with lots of tests, it is really scary deploying changes to the security rules to production in a way I just haven't felt using other dbs.Come to think of it, that's not the worst part. For me, it's been their support. I really think they use some kind of generic answer bank to generate the bulk of their responses. Half the time the response doesn't even make sense in the context of the request I send.
Something like 'I'm getting X error message when I try Y using Z setup' will get a response like 'Could you send a screenshot of the error message?' - where the error message was copied and pasted verbatim into the original email. I suppose they hope I'll just give up after so much time wasted on the issue?After using firebase for over a year, I'd wholeheartedly advise steering clear of it for anything other than prototypes and hackathon projects. I'd love some more feedback on the Rules (disclosure, I'm an engineer on that team).JSON was originally picked since it felt closely aligned with Firebase (JSON data = JSON rules), but as we started building more into them (indices, etc.), and as people started writing more complex rules (even internally), things started getting really clunky. Blaze and Bolt were attempts to 1) add a less verbose syntax to rules, 2) add new features that promote code reuse (like functions), and 3) get feedback on the direction developers would like to see our authorization product move.The new Firebase Storage Security Rules are the next iteration of that.
They provide a non-JSON (though unfortunately non-standard) DSL with strong types, more functionality, functions, and some other cool things (like giving you actual row/col numbers for failures). We think it's an improvement on the JSON rules, but still think there's a lot left to do. Resolving the difference between the two languages is one of my goals, and I'm looking in to what it would take to update the Database to handle the Storage rules language so there's consistency across products.Unfortunately, when it comes to building a custom DSL, it's hard to pick some standard.
Parse has user ACLs (PFACL, PFRole on iOS for instance: ), and Horizon has it's own rules templating system ( ), but I don't think there's a good standard out there. We picked XACML as the basis for Storage Security Rules, but any other feedback on this would be much appreciated.We've considered non-code ways of doing this (like Blockly ), but don't have any concrete plans around those.As for verbose debug info, we used to support a 'debug' parameter in our tokens which would return the rule that failed (basically the output of the simulator, which told you exactly what happened where). I'm looking into adding that back, since I agree that it's pretty useful. If you haven't seen the database Security Rules Simulator (which shows this info) you should definitely check it out. Targaryen is a similar concept that you might like (unfortunately only works on the database).As for your second comment on support. The short answer is that I agree with you-since acquisition (and post I/O in particular), support has suffered (in terms of measurable things like response time as well as intangibles like response quality). I think there are a few reasons for this:1.
As a startup, you should optimize for an amazing support experience since at the expense of scalability. Everyone at Firebase was on a support rotation, and if customers had issues with the product, they talked directly with the engineer who built it and provided direct feedback and had their issue answered. It was a tradeoff (products were built slower), but it was incredibly important to is (engineers knew how the product was being used).Now that we're more than just the original Firebase features, it's much harder to have every engineer doing support, and it's actually much less valuable to have them doing this now. A lot of the value of engineers triaging front line support for a more mature product has been removed-many of the cases we get are 'RTFM' plain and simple, or the error message sent tells you exactly what the problem is (or there's a stack overflow post that details the exact problem that we've already answered). When cases get interesting, they get escalated to the engineer who built the feature.
It's the people equivalent of load balancing, but unfortunately the routing isn't perfect;)Which is a great seque to the other half of the problem.2. Unlike technology, scaling people based processes turns out to be really hard. Technology usually scales horizontally pretty easily, people don't.
You can provision new machines in minutes, but training people takes years. We've spent a lot of time teaching our new support team what Firebase is, how Firebase is generally used, and what problems people run into. We've built playbooks for each feature, created canned responses, and generally tried to build infrastructure to make knowledge available as best we can.I don't claim that these things have solved the problem, as when you're constantly working on new features, that also means the knowledge created and processes put in place have to be passed down to all of those locations. With any documentation or institutional knowledge, it's hard to ensure everything is up to date and people are all on the same page.That said, the base line of 'not asking for an error when the error is right there' is occasionally not there, and I'm working with the support team leads to combat this (as well as generally improve the experience). If I could wave a magic wand and change one thing about our current support it would be for people to adopt a distinct personality vs a script based system-even if they ask a dumb question and admit it, it's better than following a script and sounding tone deaf. If you could wave a magic wand and change one thing, what would you change?Feel free to email me mcdonald at firebase dot com (or answer here), I'd love to hear feedback on rules, support, or Firebase in general.
If you are still looking for feedback on the rules, here's what I've got:1. Allow errors to be source mapped back to the language they were written in originally (bolt/blaze/json).
Proper line numbers should be in the error messages, and if that's too much to ask for, then at least don't minify the JSON down to 1 line.2. Bring back debug mode!3. Make it possible to see, when changing a schema through the rules, what existing data that was writable will no longer be writable because it needs to be updated to match the new schema.
(In dev mode, not so important. In production, this would be my number 1 concern.)4. Stick to one language for all of the rules. I don't see any reason storage rules couldn't also use Bolt.5. Allow imports.
![]()
My rules file was getting long, so I eventually decided to split it logically and concatenate before compiling, but that's far from ideal.6. Within the firebase console, allow us to see the details of incoming requests (including auth data) as they happen. And whether they're going to get a 'Permission denied' error or not. It doesn't need to be a permanent log or anything like that, but maybe something you can enable for a few minutes while debugging. The simulator sort of helps, but it's so limited.
There's nothing that compares to real logging when you're trying to figure out what's going wrong.And as an aside, looking at the 'legacy' docs again brings back good memories. I enjoyed firebase way more before the Google transition. In addition to having better support the docs were friendlier, and that made a big difference. You guys should try out / check out then, it is a completely free and Open Source alternative that addresses many of the concerns in your post:3) Pricing. Since it is Open Source you can run it on your own infrastructure, so you can control how much money you spend and you are not vendor locked in to premiums.4) By default, gun only downloads 1 layer deep for every item you request instead of the entire subtree. This is great because it keeps things snappy fast and bandwidth light but still gives you control of when and how to load it.5) You might not like us here, because we also support offline-first changes. However everything runs through a conflict resolution algorithm such that data is strongly Eventually Consistent.
Check out the 1 minute demo videos in the repo.7) Relations are marvelous! Because gun is a graph database, you get relations as well as documents! As well as key/value, table, and other structures.9) Own your data. Yeah, not a problem here since everything is Open Source. You run gun where you want to, and it simplifies the devops for you. So it is almost like having your own self-hosted DBaaS!10) Because of the graph structure, you can do any custom query logic through conditional traversals (javascript is the query language).
However, we do plan on supporting SQL and MongoDB Query spec coming up in the future - but not yet.Happy to answer any questions and support you guys. Sorry that Firebase didn't work out for you, and congrats on your growth! Thanks, I really appreciate that. Being Open Source is rough, because people still judge you as 'selling', despite the fact that everything is free and MIT licensed.
Personally, it often causes depression, but I always pull through knowing/hoping that ultimately more lives will be impacted for the better.So thank you for the encouragement, it really helps and I hope it sends a message to others whom might have projects of their own - don't let the negativity get you down. Thanks for being that reminder.
Right now the standard way is to have a server that you proxy writes (the same setup you would have with Postges or Mongo) to, so I would refer you to things like Passport and stuff.We plan on adding our own system, however it will be based on a fully P2P setup. Where every user has public/private keys and the server does not have access to that private key. We have a couple prototypes but we aren't security experts so we want to be careful and get some auditing before we publish it as a tool.Finally, if you just want to control request/response, then there is a generic callback for that that gives you the ability to reject requests. See as an example, note that we may be changing this in the future though.
This bug arised again in v3.9.2Using the exact snippet from this issue2017-08-05T20:21:29.636Z CLI Version: 3.9.2 2017-08-05T20:21:29.636Z Platform: win32 2017-08-05T20:21:29.636Z Node Version: v6.11.2 2017-08-05T20:21:29.636Z Time: Sat Aug 05 2017 22:21:29 GMT+0200 (W. Europe Daylight Time)info: User function triggered, starting execution info: Execution took 60009 ms, finished with status: 'timeout' info: Execution took 60019 ms, finished with status: 'crash' Error: Can't set headers after they are sent. At ServerResponse.OutgoingMessage.setHeader (httpoutgoing.js:356:11)Same functions works fine when deployed, just not local.edit: Using the gcloud solution mentioned here fixes it.
Comments are closed.
|
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |