Background: My company currently has an iOS app built on a firebase / google servierless backend. We use callable functions extensively to centralize common business logic in the backend for reuse with our web app. We also have future plans for Android app development and would like to leverage this centralized business logic.
Problem: Many of our users use our iOS app in places where internet connectivity is limited (typically large concrete buildings).
Need: Is there a preferred approach to bundle cloud function JS code on device, similar to how custom TensorFlow Lite ML models can be bundled on device. Ideally the iOS app would call callable functions first then call bundled on device functions if internet was unavailable.
In short is there an architectural pattern to solve this problem similar to how it's solved for TensorFlow Lite, but for more rudimentary functions or algorithms without the ML overhead. Bonus would be a solution that works within firebase's existing solution set.
Cloud Functions runs only in the cloud. There is no on-device execution. An internet connection is always required to invoke callable functions.
If you're asking if there is a way to run some common code on device in a multi-platform way, that's off-topic for Stack Overflow. Please do some web searches or ask around in discussion forums to solicit some ideas.
There's nothing built into Firebase (or Google Cloud Functions) to run your functions code on the device itself. It's technically definitely possible, but it's just not part of the product - nor does a quick search show an effort from someone in the community.
It's not an unreasonable request though, so I'd recommend filing a feature request so that the Firebase team can consider it in the future. Until that time, you're on your own though.
Related
I am building a XCFramework for my company and the primary purpose is to expose our data for clients using this Framework. Clients can access data using this Framework through use-cases without knowing the implementation details.
This Framework needs a very high run-time maintenance support as we may have to add or update the use-cases based on clients requests or changing busing requirements. It's very important to design an automated solution to deploy new changes and make the updated Framework available for clients. I'm looking to host SDK somewhere so I can build and deploy it. Something like maven for Android. But I've not found some good solution yet.
I would love to hear if someone has similar experience or if someone can guide for a better solution. Thanks
I am working on a project that will include a Laravel web application, Android application, and iOS application. I am new to iOS. Since a user's data will need to be synchronized across all platforms, I assume the optimal way to do this is with a Relational Database (i.e. MySQL) and a PHP Web Service that interacts with the mobile apps.
Everything I see online says to basically use Firebase for mobile apps. There is a lot of work to create the PHP Web Services necessary. I am surprised the dominant recommendation is to use Firebase. About every iPhone app I have has both web and mobile platforms where data must be synchronized. I assume they cannot use Firebase and must use PHP Web Services.
Am I missing something?
You are absolutely correct that it is not a foregone conclusion that one would use Firebase. It’s a great solution that fills a particular niche, but developing separate web services is extremely common. (I suspect that that your online research may be biased by the fact that most of these articles are likely geared for mobile developers who might not have the wherewithal to develop, maintain, and support their own web server infrastructure.)
That having been said, I would not have jumped to the conclusion that the “optimal” way would be to write your own backend going against some RDBMS. These NoSQL solutions, like Firebase, are perfectly up to the job in most cases. There are pros and cons on both sides of the NoSQL vs RDBMS discussion (which is probably beyond the scope of this question).
So, do not be unduly biased by these Firebase articles you found online, but consider adding it to your tech stack if:
there are some compelling Firebase features that you don’t want to reinvent yourself (e.g. the integrated authentication options are nice; the realtime observers for database changes is a killer feature, if you need that; etc.);
the NoSQL paradigm of Firebase’s “Real-time Database” fits your app’s requirements; and
you need backend server capabilities, but don’t want to deal with the overhead of developing and maintaining your own backend.
In your case, because you’re already developing a Laravel app, that largely undermines that last rationale, because you’ve obviously already signed up for that.
So, it is just a question of what Firebase features you need and whether these features are compelling enough to justify adding Firebase to your tech stack. But don’t use Firebase because you found a bunch of articles advocating for it. Nor should you dismiss Firebase because you fear it won’t be “optimal”. It depends.
All of that having been said, the excellent, seamless, object-to-database mapping that Laravel provides really begs for the SQL database approach. If you tried to use Firebase for the backend, you’d likely lose a lot of the benefits of Laravel.
I'm enhancing a commercial App which until now has used cloud AI models to analyse data and make predictions.
The enhancement is moving the models onto the app for applications with no or limited network access.
These models represent significant IP to our clients and it is essential that we secure any data downloaded to a device from theft.
The App is iOS only for now and I was intrigued by WWDC2020's CoreML update including support for encrypting models. This would be ideal but we can't use CoreML at the moment due to its API not supporting the methods our models require.
Nice to know though that this is a recognised issue with in-app ML model usage.
What is the best method and available options in iOS (>11.0) right now that won't run foul of encryption export laws or even Apple's app store rules etc?
Or models are Javascript which we run in a JavaScriptCore VM with additional data files loaded from json string files.
My current thinking is to use something like the iOS AES encryption. Not hardwire the private key in the app but instead pass it via https, after a user logs in, storing it in the keychain. Decrypt the data strings in memory before loading into the JS VM.
I can see the obvious weaknesses with this approach and would be keen to hear how others have approached this?
The Data
The enhancement is moving the models onto the app for applications with no or limited network access.
These models represent significant IP to our clients and it is essential that we secure any data downloaded to a device from theft.
From the moment you make the data/secrets public, in the sense you include it with your mobile app binary or later download it into the device and store it encrypted, you need to consider it compromised. No bullet proof around this, no matter what you try, you can only make it harder to steal, but with all the instrumentation frameworks available to introspect and instrument code at runtime, your encrypted data can be extracted from the function that decrypts it:
Decrypt the data strings in memory before loading into the JS VM.
An example of a very popular instrumentation framework is Frida:
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
The Private Key
My current thinking is to use something like the iOS AES encryption. Not hardwire the private key in the app but instead pass it via https, after a user logs in, storing it in the keychain.
While not hard-coding the private key in the device is a wise decision it doesn't prevent the attacker from performing a man in the middle(MitM) attack to steal it, or use an instrumentation Framework to hook into the code that stores it in the keychain, but you may already be aware of this or not, because it's not clear from:
I can see the obvious weaknesses with this approach...
In my opinion, and as a side note, I think that first you and the business need to consider if the benefits for the user in having the predictions being made locally on their device outweighs the huge risk being taken of moving the data from the cloud into the device, and data protections laws need to be taken in consideration, because the fines when a data breach occurs can have a huge impact in the organization future.
iOS Solutions
What is the best method and available options in iOS (>11.0) right now that won't run foul of encryption export laws or even Apple's app store rules etc?
I am not an expert in iOS, thus I cannot help you much here, other then recommending you to use as many obfuscation techniques and run-time application self-protections(RASP) in top of the solution you already devised to protect your data, so that you can make an attacker life harder.
RASP:
Runtime application self-protection (RASP) is a security technology that uses runtime instrumentation to detect and block computer attacks by taking advantage of information from inside the running software.
RASP technology is said to improve the security of software by monitoring its inputs, and blocking those that could allow attacks, while protecting the runtime environment from unwanted changes and tampering.
You can also try to use advanced bio-metrics solutions to ensure that a real user is present while the mobile app is being used, but bearing in mind that the more skilled attackers will always find a way to extract the data to a command and control server. It's not a question if they will be able, but when it will happen, and when it happens it's a data breach, and you need to have planned ahead to deal with it's business and legal consequences.
So after you apply the most suitable in app defenses you still have an issue left to resolve, that boils down to ensure your API server knows what is making the request, because it seems you already have implemented user authentication to solve in behalf of who the request is being made.
The Difference Between WHO and WHAT is Accessing the API Server
When downloading the data into the device you need to consider how you will ensure that your API server is indeed accepting the download requests from what you expect, a genuine instance of your mobile app, not from a script, bot, etc., and I need to alert you that user authentication only says in behalf of who the request is being made, not what is doing it.
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
Think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
I see this misconception arise over and over, even among experienced developers, devops and devsecops, because our industry is more geared towards identifying the who not the what.
Others approach
I can see the obvious weaknesses with this approach and would be keen to hear how others have approached this?
As I said previously I am not an expert in iOS and I don't have more to offer to you then what I have already mention in the iOS Solutions section, but if you want to learn how you can lock your mobile app to the API server in order to only reply with a very high degree of confidence to requests from a genuine instance of your mobile app, then I recommend you to read my accepted answer to the question How to secure an API REST for mobile app?, specifically the section Securing the API server and the section A Possible Better Solution, where you will learn how the Mobile App Attestation concept may be a possible solution for this problem.
Do you want to go the Extra Mile?
In any response to a security question I always like to reference the amazing work from the OWASP foundation.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
I am planning to build an iOS app with react native and I am super excited to do so.
Unfortunately the deadline is quite short, so I am considering to use an approach like this, which hosts the app bundle in the cloud for the production build of the application.
This may be beneficial, as an api will be build for the app and I could simply change the code of the deployed app if the api behaves otherwise than previously assumed.
As this seems like a good idea on first thought and I am quite sure it is a good idea in terms of testing and continuous delivery I am not sure if this works out in production and if the application will be accapted by apple.
So my question is if such an application would be approved by apple and if this kind of structure provides any problems on the users devices.
Yes, this tends to be good idea. Usually, application stores a lot of data (authentication, user data and so on) on it's own servers.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
MongoDB vs Firebase
What are some quantitative advantages of using Firebase over MongoDB? (not opinions)
I know that Firebase is a cloud-based service with its own API, but I feel like Mongo may give me greater control in the long run.
Firebase is a real-time engine with backward connectivity. I.e. you might build a cross-platform app where clients subscribe to events on specific data and server actively informs clients about changes
The data layer is hosted for you. Mind that it is highly scalable. It's a nice kickstarter solution. Including auth management
Geo-Fire. Real-time geo coordinates solution.
Evident drawbacks of Firebase are:
You have to pay for it as soon as you start growing
You can't host datalayer (if owning data is critical or you develop an app for some separated subnet)
EDIT: here is a nice article how to replace Firebase in your app with Node.js+MongoDb. It shows how much work you would have to do on your own, and explains, IMHO, why a startup (small app) should begin with Firebase (if real-time updates to clients are required) and proceed with MongoDb (in any case self-written solution) if the project keeps evolving
EDIT 2: after being acquired by Google Firebase now offers various perks on top of its basic features which you would struggle to build on your own:
For development
Cloud Messaging: Deliver and receive messages across platforms reliably
File Storage: Easy file storage (including iOS)
Hosting: deliver static files from Firebase's servers (Included in Free plan)
Crash Reporting: Not a full logging service, but crucial help
For growth
Remote Config: Customize your app on the fly: suitable for A/B testing
Dynamic Links: Send users to the right place inside your app
Notifications: Engage with users at the right moment
Apples and oranges. Firebase is a Backend-as-a-Service containing identity management, realtime data views and a document database. It runs in the cloud.
MongoDB on the other hand is a full fledged database with a rich query language. In principle it runs on your own machine, but there are cloud providers.
If you are looking for the database component only MongoDB is much more mature and feature-rich.
Firebase is designed for real-time updates. It easily integrates with angular. Both are NoSQL databases. MongoDB can also do this with Angular through Socket.io integration. Meteor.js also makes use of MongoDB with an open socket connection for real-time updates.
MongoDB can be run locally, or hosted on many different cloud based providers. Firebase, in my opinion is great for smaller apps, very quick to get up and running. MongoDB is ideal for more robust larger apps, real-time integration is possible but it takes a bit more work.
After using Firebase a considerable amount I've come to find something.
If you intend to use it for large, real time apps, it isn't the best choice. It has its own wide array of problems including a bad error handling system and limitations. You will spend significant time trying to understand Firebase and it's kinks. It's also quite easy for a project to become a monolithic thing that goes out of control. MongoDB is a much better choice as far as a backend for a large app goes.
However, if you need to make a small app or quickly prototype something, Firebase is a great choice. It'll be incredibly easy way to hit the ground running.
I will answer this question in terms of AngularFire, Firebase's library for Angular.
Tl;dr: superpowers. :-)
AngularFire's three-way data binding. Angular binds the view and the $scope, i.e., what your users do in the view automagically updates in the local variables, and when your JavaScript updates a local variable the view automagically updates. With Firebase the cloud database also updates automagically. You don't need to write $http.get or $http.put requests, the data just updates.
Five-way data binding, and seven-way, nine-way, etc. I made a tic-tac-toe game using AngularFire. Two players can play together, with the two views updating the two $scopes and the cloud database. You could make a game with three or more players, all sharing one Firebase database.
AngularFire's OAuth2 library makes authorization easy with Facebook, GitHub, Google, Twitter, tokens, and passwords.
Double security. You can set up your Angular routes to require authorization, and set up rules in Firebase about who can read and write data.
There's no back end. You don't need to make a server with Node and Express. Running your own server can be a lot of work, require knowing about security, require that someone do something if the server goes down, etc.
Fast. If your server is in San Francisco and the client is in San Jose, fine. But for a client in Bangalore connecting to your server will be slower. Firebase is deployed around the world for fast connections everywhere.
Firebase is a suite of features .
Realtime Database
Hosting
Authentication
Storage
Cloud Messaging
Remote Config
Test Lab
Crash Reporting
Notifications
App Indexing
Dynamic Links
Invites
AdWords
AdMob
I believe you are trying to compare Firebase Realtime Database with Mongo DB .
Firebase Realtime Database stores data as JSON format and syncs to all updates of the data to all clients listening to the data . It abstracts you from all complexity that is needed to setup and scale any database . I will not recommend firebase where you have lot of complex scenarios where aggregation of data is needed .(Queries that need SUM/AVERAGE kind of stuff ) . Though this is recently achievable using Firebase functions . Modeling data in Firebase is tricky . But it is the best way to get you started instantaneously .
MongoDB is a database. This give you lot of powerful features. But MongoDB when installed in any platform you need to manage it by yourself .
When i try to choose between Firebase or MongoDB(or any DB ) . I try to answer the following .
Are there many aggregation queries that gets executed .(Like in
case of reporting tool or BI tool ) . If Yes dont go for Firebase
Do i need to perform lot of transaction . (If yes then i would
not like to go with firebase) (Tranactions are somewhat easy though
after introduction of functions but that is also a overhead if lot of
transactions needs to be maintained)
What timeline do i have to get things up and running .(Firebase
is very easy to setup and integrate ).
Do i have expertise to scale up the DB and trouble shoot DB related
stuffs . (Firebase is more like SAAS so no need to worry about scaleability)
In my experience, working with Firebase is a huge advantage if you are trying to do user management, database, messaging sort of app since all of these features are already well integrated.
Like others have said, if you're just focused on the database/querying aspect, stick to mongo.
Firebase provides some good features like real time change reflection , easy integration of authentication mechanism , and lots of other built-in features for rapid web development.
Firebase, really makes Web development so simple that never exists. Firebase database is a fork of MongoDB.
What's the advantage of using Firebase over MongoDB?
You can take advantage of all built-in features of Firebase over MongoDB.