I am new in mobile app development and I am developing an application in React Native, which will contains the lyrics of songs. Now, I am in a situation where I am thinking about the best way to make database for it.
I would like the basic lyrics to be downloaded to the device with the app, but also that the user can add other songs that would only be visible to him. Which way is the best? I think, that all songs could be saved into some database (for example in device storage or SD-card). I think about SQLite or Firebase, but is this the right way?
Thank you for all your advice ;)
Whole solution seems like a good use case for Firebase/Firestore.
Firestore seems to integrate well with mobile apps. It's also managed so it's a simple way to run a database for a mobile app given you can provide the customer with direct access to the database without the need for a backend.
I am learning web dev and I am planning on developing a simple web app using React: a decision matrix tool.
I need users to be able log in and save their matrices under their profile so I prefer to not use LocalStorage and thus learn more about databases. I am thinking of using JSON as the data format and I will also need to store basics user data for login and their profile.
I wonder how to tackle such a project since so far I have only been using GitHub Pages to host my static websites. Most of what I find by googling seems confusing or irrelevant for such a small-sized project.
My questions are:
What is the simplest way to store, access and edit JSON data as well as user data for a web app?
Are there any simple databases that can be “hosted” together with the app files on a server? Not sure if the question makes sense but I don’t understand where the database is.
What article or resource would you recommend to understand the concepts for data storage?
Ideally you would want to create a backend server using any language/framework e.g nodejs, java, django, php etc and expose the required data through APIs. But, if you don't want to create a separate backend app you can use Firebase database Firestore to save and fetch all of your required data. You can even use firebase hosting to deploy your app. Moreover, firebase also have their Authentication service which you can leverage for your app's authentication.
I just started learning react. Now I want to build a small application where:
A user can Register/Log In (working with database)
The user can add items to a todo list
The todo list is stored in a database
Do I need other libraries to work with databases?
It's a small application.
Should I use Redux or rather something using MVC pattern like ASP.net?
I don't have any expierence with any of these. After lot of research I am still clueless on where to start with.
As you are a beginner. I would recommend you to use below libraries in both front-end and backend to start with your application
Front-end:
React - works as view layer
axios - to talk to backend database for all CRUD operations
Use localstorage or session storage to work between components. Because your application is very small so you can go with this approach or consider
using redux from now if you feel your application will grow bigger in
future
Back-end:
Keep your back end service as micro-services
As you are already working on react means you know something about javascript so I recommend you write your backend service in nodejs
If you want to use No SQL database then you can go with mongoDB database using mongoose in nodejs
If you prefer SQL database then I would recommend you to start with Postgres SQL database. Postgres SQL is popular these days than
any other SQL database
These are the required libraries for you to start.
I would recommend you to go for MERN stack i.e., MongoDB, Express JS, ReactJS and NodeJS
I would like to ask how to create an ionic app that talks to Laravel API but still works offline when there's no connection.
Let's say i have to write a quiz mobile app in Ionic and it requests for Laravel API to retrieve the questions as well as store the scores in db.
I'm just starting to learn Ionic and i'm really confused right now on how to approach this.
What confuses me most are:
Does the Ionic source live inside the Laravel source code w/c serves the API?
If i want the Ionic app to be installable, should the Laravel source code be included as well during the compilation process?
Thanks in advance for any help.
Your php or in general server side code is completely independent from your ionic application. If you want your app to work offline you should think about something like fetching a high number of information initially and work with this data without making any additional requests.
However your ionic app does only contain the frontend. You could implement some logic for local storage, but if you want to keep information hidden from the user (e.g. solutions) you have to put that logic on a dedicated server.
In the few details you provided, I can say the Laravel code does not live inside the ionic app. The ionic app is separate from the backend API by Laravel. You are possibly trying for a ReST based architecture where you communicate with your Laravel Server with an API. You need to keep those codes separate.
However without any internet, you won't be able to access those APIs, so you will just be able to show some static data, or you could serve from a DB and show later. For how to use the sqlite db you can look here
In your backend you can have an API like
http://example.com/api/v1/questions/1/
Which will fetch a question with options and if you want the app to have the answer for offline storage you may have that as well. When a user answers, you may check whether you have internet access and send answer and verify if you do, else you may save the answer in your DB and sync when you do have access. You can fetch multiple questions so that a user may answer multiple questions in case he/she will not have internet access.
Hope it helps. :)
Context: I'm a beginner programmer, self taught in the hope of making a SPA. I've started with JavaScript, Jquery, PHP and MySQL, and now feel pretty confident with all. I've started with Ember, and am now moving away from having a PHP API to Node. Which has then brought me closer to Meteor... I'm aware I'll need to use Mongo instead, but having an integrated front and back seems to be sensible and have some advantages.
So my question is what are the advantages of having a separate REST backend API (eg Express) rather than an integrated front/back (eg Meteor).
One that springs to mind is that my app will be tablet/pc based, but in future I'll want a different mobile version, so I'd be able to use just use the same API. I'm conscious that the above question is the main concern with this stack question, but perhaps if a meteor developer could clarify whether this is indeed a concern.
Thanks in advance!
well for me you'll get a lot of advantages using a rest API, they are lightweight, extensible and overall reusable.
today it's a trend to use a vertical architecture that means having a RestFul service with a single responsibility, why because it scale better and it's easier to assign a team to an api, so that way you'll be able to manage several teams and apis in a very ordered way. This is probably how Twitter, wunderlist and other companies works, because it's a solution to scale better.
take a look to this talk by Raffi Krikorian he was the head of architecture of Twitter for a while is a little bit old but it worth every minute and to illustrate some of the advantages.
Also you can look at the diagram below, I did while ago it explains the differences between the MVC and API first type of architecture.
I've authored one rest app using angular and rest services and it has been a very nice experience to me there's no way back.
good luck
Meteor doesn't really "integrate" the front (client) and backend (server) as you describe. It still maintains them as two separate layers. The beauty of meteor (aside from the insanely awesome reactivity) is that it uses Javascript everywhere, instead of using JS on the client and some other language on the server, so you can use the same APIs on both the front and backend. Although Meteor does snazzy things like let you write client and server code in the same file, it still requires you to distinguish between the two, and server code is still stored only on the server and client-side code is still served down to the client.
Meteor is still young, but the developers and community are very active, and everything you described can be achieved with it at this point. I've been working with Meteor for about 6 months now, and it hasn't let me down yet. I'm working on a production-level application that also requires exposing a REST API for consumption in mobile apps, which I'm doing quite successfully with Meteor (I just updated a user profile using a REST endpoint from an Android device and watched it change in the Meteor app in realtime. So cool!).
I was using this great package, RestStop2, for building REST APIs in meteor, but it was unfortunately deprecated, so I released an updated version. Check it out for an example of building REST APIs in Meteor. It's available through the Meteor package manager: https://atmospherejs.com/nimble/restivus
So to answer your question, you always want to separate the REST API into it's own layer, but that is entirely possible with Meteor. To make it clear, you would never consume this REST API from within your Meteor app. Meteor uses DDP (not HTTP), which gives you a much more direct connection with your server, so you're doing something wrong if you're accessing data on your Meteor server from a Meteor client via HTTP. Of course, with Meteor, you have the advantage of being able to use existing code from your REST API.
There's a really good write-up that explains some of the considerations of writing a REST API in Meteor: http://www.meteorpedia.com/read/REST_API.
The design of a architecture separated in layers like frontend, backend (Rest Api) and DB, is for obtain a better a scalability, reusability and logic separator of features of the application. For example:
Today make a web applications separated in 3 layer (frontend, backend,
and databases), if tomorrow you wanna do a mobile application you can
develop the application like a extra project in the frontend layer,
but use all the features developed in backend. Then the frontend
application not need servers why run inside every device, but maybe
the load in the backend servers increase, and you only need add 1 more
server in the backend layer.
Its a little example, but is the most common case in this new era of mobile applications.
Remember always this in MVC architectures:
Frontend: Always call services from the backend, render the view, and capture data. Sometimes make a litle logic.
Backend: Receive the request, apply all the business logic, read and write operations in databases, and return a response preferred in json format.
Model: store data, backups, slaves, etc.
PD: If you use meteor in this example you gonna need to make a api Rest to develop the mobile application.