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?
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'm trying to host a database (on either AWS or Heroku) to store data from my web app. I also need to create an API to interact with the database. Basically, like this picture from Google.
Image source: https://dzone.com/articles/an-introduction-to-restful-apis
What I'm trying to figure out:
Is the API and database typically hosted separately? Or are they often hosted together? I'm not sure if the API and DB are together 1 component (with sub components being API and DB), or if they are 2 separate standalone components.
If they are 1 component and they can be hosted together, then I believe you can use something like Express.js for your API which can query the database and respond to HTTP requests from the website.
If they are 2 separately hosted components, I feel that means I have to have 2 APIs, unless my API can directly talk to the database (I'm not sure if this is proper). So I would need my API to talk to some server side technology (PHP, Java, etc.) which would then query the database and return result to the API. So basically my API is talking to an API which is talking to the database. I'm not sure if this is over complicating things, but it sure seems like it.
I'm trying to clarify how this process works.
Is the API and database typically hosted separately? Or are they often hosted together?
Since the API service needs to make lots of requests to the database, you want the minimum network lag possible between them.
So generally they should be hosted together. What that means depends on the style of hosting. Using the same cloud service makes sense if you are using something like AWS Lambda. Otherwise using the same machine for both the database and HTTP service until you scale to the point where you need to separate them.
If they are 1 component and they can be hosted together, then I believe you can use something like Express.js for your API which can query the database and respond to HTTP requests from the website.
This is a common approach.
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 am creating an app that involves sending and receiving settings... The desktop application is constantly sending information to a hosted MySQL database, and the Android app will query this same information. It is something similar to the whatsapp web (but in this case, I'll be using a desktop app instead of webpages).
Until this part, everything is working as I need... but, this same Android app will be used to send settings to the desktop app, and the desktop will read and change its settings according to what was just sent.
If I need to constantly query the hosted MySQL database and check if there is any kind of changes sent from the Android, I believe that I'll have a performance drop... each time a query loop is finished, I would have to query, check for any modifications and so on.
Is there a better or correct way to do this kind integration between two apps? I've read something about WebSockets, but I don't have much technical information about this, neither examples that I can use in this case.
Thank you very much for your knowledge sharing.
Here are some useful sites on WebSocket:
http://websocket.org
http://blog.kaazing.com/ [some useful blog posts]
http://www.html5rocks.com/en/tutorials/websockets/basics/
https://goo.gl/5OaJff [mozilla site]
You may want to consider the Observer/Observables pattern. The MYSQL is the Observable and your desktop app and Android app are Observers (and you can add other Observers in the future). Its a common pattern with lots of examples out there. But you'll need a centralized WebSocket server and an Observer/Observable coordination subsystem. You can setup a pub/sub message broker that uses WebSocket with a nice JMS, MQTT, etc, API to make your life easier. ActiveMQ, IBM MQ Lite, Kaazing JMS Edition... lots of options.
full disclosure. I work for Kaazing.
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.