I'm developing an app for Firefox OS and I need to retrieve/sent data from/to my DB. I also need to use this data in my logic implementation which is in JS.
I've been told that I cannot implement PHP in Firefox OS, so is there any other way to retrieve the data and use it?
PS: This is my first app that I'm developing, so my programming skills are kind of rough.
You can use a local database in JS, e.g. PouchDB, TaffyDB, PersistenceJS, LokiJS or jStorage.
You can also save data to a backend server e.g. Parse or Firebase, using their APIs.
Or you can deploy your own backend storage and save data to it using REST.
You should hold on the basic communication paradigms when sending/receiving data from/to a DB. In your case you need to pass data to a DB via web and application.
Never, ever let an app communicate with your DB directly!
So what you need to do first is to implement a wrapper application to give controlled access to your DB. Thats for example often done in PHP. Your PHP application then offers the interfaces by which external applications (like your FFOS app) can communicate with the DB.
Since this goes to very basic programming knowledge, please give an idea of how much you know about programming at all. I then consider offering further details.
It might be a bit harder to do than you expect but it can be easier than you think. Using mysql as a backend has serious implication. For example, mysql doesn't provide any http interfaces as far as I know. In other words, for most SQL based databases, you'll have to use some kind of middleware to connect your application to the database.
Usually the middleware is a server that publish some kind of http api probably in a rest way or even rpc such as JSONrpc. The language in which you'll write the middleware doesn't really matter. The serious problem you'll face with such variant is to restrict data. Prevent other users to access data to which they shouldn't have access.
There is also an other variant, I'd say if you want to have a database + synchronization on the server. CouchDB + PouchDB gives you that for free. I mean it's really easy to setup but you'll have to redesign some part of your application. If your application does a lot of data changes it might end up filling your disks but if you're just starting, it's possible that this setup will be more than enough.
Related
I am creating an app in Electron using React. The first version will be a purely desktop based app using a local database for data storage etc. However, eventually I would like to utilise as much of the same code base as possible and deploy the same app as a cloud-based alternative (by just leaving out the electron component).
I'd like some advice, thoughts, opinions from the community on if I should use axios for creating internal restAPI infrastructure rather than a API using javascript modules/functions etc. for performing requests such as getting data from a database.
My thinking is then that when I port the application to the cloud, I really just need to change the restAPI locations to point to a cloud version which would then get the data from a cloud database rather than a local database etc.
Would exposing such APIs locally within Electron using axios pose any security risks or other issues that I may need to consider?
Perhaps this answer/discussion may also provide useful for the community in the future.
Looking forward to thoughts, or even new suggestions on how this may be best approached.
Thanks.
My boss asked me to find a way to completely disassociate our front-end application from the back-end in the local environment, currently I'm the sole developer for both our back-end software and the front-end, so using Docker I'm able to mimic a production environment and work on both projects separately, (we don't render on the server side), his idea is to mock literally everything, so in theory you wouldn't need the back-end software to develop the front-end.
Two of the (more reasonable) solutions I've thought of are:
Mocking all of the network requests on the frontend, these functions will
run instead of network requests.
the problem with this approach is that it is not persistent, all of the data is randomly generated for every request, and in a system that is so oriented around forms, tables, and lists, I feel that getting the data you're expecting after a form submission is a must.
and in order to persist data, every request would have to go through some sort of data store (Mobx, Redux, etc...) and even then, if the page refreshes, the data is gone.
Initiating an express server and DB on top of Docker along with Webpack, and mimicking the production server requests and responses using db seeders, this way the front-end is persistent.
Obviously, this approach would generate plenty of work, and in order to make sure the express server is correctly mimicking the original back-end software, it too will need unit tests and mock requests.
While mocking the data is great for unit tests, this doesn't seem like the way of doing front-end with such a small team to me, is there a good approach to achieving this that I cant come up with or find? or is this an exercise in poor decoupling strategies?
What you are looking for is a Mock API. There's plenty of packages for it where you define example requests in a JSON format. A lot of these also handle persisting data for a short amount of time.
From a strategy perspective using these can actually make a lot of sense to automize end-to-end-tests, which shouldn't rely a production API. Whether it's the right choice of developer time in a one man team depends on the long-term perspective of course ;-)
I'm still new to web development. To learn more about JavaScript(JS) and web development, I am thinking of writing a simple web app which pulls and records time-series data (say, the price of a stock) periodically and draws a live chart showing the historical data. In addition to price data, I would like the app to record/maintain some user-related info such as the ticker of the stock(s) associated to each user.
Ideally, I would like to keep the app light-weight and portable/standalone (meaning, reduce the dependency as much as possible, and the end user hopefully doesn't have to do a lot of configuration/install of dependencies). The issue that I cannot figure out is where to store the historical data. I looked around for database solutions which will allow the app to write data directly from the browser (that is, using JS) to the client's machine. LocalStorage and IndexDB are non-persistent as far as I understand. Some suggested using PouchDB, but upon looking at it closer, it seems like the user need to install CouchDB or some compatible DB (say, SQLite). But that means I cannot share my app with users who aren't technical enough to install and configure CouchDB or SQLite on their machine before using my app.
If anyone could share some insights as to which DB might allow a JS-based app to write persistent data to the client's machine (if such thing even exist), that would be greatly helpful. If there is no such DB solution, please feel free to let me know alternative solutions that would allow the goal of building a simple, portable, JS-based web app. Thank you!
I think the best solution is to use Electron.js. The whole idea of this framework is to create web apps that can reside on client machines. You could package up any DB option you want, or even better, just include an API to your backend through the web app and it will work on your client machine like I think you want it to.
As for DB options, there is a great thread on S.O. that talks about what is possible. It looks like knex.js is your best bet (full disclosure - I haven't used knex).
I get the general idea at this point, angular.js is client-side, so any attempts to do database communication is done via initiating get/post requests to a server-side script on the server (via node, php, asp.net, whatever you're using)...
Only thing I haven't been able to determine is what's the proper practice for this in both conventions/security : do you make specialized pages for many of your particular queries, or 1 to a few general purpose pages that run whatever passed in as parameters. That latter option seems like a security nightmare but at the same time making a page for each table's select,insert,update, etc also seems nonviable.
To be clear and try and focus this back to a single question, it feels like I'm missing a concept here. How do you structure the database calls for an angular.js application?
From a security standpoint it isn't very different than a traditional web app. Your web server sends and receives json (most likely) instead of html. This means using something like rails-api instead of full rails. It's best to think of your Angular app as completely disconnected from your web server like an Android or iOS app is.
You might use token based authentication instead of cookies (nothing would preclude you from using token based auth in a traditional web app but I wouldn't say it's commonplace in traditional web apps). Other than that any concepts that apply to securing a traditional web application apply to securing an API.
What database do you use? Structure depends on the app you're building and if DB is relational or not. It's a strategic question, for example it may be better to have nested documents, or not.
A chat application can be implemented using a database (browser send a request conterminously with a particular period and get data from a table which keeps messages).
I want to know that, is there a way to implement a chat application using Ajax and jsp/servlets in HTTP and no database connection ? I know jsp,servlets. How can session,request,responses be handled internally in a jsp/servlet application ?
If you want the non-production, educational version you can use Application Scope:
You can have an application scoped variable holding the chat list
E.g. use <jsp:useBean scope="application"> (one instance per application)
And as long as you have thread safety goggles, and you synchronize where needed, you are fine
But as mentioned, try to check node.js, it seems like the natural candidate for that
Edit:
Note that the application context is per VM, e.g. not the most scaling approach
You can use also ServletContext.setAttribute (same syncronization and scaling issues)
A database is just a glorified file. If your data is simple enough and you don't want to deal with databases just write to a file?
If you are a java guy, what you need seems to me like a good fit with spire.io, a service that allows you to build server-less, database-less applications with a java client.