Can someone explain to me why you can't connect to a MySQL DB directly through dart from a security point of view?
There is no hard guideline on whether to connect frontend directly to backend or not. It is just a design practice that has been widely accepted and evolved over many years.
Typical app structure consists of
FRONTEND -> SOME MIDDLE LAYER -> BACKEND
Where your middle layer handles all the interactions/processing with the database and the frontend uses this functionality with some sort of API structure. Having this layer is extremely helpful when the application goes to scale, it gives an added abstraction to the frontend.
It is not advisable to directly fuse your frontend(your flutter app), to the DB(MySQL) because any efficient hacker might use basic man-in-middle attack to know your DB structure/connections/queries(There are some pretty effective decompilers present out there), and alter your data and you might not even get to know what caused the data to update unless you've applied some checks on DB layer.
Also, your frontend logic needs to be more of end-user centric than to handle the data of the user. Any backend system(java, node, etc) gives you added functionality & freedom to parse and present the data from either side.
You can use the sqlite package available to store basic data, like your session tokens, your app configurations etc, but it is advisable to keep the main user data like the logins, etc in a separate place, or better yet, you can use the firebase plugin to store data in document structure in the cloud.
Related
After creating some collection entries in Squarespace (like Blogs, Events, Products and so on..), is it possible to access the single databases with a MySql management application?
Or is it possible to create a private MySql database and force Squarespace to use it for the collection?
I would be easier to add/edit large data..
Squarespace is very much a "design-first" platform, and the data structure (or at least, the data structure as we can access it) is heavily abstracted away in the name of a simple design process. Getting data in can indeed be difficult, and getting it out even more so. It's just not a platform friendly to data management or portability.
Furthermore, you cannot run server-side code. So unless you fetch, parse and display your date entirely client-side using JavaScript (bypassing Squrespace's collections/layout entirely), the only way to serve the data to users is to first enter it via Squarespace's back-end editing UI. Custom tools have been created that, for example, add a button in the backend editing UI that allows you to manually sync collection items/data with an external source. It basically reads your source, maps the data to the collection item creation API that the backend UI itself uses, then executes until all collection items have been added in the back-end. However, this process must be manually trigered, and continually done as needed by logging into the backend, running the syncing function, then waiting for it to finish.
I'm new to flutter and i really want to know, is there a way to connect to a database server (for instance mysql) in flutter rather using firebase. I'm working on a smart parking system project where i need to insert the latitude and longitude of the parking area which is free into the database which is created in server and retrieve it whenever user requests for it. It would be great if anyone gives solution for above mentioned problem (Flutter with database).
Since Flutter is just a UI Framework, topics such as persistence and databases may be out of scope or may depend on the use case.
Flutter UI's can persist data (application state) for short periods of time in a manner that is really only useful for the purposes of creating a good User Experience (is this button click? is it green? etc.)
For persisting more useful data outside of the application and on the actual device, you may want to consider the Shared Preferences Plugin for Flutter.
Wraps NSUserDefaults (on iOS) and SharedPreferences (on Android),
providing a persistent store for simple data. Data is persisted to
disk automatically and asynchronously.
Now, if you require persisting data in any centralized manner (e.g. RDMS, Firebase, or any data persistence service) your options are:
Persistence options that have a Flutter plugin (e.g. Firestore, Firebase)
Build your own service layer using HTTP, gRPC that talks to some backend service that provides access to a data store. You can do this with Express, Rails, CloudFunctions, etc.
As for connecting directly to a database such as MySQL, I don't see why you couldn't do that (maybe there is some technical limitation), but this would be a very bad idea in any practical situations as (unlike Firebase/Firestore) you won't be able to protect your data store once any client application has write access.
It sounds like you need a central read/write data store, so your best bet may be to host a server that provides access to a database while exposing an API to Flutter for which you can use dart:io to make requests.
Try using sqflite. It's a package you can include in your Flutter app that allows you to persist data to the local device. You will need to use the path_provider as well. Here is the link to the repository on Github https://github.com/tekartik/sqflite
I know this sounds crazy, but I had a thought and I was willing to try it out. I use GitLab pages for all my online projects, but a lot of them are ASP.NET MVC, which is an issue as I don't think you can run ASP.NET MVC sites on GitLab pages. I then thought, what if I make a site using something like angular or node.js, and have a central API for all my web projects? I thought that was a great idea, until I realized I couldn't use a database either. I guess what I'm asking is, would it be possible to create a REST API that uses JSON files for storage and node.js as the request pages, to create an API without a database?
Of course.
If you think about a database from the perspective of your application code, it is basically just a place to store and retrieve data.
Imagine the database library you are using has two simple methods, store and retrieve. In your application code, you could write db.store('here is the item') and the later on, db.retrieve().
However, those store and retrieve methods could be implemented in many different ways to provide the same effective behavior from the perspective of your application. Some examples:
Send/query the data to/from an external data store, such as PostgreSQL
Write it to a file on disk and read it back later
Store the data in memory
Make HTTP requests to an external system to store the data
Some of these options will be more or less appropriate depending on your exact requirements, however, the general idea is that given a database API, you could implement the exact same method signatures with a completely different approach.
The task is to create several JSPs, in which the user would be able to interact by inputting information, which would be saved on a database server, so the info can be called up later.
I'm not sure if this question is constructive enough or not, but I have no idea how to even start. I know what each one of the components means, but that's about it. I have no idea how the whole process works and I don't know what's it called, so I can't even search for it properly.
Could anyone briefly describe the process from start to finish how this system would work and what should be my first concern? I'm more interested in the JSP hosting (would Tomcat be a better choice, or is Geronimo much better in my case) and the connection of JSP to the database.
You need several components and layers for an application like that, so the first thing to do is select your technology stack so you don't reinvent the wheel and adopt best practices that your frameworks include. My choice, is Spring Framework.
Your JSP's represent the View Layer of your app. You can use JavaScript/AJAX to embelish your forms and sent data to your server.
The data that the user enters in the form is received and processed by the Controller Layer. Spring MVC has some neat collection of controllers for you to use. Once the data es ready, you can pass it to the Service Layer to execute Business Logic.
The Service Layer contains Business Logic rules. Spring Framework let this Layer to be simple POJO's, and to apply Transactional logic if you wish. It's highly probable that Service Layer requires to persist some data in the Database, so it invokes the DAO layer.
The classes in DAO layer have the responsability of storing data in the database. You can use several frameworks for this, and Spring supports many of them. Also, Spring includes some inherent JDBC support with templates included.
With that you can start your project. It should run with no problems in Tomcat, Geronimo or any Java EE Container
I am developing a game (ipad), the game will need an online database for storage, becuz it will need others players data to play multi-player stuffs.
I have been reading core data tutorials, but so far, what I read are all for internal iphone storage (using internal sqlite3 etc).
My question is that:
If I were using online webserver database (connecting/read/write/update by using php), do I need to use the internal core data?
More details for question 1: For example, I fetch a player's data like username, level, gold, hp, exp etc, do I need to wrap to core data, or I just simply create an NSObject for storing the player information, and using share manager to share with others classes that need it?
What are the tips and technique for developing iPad games with web-services(mysql via php HTTP POST). (FYI, I found this ASIHTTPRequest library, and I find it quite useful, and I am using it).
Core Data isn't primarily for storage. Instead it is a means of creating the model layer of an Model-View-Controller design app (which the Apple API uses.) Persisting the model to disk is really just an option.
Core Data handles both size and complexity in models. If your app just fetches dumb data from the web server e.g. a list of static values, then you probably don't need Core Data. However, if your app fetches data from the web server and then manipulates it in a complex manner, then Core Data will provide you many benefits.
A lot times, if you don't use Core Data, you can end up essentially rewriting Core Data just to manage all the relationships between your data objects and the rest of the API.
If you plan on working a lot with the Apple API, you should learn Core Data regardless of the source or destination of your data. It will save you a lot of time in the long run. The important thing to remember is that its not a database wrapper.