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 6 months ago.
Improve this question
I have an app built with flutter and firestore as the DB. It works fine the way I need, it's pretty fast (does not have much data), but since a few days ago I started wondering if adding GraphQL in this App would bring any benefits to it?
To give some basic idea, let's say the app is a Uber eats like app, with several restaurants and multiple users making requests. I achieved this by with plain Flutter + Firestore. I'm afraid that at some point let's say, the app has lots of users and start to get slow, would GQL help on this aspect?
I found some Flutter packages like Firegraph that looks promising and easy to use.
Hope someone can share some knowledge on this area.
Fetching the data from firebase has a completely different approach compared to graphql or REST. Its developed in such a way that there's 0 delay. If you are using firestore then using graphQl will make no much difference in terms of performance. Also by checking the source of this package i see that it's fetching a document, saving it in cache and iterating though each document fields. So it's basically adding another layer to fetch data which i think isn't a good idea
Related
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 last month.
Improve this question
I am developing an app for keeping attendance records for the students and I am confused about using either SQFlite or Hive for the local database. What are the pros and cons of both? How does each perform in apps with smaller and more complex databases?
I am currently using Hive and it seems like a hassle regarding code readability.
if you want the saved data to be fetched instantly and you won't need complex queries or have relations among the saved entities then go ahead and use Hive since it loads its boxes (saved data) in the memory for instant fetching
otherwise use SQFlite as it's more readable, scalable, and customizable.
in your case and regarding the project you are working on, I believe you should go with SQFlite, maybe in the future you will add some other features not just attendance, and might need to make complex queries.
Both of them work great, but for both proper data modelling is essential.
However, I wonder whether your app can work without storing data externally. In that case, neither is a good option.
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 6 years ago.
Improve this question
Did someone try developing a GraphQL instead of RESTful API? Can someone give real life (not only theoretical) pros and cons. Basically from my research I found that the GraphQL power is to get exactly what you need nothing more. Where with REST APIs, you often have to make a series of requests and you can easily get back more information than you really needed.
Is it worth the time spent on researching and learning GraphQL? Any bugs or showstoppers that get your attention?
This question is primarily opinion-based.
But from my experience:
Multiple requests on a RESTful-API for just one thing often indicates a lack in the API design, namely the needed resource was not available and therefore stuff needs to be gathered from different resources to compensate for this.
A REST-API that could be easily replaced by GraphQL indicates, that the API was in fact a CRUD-HTTP-API, what is considered an Anti-Pattern among REST-Evangelists.
Also worth noting is, that GraphQL puts responsibilty on the client, because the backing API is reduced to be a datastore that just needs to be queried. REST on the other hand enforces the behaviour of the client and therefore reduces responsibility on it. The client gets reduced to be something similar to a browser.
There are cases the one or the other approach would yield better results, but that greatly depends on your situation.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'd like to get the data of a website. I'd like to display the table in an app. Do you have an idea how I could do it? Thanks for your answers!
Usually, you'd want the maintainer of the data you need to supply some API for machine-to-machine communication (a REST JSON web service, for example).
Since you are asking how to display the table in an app:
the easiest way would be to just point an UIWebView that way and go from there.
a more native look might be acomplished by parsing the data. As you included several 'parsing' tags, I guess this is what you'd prefer.
The problem with HTML scraping web pages (what you probably hope to do) is that the data you are looking for and foremost it's structure is prune to changes. If some unexpected changes can easily break your parser.
Thus, if you go for doing that (which might be prohibited by your school or other publisher, especially in germany), try to parse the data on your server and offer an web service for your app yourself. This way, you can react to changes of the structure faster and do not break the app for your users.
Seriously consider asking the school for an API.
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 8 years ago.
Improve this question
I am sorry if this is not a constructive enough question.. Coming from the SQL world I'm just trying to wrap my head around this. After reading a lot about MongoDB, I've become very enthusiastic about it and consider using it for an upcoming application (in combination with Meteor).
However, I came across this blog post, which describes the troubles Diaspora ran into when using it and states "you should never use MongoDB". The examples she's giving sound pretty convincing.
Are these true problems with MongoDB, or were they using it wrong? Is this article now outdated and are there better ways for doing what they're doing (duplicate data for instance, like users being linked to each other, to posts and to comments, is a very common use case)?
Yes, there is a plenty of cases when mongodb not feet good, some of them are
When data perfectly described with 'table' metaphor (better using
SQL)
When you need ACID and transactions out of the box
When your workflow extremely oriented to write operation
When you need to generate complex cross-data reports
Data model have strongly relational view (a lot of connected
instances)
There is a lot of others, but this is just something which comes to my head fast.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I want to make an app like Instagram but the problem is where to store all text and images data, I have used Instagram when there is no connectivity available then app will show the last feeds even when app is freshly openend (not from background). It uses core data or sqlite.
I came across a scaling presentation from instagram a little while back where they talk how they started, using what and then how they approached the challenges.
See the link: http://www.scribd.com/doc/89025069/Mike-Krieger-Instagram-at-the-Airbnb-tech-talk-on-Scaling-Instagram
Hope this helps.
It's not known what Instagram uses. Use whatever you feel most comfortable with. Anything is possible with any storage technology, although some might fit better than others. Also, regarding your question on "core data or sqlite", you can use Core Data with an SQLite database as a backend (way easier than accessing raw SQL). You can also use other backends with Core Data: binary and XML.