I want to create a new shopping kind of app using react native (Expo). Need few details like,
Which DB is better to use (I'm familiar with SQL)
From react native itself, can we connect to the DB or do we need to use other medium to connect
to DB and then call the APIs from ReactNative?
If I use dotnet as medium to connect to DB and call dotnet API from ReactNative, how difficult
it will be while publishing the app?
Can someone please elaborate on these points, as I'm fairly new to ReactNative and mobile app development.
Thanks in advance!!
There is no correct answer on your question.
If you don't need really critical performance requirements a lot of solution could fit your request.
The most common stack for mobile development are:
MERN stack:
MongoDB, ExpressJS, ReactJS, NodeJS
https://medium.com/swlh/how-to-create-your-first-mern-mongodb-express-js-react-js-and-node-js-stack-7e8b20463e66
PROS
Full stack javascript solution
Flexible data model with non relational db mongodb
Fast learning curve
CONS
Could require system administration
Could require architecture knowledge
Require nodejs knowledge
Costs
High TTM if you are alone (Time to market)
Require IT security knowledge
Note: you can replace MongoDB with PostgresSQL if your data model doesn't require flexibility and you have more experience.
This solution require a backend server which came with a cost and system knowledge (do you need a scalable architecture?), you can opt for example for Google App Engine (PaaS server) with a standard environment to reduce cost with less performance or flexible environment with more cost and good performance.
FIREBASE
Firebase is a platform developed by Google for creating mobile and web applications. Is a BaaS (Backend as a Service), so you don't need a backend, it give you really nice free usage (you won't have cost during development) and give all the complex part as a service such as authentication (username/password, social login, phone login, reset password ecc..), real time non relational database, storage, cloud functions and much more.
Is just a framework that you need to integrate in your app with easy configuration, easy query and good documentation.
The cons is that you will be locked with firebase as a provider.
DotNet solution is not really common on a full stack mobile development, is more an enterprise solution.
If you are searching for a fast learning curve and an easy development environment, the best solution is ExpoJS (instead of react native) and Firebase.
Related
I am planning to build a react native application, where at some point i should use a database, which database is suitable for online react native and how will i connect db with my react native code?
Databases should be linked to the server, and not directly to the app for obvious security purposes. An App is just like the front-end part of a website: if it's executed in client-side, it's not safe.
So any back-end framework with a SQL DataBase will do (PHP frameworks like Symfony or Laravel or NodeJS) You will have to get your data with react native's Linking fetch API, by adding a token if you want to limit the access to connected users only.
But good news, if you're not very comfortable setting up a server, you could always choose a server-less solution like Firebase .
I definitely recommend it. You could save a lot of time and end up with a very secure and fast solution to manage your app's data. Just be aware that only a limited number of requests per day are free (but don't worry, it's not that expensive and it gets paying only with a great number of request per day). You will have to learn how to use it by reading the docs though, it might take you a couple of days, but trust me it's not rocket science.
(Disclaimer: I'm not advertising for Firebase, I just enjoyed using it so I recommend it)
I currently have an Electron ReactJS application on hand that uses CouchDB as its backend for syncing and real-time updates. I have been tasked with "porting" the backend of this application to an existing webserver. The goal is to use the existing permission management and business logic implementations. At the same time the intent is to refactor the data structures as the data is heavily relational in nature. That said, personally, I would keep the app on CouchDB as it full-fills the main "offline-first and real-time" requirements and just add the missing authentication and permission layers, but management wants otherwise.
The port would be using an existing web server (running Play Framework with Scala) and a relational database (MySQL). I have been scavenging the web for a good existing solution. The "simple" solution that came to my mind sounds tedious and like I'm reinventing the wheel. My idea was to create an API and on top of it also send real-time updates to the users to which a change is relevant via web sockets. For state management on the client I would use Redux + Redux Offline. While this would work, this would require a lot of manual wiring of CRUDs on the backend server and the according requests and mutations on the client.
I have taken a look at AWS AppSync, Meteor.js and Apollo. AWS AppSync sounds like exactly what I could use, but it relies on the database being accessible to it, which is not an option due to my DB instance being on premise. From Apollo, the client part sounds like an option I could go with and then use Sangria on the backend. I suppose I could also drop the idea of Redux and use Apollo's "local state", although this requires more thought as I'm not familiar with it.
All of the latter solutions involve GraphQL. While this would still require quite some work on the backend, the communication itself between the frontend and backend would be simpler to handle.
In my case where the use of an existing backend server is a must, are there any more elegant solutions for offline-first collaborative real-time apps? Am I missing something?
I'd like to ask for the pros and cons between choosing either Firebase or Objectify (convenience interface for Google's Data store), as storage for the backend.
I'd like to make it as general an answer as possible, but in my use case, we have a Java desktop application, that will communicate with JSPs and servlets on Google App Engine, as well as Docker instances served on Google Container/Compute Engine (GCE/GKE). We have already implemented Firebase for authentication.
Our data scheme is simple, for now. No complex class, nothing inner, nested, or what not. The bulk of what we want to store are JSON objects, as flat in nature, as possible.
We're debating whether to store in Firebase as is (JSON), or to create a POJO server-side, to store in Objectify. We've done both, and we've researched the performance and scalability of these 2 services, as well as we can.
We deem both to be adequate for our needs, but expert opinion is always desirable, especially when considering long-term growth, inter-service convenience (e.g. GAE to GCE and back) and costs. Any other sort of input, is welcome too, of course.
I have a MySql database set up and a mobile app that should be able to write/read to and from the database.
The data being stored will be posts, comments, votes, etc.
Eventually, I might create a website that uses the same database.
My question is, do I need some sort of middleman (restful) service running or can I just connect straight to the MySql db from the client code (either the mobile app or website)?
Introducing a REST api into the middle would be much beneficial in a lot of ways.
Improve generalization and reuse. (REST api can be used by both mobile client and web client, no need to do the same work twice)
Can maintain business logic centrally. (If there's a logic to change or a bug fix, no need to correct in 2 places)
Can be easily exposed to any other app/client which would need the set of operations provided by the api.
Extending and maintenance of the app would be much simplified and would take minimum effort.
Especially with the mobile application, where you have much less control of updates, it seems better to use some middle-ware to connect to your database.
Say for instance your website needs a little change in the database that would break an active version of the mobile application. A web service could catch that for you.
What about a new version of your mobile app that needs a change. Again a web service can handle that for you.
This is all about cutting dependencies and keep the complete ecosystem adaptable.
Whether this is a rest or any other type of web service is a completely different discussion.
I have a app and I need develop a restfull api to be used for this app.
Is liferay a valid option to develop this (using the service builder and persistence layer of liferay) to expose my service api to be used for the app?
I have in mind the performance and availability to this services.
what another option (to develop the api rest) i should consider for this purpose
Thanks
I expect for your replies.
Regards
Liferay can act as a rest server by service buider (I'm not sure it will support any RESTful operation, but only GET/POST).
By this way you can inherit the interesting features provided such as:
- users, roles and groups
- ready scalable platform
- hibernate+ehcache already configured
Ecc... by the other hand, it will bring a great burden to you... so in my mind, if you are interested to other Liferay native features, then you can use it.
On contrary, there are other ligther frameworks for achieving your needs (just think to Spring MVC, it can implement any other restful method, like so PUT/DELETE... and it is more configurable)... so in this case it will ask you to do a bit more work by hand... but you will not "fight" with a complex platform if it is not necessary.
(In the first hypothesis, don't forget to give an eye to the "Liferay Mobile SDK")
thanks for answer.
In fact, I am interested in use the features of liferay like users, groups, profiles, persistence layer and the web content to manager some resources in the app.
My question is thinking in the performance and scalability of the services layer for this app, if is factible use only liferay to expose all the service to the app need and if her performance will be appropriate.
regards.